Skip to main content

Semantic IPv6 Prefix
draft-jiang-semantic-prefix-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Sheng Jiang
Last updated 2012-07-16
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jiang-semantic-prefix-01
DHC Working Group                                          Sheng Jiang 
Internet Draft                            Huawei Technologies Co., Ltd 
Intended status: Informational                           July 16, 2012 
Expires: January 14, 2013 
                                    
                          Semantic IPv6 Prefix 
                   draft-jiang-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 January 14, 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 January 14, 2013                [Page 1] 


Internet-Draft     draft-jiang-semantic-prefix-01            July 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 provides analysis on how to form semantic 
   prefix and corresponding use cases, and identifies the technical 
   requirements to maximize the benefits of the semantic prefix  
   approach. It is recommended to use 4~12 bits in prefix for embedded 
   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. Why Prefix ................................................... 4 
   3. The Semantic Prefix Domain ................................... 5 
   4. The Embedded Semantics ....................................... 5 
   5. User Cases of Semantic Prefixes .............................. 6 
      5.1. ISP semantic bits ....................................... 6 
      5.2. An ISP semantic prefix example .......................... 7 
      5.3. Enterprise semantic bits ................................ 8 
      5.4. An enterprise semantic prefix example ................... 8 
   6. Benefits ..................................................... 9 
   7. Gaps ......................................................... 9 
   8. Security Considerations ..................................... 10 
   9. IANA Considerations ......................................... 10 
   10. Change log ................................................. 10 
   11. References ................................................. 10 
      11.1. Normative References .................................. 10 
      11.2. Informative References ................................ 11 
    

 
 
Sheng Jiang           Expires January 14, 2013                [Page 2] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 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 requirments, quality requirements, etc. Based on the 
   information, 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. Applications 
   or ISPs 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 

 
 
Sheng Jiang           Expires January 14, 2013                [Page 3] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
   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 for the approach that user 
   chooses application-associated address differently. 

   This approach transfers much network complexity to the planning and 
   management of IPv6 address and IP address based policies. It indeed 
   simplifies the management of ISP networks. 

   This document provides analysis on how to form semantic prefix and 
   its user cases. It is recommended to use 4~12 bits in prefix for 
   embedded semantics. This document also analyzes the technical gaps to 
   maximum the benefits of semantics prefix approach. 

   Different netowrks may have very different choose for the most 
   important semantics. 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. 

2. 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 
   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). 

 
 
Sheng Jiang           Expires January 14, 2013                [Page 4] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
   Two major arguments against this approach should be considered. One 
   of them is practical: 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. 
   The second argument is that addresses should not, as a matter of 
   principle, contain application semantics, because this violates the 
   layering structure of protocols. This argument can be answered by 
   ensuring that the only impact of the approach on the routing and 
   forwarding system is to modestly increase the number of internal 
   routes handled by the ISP concerned; there should be no impact on 
   aggregated routes that the ISP announces to other ISPs. 

3. The Semantic Prefix Domain 

   A Semantic Prefix domain, analagous to a Differentiated Services 
   Domain [RFC2474], is a contiguous portion of the Internet over which 
   a consistent set of semantic prefix 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 blocks have 
   different sizes, their semantic prefix domains may be distinguished 
   each other by minimum differences of semantic definition. 

   A Semantic Prefix domain has a set of pre-defined semantic 
   definitions, which is 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. 

4. The Embedded Semantics 

   As mentioned in Section 1, much information regarding to packets is 
   useful for network operators, such as destination location, user 
 
 
Sheng Jiang           Expires January 14, 2013                [Page 5] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
   types, service types, applications, security requires, quality 
   requirements, etc. 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: 
   user types, service types, security information, traffic identity 
   types, applications or application types, etc. When used, all of them 
   should be restricted in a highly abstracted way. 

   In a given Semantic Prefix Domain, multiple semantics can be used 
   combinatorially. They may be organized by using semantic type bits in 
   prefix or any pre-defined arbitrary way. However, the former is 
   preferred. 

   To use the limited bits efficiently, bits semantics should be pre-
   defined very carefully. Some formation recommendations are introduced 
   below. 

5. User Cases of Semantic Prefixes 

   Depending on the IPv6 address space that network operators received 
   from IANA or upstream network service providers, the number of 
   arbitrary bits in prefix is different. For now, this document only 
   discusses unicast address within IP Version 6 Addressing Architecture 
   [RFC4291]. 

   The first and most 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. 

   It is recommended network operator only use necessary semantics when 
   they can bring benefits to network operations. 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 prefix. So that they may avoid trap themselves into very 
   complicated management issues. 

   While assigning all these bits on a separated subfield mechanism is 
   considered inefficient and lack of flexibility, it is recommended to 
   assign in low granularity, such as bit by bit. 

