DHC Working Group S. Jiang Internet Draft Huawei Technologies Co., Ltd Intended status: Informational Q. Sun Expires: April 23, 2013 China Telecom October 22, 2012 A Framework for Semantic IPv6 Prefix and Gap Analysis draft-jiang-v6ops-semantic-prefix-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 23, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Sheng Jiang Expires April 23, 2013 [Page 1] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 Abstract Some Internet Service Providers and enterprises desire to be aware of more information about each packet, so that packets can be treated differently and efficiently. Packet-level differentiating can also enable flow-level and user-level differentiating. IPv6, with a large address space, allows semantics to be embedded into addresses. Routers can easily apply relevant operations accordingly. This document describes a framework that embeds semantics into IPv6 prefixes, so that network devices can treat packets based on these explicit semantics. This document also analyzes on the technical gaps for embedding complex semantics. This informational document only discusses usage of semantics in a Semantic Prefix Domain. It does NOT intent or suggest to standardize any common global semantics. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 4 3. Why Prefix .................................................. 4 4. The Semantic Prefix Domain .................................. 5 5. The Embedded Semantics ...................................... 6 6. Applicability ............................................... 6 6.1. An ISP semantic prefix example ......................... 6 6.2. An enterprise semantic prefix example .................. 7 7. Benefits .................................................... 8 8. Gaps ........................................................ 8 8.1. Semantics management in networks ....................... 8 8.2. Semantic relevant interactions with host ............... 9 9. Security Considerations .................................... 10 10. IANA Considerations........................................ 10 11. Change log ................................................ 10 12. References ................................................ 10 12.1. Normative References ................................. 10 12.2. Informative References ............................... 11 Sheng Jiang Expires April 23, 2013 [Page 2] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 1. Introduction While the global Internet increases explosively, more and more differentiated requirements are raised for the packet delivery of networks. Internet Service Providers and enterprises desire to be aware of more information about each packet, such as destination/source location, user types, service types, applications, security requirements, traffic identity types, quality requirements, etc. Based on these informations, network operators could treat packets differently and efficiently. Packet-level differentiating can also enable flow-level and user-level differentiating. However, except for destination/source location, almost of abovementioned information is not expressed explicitly. Hence, it is difficult for network operators to identify. Two passive and indirect technologies are already developed to distinguish the packets. Deep Packet Inspection (DPI) has been used by ISPs to learn the characters of packets. But DPI is expensive for both operational costs and process latency. Its time delay is too much to be able to be used for real time traffic control. Overlay networks are constructed in order to permit routing of packets to destinations not specified by IP addresses. But still, the overlay has no control over how packets are routed in the underlying network between two overlay nodes. Although tunnel or label forwarding may operate the traffic path, they introduce extra overhead while they depend on indirect information sources. An initiative solution, Quality of Service (QoS) and DiffServ [RFC2474] was also developed. It specifies a simple, scalable and coarse-grained mechanism for classifying and managing network traffic. However, the DiffServ fields set by the packet senders are not trustable by the network operators. In the real user case, ISPs deploy "remarking" points at the edge network, which classify each received packet and rewrite its DiffServ field according to user information learned from AAA or VLAN. The abovementioned solutions are mainly developed in IPv4 era, in which IP address is only locator, nothing else, giving the limited space. Although DiffServ was developed identically for IPv4 and IPv6, it inherits the same limitation. IPv6 has broken such limitation with its very large address space. It allows certain semantics to be embedded into addresses. ISPs or Enterprises can proactively embed pre-defined information into addresses so that intermediate devices can easily apply relevant operations on packet since addresses are the most explicit element in a packet. It provides an easy access and trustable fundamental for packet differentiated treatment. The technical fact that IPv6 allow multiple addresses on a single interface also provides precondition Sheng Jiang Expires April 23, 2013 [Page 3] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 for the approach that user chooses addresses differently for different purposes/usages. This document describes a framework that embeds semantics into IPv6 prefixes, so that network devices can treat packets based on these explicit semantics. This approach diverts much network complexity to the planning and management of IPv6 address and IP address based policies. It indeed simplifies the management of ISP networks. Different networks may have very different choose for the most important semantics. Pre-defined semantic definitions are only meaningful locally. Therefore, standardizing a general semantic is almost an impossible job. This informational document only discusses usage of semantics in a Semantic Prefix Domain. It does NOT intent or suggest to standardize any common global semantics. This document also analyzes the technical gaps to maximum the benefits of semantics prefix approach, for which complex semantics may need to be embedded. For now, this document only discusses unicast address within IPv6 Addressing Architecture [RFC4291]. 2. Terminology Semantic Prefix: a flexible-length IPv6 prefix that was embedded certain semantics. Semantic Prefix Domain: a portion of the Internet over which a consistent set of semantic-prefix-based policies are administered in a coordinated fashion. 3. Why Prefix Although interface identifier of IPv6 address has arbitrary bits and extension header can carry much more information, they are not trustable by network operators. Selfish users may easily change the setting of interface identifier or extension header in order to obtain undeserved priorities/privileges, while servers or enterprise users may be much more self-restricted since they are charged accordingly. Prefix is almost the only thing a network operator can trust in an IP packet because it is delegated by the network and the network can detect any undesired modifications, then, filter the packet. If one gets the destination address wrong, the packet would not reach; if it gets the source address wrong, the return packet would not arrive. This also would allow enterprise semantics to be able to traverse ISP networks. The prefix concept here refers the most left bits in IP addresses that are delegated by the network management plane. It could be Sheng Jiang Expires April 23, 2013 [Page 4] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 longer than 64, if the network operators strictly manage the address assignment by using Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] (but in this case standard Stateless Address Autoconfiguration - SLACC [RFC4862] cannot be used). Although IPv6 address space is plentiful, it should not be wasted. This argument can be dealt with by ensuring that only a small number of traffic classes are identified within a given user's traffic, so only a few bits in the prefix are needed. 4. The Semantic Prefix Domain A Semantic Prefix Domain, analagous to a Differentiated Services Domain [RFC2474], is a portion of the Internet over which a consistent set of semantic-prefix-based policies are administered in a coordinated fashion. A Semantic Prefix Domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies, hosts and routers, different user groups, different services, different traffic groups, different applications, etc. An enterprise Semantic Prefix Domain may span several physical networks, traversing ISP networks. The selections of semantics are various among different Semantic Prefix Domains. Network operators should choose semantics according to their needs for network management and services management. If an ISP has several discontinuous address blocks, it may be organized as a single Semantic Prefix Domain if the same semantic definition shared among these discontinuous address blocks. If these address blocks have different prefix lengths, their Semantic Prefix Domains may be distinguished each other by minimum differences of semantic definition. This indeed introduces the hierarchical Semantic Prefix Domains. A big Semantic Prefix Domain, which has common semantics, may contain several sub Semantic Prefix Domains, each of which has their own additional semantics. The design of the hierarchical Semantic Prefix Domains can also be used to organize and manage logic subnets. A Semantic Prefix Domain has a set of pre-defined semantic definitions, which are only meaningful locally. Without an efficient semantics notification or exchanging mechanism or service agreement, the definitions of semantics are only meaningful within local Semantic Prefix Domain. The semantics notification or exchanging does not have to through protocols. Manual interactions between network operators may also work out. However, this may involve trust models among network operators. Sharing semantic definition among Semantic Prefix Domains enables more semantic based network operations. Sheng Jiang Expires April 23, 2013 [Page 5] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 5. The Embedded Semantics As mentioned in Section 1, much information regarding to packets is useful for network operators. But, the prefix bits that can be used for embedded semantics are very limited. Therefore, only the selected, most useful semantics can be embedded in the prefix. Note, however, that DiffServ provides a very rich QoS semantic with only 6 bits. The available bits increase largely in the strictly managed network by DHCPv6. The following are some semantics may be useful by network operators beside source/destination location: user types, service types, applications, security requirements, traffic identity types, quality requirements, etc. When used, all of them should be restricted in a highly abstracted way. Larger granularity of semantics may provide better aggregation and extensibility. This document does not intend to define or give recommendations on choose of semantics for embedding in prefix. In a given Semantic Prefix Domain, multiple semantics can be used combinatorially. To use the limited bits efficiently, bits semantics should be pre-defined very carefully. The network operators should be very careful to plan and manage the semantic field. The network operators should self-restrict NOT to put too many semantic into prefixes, in order to avoid to be trapped into very complicated management issues. Too many semantics make management for prefix delegation become very complicated and hosts would not be able to handle. An important principle is to avoid semantic overlap for packet though semantic overlap for devices/hosts is fine. Any potential scenarios that a given packet may be mapped two or more semantic prefixes are considered harmful. 6. Applicability 6.1. An ISP semantic prefix example The current ISP network is mainly aggregated according to locator. The below ISP semantic prefix example uses the most left bits of prefix for locator function and lower bits for semantics. In other scenarios, if the network operator would like to organize network aggregation by semantic prior, using higher bits for semantics is also possible. Mixed aggregation model can be reached by put semantics or part of semantics bits in the middle of locator bits. Sheng Jiang Expires April 23, 2013 [Page 6] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IANA assigned block | locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | locator (Cont.) | Semantic Field|Subscriber bits| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: An ISP semantic prefix example In this example, the Semantic Prefix Domain has a /20 IPv6 address space. The 28 most-left (roughly 26 million of /64 prefixes) bits are allocated as locator. It serves network aggregation of topology based. The 8 most-right bits are subscriber bits. It means /56 prefix is assigned to subscribers. 8 bits (from bit 44 to 51) are assigned as semantic field. 6.2. An enterprise semantic prefix example The below enterprise semantic prefix example also uses the most left bits of prefix for locator function and lower bits for semantics. However, the locator function of IP address in enterprise networks may not be as important as in ISP networks. The enterprise network operator may prefer to organize network by semantic prior. A multiple-site enterprise may receive several prefixes that have different lengths. The semantic bits should be based on the longest prefix. The shorter prefix can use extra available bits for locators. It is compatible that shorter prefixes serve bigger networks with more users. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISP assigned block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISP assigned block | Locator | Semantic Field| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: An enterprise semantic prefix example In this example, an enterprise have received a 38/ address block for one site A and a /44 for another site B (the semantic prefix shown in Figure 2). They can be organized in a same Semantic Prefix Domain. The most-left 18 (site A) / 12 (site B, as shown in Figure 2) bits are allocated as locator. It serves network aggregation of topology based. The most-right 8 bits (from bit 56 to 63) are assigned as semantic field. Sheng Jiang Expires April 23, 2013 [Page 7] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 7. Benefits This section presents some, definitely not all, benefits. Depending on embedded semantics, various beneficial scenarios can be expected. - Easy measurement and statistic The semantic prefix provides explicit identifiers for measurement and statistic. They are as simple as checking certain bits of address in each packets. - Easy flow control By applying policies according to certain bit value, it is easy to control packets that have the same semantics. - Policy aggregation The semantic prefix allows many policies to be aggregated according to the same semantics in the policy based routing system [RFC1104]. - Easy dynamic changing for semantic oriented policy The network operators may want to dynamically change the policy actions that are operated on certain semantic packets. The semantic prefix allows such changes be operated easily. - Application-aware routing Embedding application information into IP addresses is the simplest way to realize application aware routing. 8. Gaps The simplest model of the semantic prefix is only embedded abstracted user type semantic into the prefix. It can be supported with the current network architecture because each subscriber is still assigned one prefix, while they are not notified the semantic within it. In order to maximum the benefits from the semantic prefix design, more functions are needed to allow semantic relevant operations in networks and semantic relevant interactions with hosts. 8.1. Semantic relevant operations in networks In order to manage semantic prefixes and their relevant network actions, the network should be able to perform semantic relevant operations. Sheng Jiang Expires April 23, 2013 [Page 8] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 - Semantics notification within the managed network When DHCPv6-PD [RFC3633] delegates a prefix, the associated semantics should be bounded. This is particular useful for autonomic process when a new device is plugged in. - Policy dynamic changing New functions or protocol extension are needed to enable dynamically changing the policy actions that are operated on certain semantic packets. - Semantics announcement to peer networks Networks may want to announce some of its prefix semantics to their peer networks. Hence, their peer networks may take some correspondent operations. 8.2. Semantic relevant interactions with hosts The more semantics embedded into prefix, the more complicated functions are needed for semantic relevant interactions between hosts and the network, such as prefix delegation, host notification and address selections, etc. - Notify prefix semantics to hosts When a host connects to network, it should be assign a prefix. The associated semantics should also be notified, also if there are semantic relevant rules. - Address selection according to semantics on hosts In practice, a host may belong to several semantics. It means several IPv6 addresses are available on a single physical interface. A certain packet would only serve a certain semantic. The IPv6 stack on that host must know and understand these semantics and its correspondent bits in order to choose right source address when forming a packet. If the embedded semantic is application relevant, applications on the hosts should also be involved in the address choosing process: the host IPv6 stack reports multiple available addresses to the application through socket API (one example is "IPv6 Socket API for Source Address Selection" [RFC5014]). Then the application responses the one it attached. In this architecture, hosts have to be intelligent enough to choose its source address according to its given information. In some complicated scenarios, choosing destination address may also need further supporting functions. Sheng Jiang Expires April 23, 2013 [Page 9] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 The current address selection algorithms and address selection API [RFC5014] are too simple to support this architecture. More complicated functions and intelligence are needed. 9. Security Considerations Embedding semantics in prefix is actually exposing more information of packets explicit. These informations may also provide convenient for malicious attackers to track or attack certain type of packets. When networks announce their local prefix semantics to their peer networks, it may increase the vulnerable risk. 10. IANA Considerations This document has no IANA considerations. 11. Change log draft-jiang-v6ops-semantic-prefix-01: add the concept of hierarchical Semantic Prefix Domain and more gap analysis, 2012-10-22. draft-jiang-v6ops-semantic-prefix-00: resubmitted to v6ops WG. Removed detailed examples and recommendations for semantics bits, 2012-10-15. draft-jiang-semantic-prefix-01: added enterprise considerations and scenarios, emphasizing semantics only for local meaning and no intend to standardize any common global semantics, 2012-07-16 draft-jiang-semantic-prefix-00: original version, 2012-07-09 12. References 12.1. Normative References [RFC1104] H.W. Braun, "Models of policy based routing", RFC 1104, June 1989. [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for IPv6", RFC 3315, July 2003. [RFC3633] O. Troan, and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Sheng Jiang Expires April 23, 2013 [Page 10] Internet-Draft draft-jiang-v6ops-semantic-prefix-01 October 2012 [RFC4862] S. Thomson, T. Narten, and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4291] R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC4291, February 2006. 12.2. Informative References [RFC5014] E. Nordmark, S. Chakrabarti, J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100084 P.R. China EMail: sunqiong@ctbri.com.cn Sheng Jiang Expires April 23, 2013 [Page 11]