5.1. ISP semantic bits 

   Typically, ISPs with millions subscribers would have /16 ~ /24 
   address space. It allows 40~48 arbitrary bits in prefix to be set by 
   network operators (assuming the network is not strictly managed by 
 
 
Sheng Jiang           Expires January 14, 2013                [Page 6] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
   DHCPv6). However, many ISPs plan to assign /56 or even /48 for 
   subscribers, the arbitrary bits are reduced to 22~40. 

   The locator function of IP address should be ensured first. Enough 
   consideration should be given for future expanding. Some address 
   space may be wasted in aggregation. For a Semantic Prefix Domain that 
   organizes several millions subscribers with a continuous IPv6 address 
   block, 24 bits for locator function is a minimum safe allocation. 
   Several bits may be good for safety margin.  

   The current network is mainly aggregated according to locator. Hence, 
   it is recommended using the most left bits of prefix for locator 
   function and lower bits for semantics. It is also useful for routing 
   scalability. However, 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. 

   According to the above analysis, it is recommended to use 4~12 bits 
   in prefix for embedded semantics. 

5.2. An ISP semantic prefix example 

    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| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The above figure represents an ISP semantic prefix example. 

   In this example, the semantic prefix domain have a /20 IPv6 address 
   space. It should serve over one million users. Hence, 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. It may be assigned further for semantic combinations. 

   A further detailed example, combing user type, service type, VPNs, 
   and application virtual overlay networks, the semantic field can be 
   assigned like blow (presented in octet): 

     00   Normal individual user with normal internet access services 
     01   High-end individual user with normal internet access  
            services 
     02   High-end individual user with secure internet access  
 
 
Sheng Jiang           Expires January 14, 2013                [Page 7] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
            services 
     03~07 Reserved 
     08   Enterprise user with normal internet access services 
     09   Enterprise user with secure internet access services 
     0A~0F Reserved 
     10~3F VPNs (with 48 sub-IDs) 
     40~7F Application virtual overlay networks (with 64 sub-IDs) 
     80~FF Reserved 

5.3. Enterprise semantic bits 

   Typically, enterprises with thousands users would have /32 ~ /48 
   address space from upstream network provider or address allocation 
   organization directly. It allows 16~32 arbitrary bits in prefix to be 
   set by enterprise network operators (assuming the network is not 
   strictly managed by DHCPv6). 

   The locator function of IP address should also be considered though 
   it is not as important as 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 available bits for locators. It is 
   compatible that shorter prefix serves bigger network with more users. 

   According to the above analysis, it is recommended to use 4~12 bits 
   in prefix for embedded semantics. 

5.4. An enterprise semantic prefix example 

    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| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The above figure represents 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). They can be organized in 
   a same semantic prefix domain. The most-left 18 (site A) /  
   12 (site B) 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 January 14, 2013                [Page 8] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
6. 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 

   Semantic prefix allows many policies to be aggregated according to 
   the same semantics in the policy based routing system [RFC1104]. 

   - Application-aware routing 

   Embedding application information into IP addresses is the simplest 
   way to realize application aware routing. 

7. Gaps 

   The simplest model of semantic prefix is only embedded abstracted 
   user type semantic into the prefix. It can be supported with the 
   current network architecture because each subscribe still assigned 
   one prefix, while they are not notified the semantic within it. 

   The more semantics embedded into prefix, the more complicated 
   functions are needed for prefix delegation, host notification and 
   address selections. 

   - Associate semantics with prefix delegation 

   When DHCPv6-PD [RFC3633] delegates a prefix, the associated semantics 
   should be bounded. 

   - Notify prefix semantics to hosts 

   When a host connects to network, it should be assign a short prefix 
   locator with some enabled semantics rules. 

   - Address selection according to semantics on hosts 

 
 
Sheng Jiang           Expires January 14, 2013                [Page 9] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
   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 should also be involved in the address choosing process. 
   The host IPv6 stack reports multiple available addresses to 
   application through socket API (one example is "IPv6 Socket API for 
   Source Address Selection" [RFC5014]. But more complicated functions 
   are needed). Then 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. It may also 
   receive address select information from the applications. In some 
   complicated scenarios, choosing destination address may also need 
   further supporting functions. 

   The current address selection algorithms and address selection API 
   [RFC5014] are too simple to support this architecture.  

8. Security Considerations 

   This document provides no new security features. 

9. IANA Considerations 

   This document has no IANA considerations. 

10. Change log 

      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 

       11. References 

11.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. 
 
 
Sheng Jiang           Expires January 14, 2013               [Page 10] 



Internet-Draft     draft-jiang-semantic-prefix-01            July 2012 
 
   [RFC3633] O. Troan, and R. Droms, "IPv6 Prefix Options for Dynamic 
             Host Configuration Protocol (DHCP) version 6", RFC 3633, 
             December 2003. 

   [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. 

11.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 

 
 
Sheng Jiang           Expires January 14, 2013               [Page 11]