Internet DRAFT - draft-xu-behave-hybrid-type-prefix


Network working group                                             X. Xu  
Internet Draft                                                   Huawei 
Category: Standard Track                                       C. Byrne 
Expires: July 2010                                         T-Mobile USA 
                                                           M. Boucadair 
                                                         France Telecom 
                                                           China Mobile 
                                                       January 15, 2010         
            Hybrid Type Prefix for IPv4-Embedded IPv6 Addresses  

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-

   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 

   The list of Internet-Draft Shadow Directories can be accessed at 

   This Internet-Draft will expire on July 15, 2010. 

Copyright Notice 

   Copyright (c) 2009 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 in effect on the date of    
   publication of this document (   

Xu, et al.              Expires July 15, 2010                 [Page 1] 
Internet-Draft             Hybrid Type Prefix             January 2010 
   Please review these documents carefully, as they describe your 
   rights and restrictions with respect to this document.  


   To build IPv4-Embedded IPv6 addresses for IPv4/IPv6 translation, the 
   Well-Known Prefix (WKP) and Network Specific Prefix (NSP)-based 
   address formats have been defined in [Address-Format]. However, both 
   of them have some limitations in several use cases. Hence, this 
   document aims at discussing the validity of the use cases and assess 
   the interest of the BEHAVE WG to meet the requirement of 
   unambiguously distinguishing IPv4-Embedded IPv6 addresses from 
   native IPv6 ones. Doing so would guide the address selection and 
   therefore allow avoiding crossing unnecessary or even useless 
   address family translators.  

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   document are to be interpreted as described in RFC-2119 [RFC2119]. 

Table of Contents 

   1. Problem Statements...........................................3 
      1.1. Communications Involving Dual-Stack Hosts...............3 
      1.2. Load Balancing with WKP.................................4 
   2. Applicability Scope..........................................5 
   3. Hybrid Type Prefix...........................................5 
   4. Alternative Solutions........................................7 
   5. Security Considerations......................................7 
   6. IANA Considerations..........................................8 
   7. References...................................................8 
      7.1. Normative References....................................8 
      7.2. Informative References..................................8 
   Authors' Addresses..............................................9 

Xu, et al.              Expires July 15, 2010                 [Page 2] 
Internet-Draft             Hybrid Type Prefix             January 2010 
1. Problem Statements 

   The Well-Known Prefix (WKP) and Network Specific Prefix (NSP) have 
   been defined in [Address-Format] to build IPv4-Embedded IPv6 
   addresses for IPv4/IPv6 translation purposes. However, some 
   limitations may be experienced when using these formats in some 
   network configuration scenarios as elaborated latter in this 

   Without special mention, the NAT64 in the following description only 
   refers to stateful NAT64 [NAT64]. 

1.1. Communications Involving Dual-Stack Hosts 

   According to the rules defined in [RFC3484], native paths should be 
   preferred to paths involving address translation (including address 
   family translation). Particularly, in the context of IPv4-IPv6 
   interconnection, IPv4-Embedded IPv6 addresses should have a lower 
   priority than IPv4 addresses, otherwise IPv4-IPv6 translators may 
   not be off-loaded (The off-load is motivated by the need of 
   optimizing the resource of translators, especially stateful 
   translators) and even some communications may fail (e.g., when IP 
   addresses are enclosed in the application's payload and no specific 
   ALG is enabled in the IPv4-IPv6 translator). For this reason, means 
   to identify IPv4-Embedded IPv6 addresses may be required so as to 
   avoid crossing IPv4-IPv6 translators.  

   In some scenarios (e.g., the IPv6 host and the IPv4-IPv6 translator 
   are not located in the same administrative domain (e.g., AS)), the 
   NSP can not meet the above requirement of distinction between 
   synthesized and native IPv6 addresses because the NSP used by the 
   remote IPv4-IPv6 translator is not known to the IPv6 host.  

   Although the WKP allows for easy distinction between synthesized and 
   native IPv6 addresses, it does not meet all needs. For example, the 
   WKP is not suitable in the IPv6 Internet to an IPv4 networks 
   scenario because 1) the WKP can not be used to represent non-global 
   IPv4 addresses (e.g., the private addresses defined in [RFC1918]); 2) 
   even with global IPv4 addresses, the use of WKP will cause the 
   routing scalability issue on IPv6 routing systems due to importing 
   IPv4 routing table into IPv6 one. Hence the NSP is the only choice 
   for that scenario. Since it is difficult to distinguish IPv6 
   addresses synthesized with the NSP from native IPv6 addresses when 
   the translator and IPv6 host are not located in the same 
   administrative domain, it is possible that a suboptimal connectivity 
   will be chosen for communication involving dual-stack hosts. As 

Xu, et al.              Expires July 15, 2010                 [Page 3] 
Internet-Draft             Hybrid Type Prefix             January 2010 
   illustrated in Figure 1, H1 is a dual-stack host connected to a 
   dual-stack network, while H2 is an IPv4-only host connected to an 
   IPv4-only network. Assume H1 got the synthetic AAAA of H2 as a 
   return for its AAAA DNS query, H1 has no way of knowing the IPv6 
   address in the received AAAA response is not a real IPv6 address, 
   but a synthetic IPv6 address. H1 may therefore, be led to believe 
   that it has end-to-end IPv6 connectivity with H2. As a result, H1 
   may initiate IPv6 communication to H2 via the NAT64 device, even 
   using some IPv6-specific options (e.g., IPSec) that are not 
   supported by the NAT64 device.  

                       |                 | 
      +------------+   | IPv6 Internet   |  +-----+  +------------+ 
      | Dual-stack +---+                 +--+NAT64+--+ IPv4-only  | 
      |            |   +-----------------+  +-----+  |            | 
      |   +----+   |                                 |   +----+   | 
      |   | H1 |   |   +-----------------+           |   | H2 |   | 
      |   +----+   +---+                 +-----------+   +----+   | 
      +------------+   | IPv4 Internet   |           +------------+ 
                       |                 | 

        Figure 1. Dual-stack Hosts Communicating to IPv4-only Hosts 

   Preventing dual-stack hosts from using DNS64 service [DNS64] is not 
   a feasible way to address the above issue since synthetic AAAA 
   records may be added to authoritative DNS servers.  

   Configuring NSPs in H1's address selection policy table and 
   assigning them a lower selection priority is also unpractical for 
   the above scenario. 

1.2. Load Balancing with WKP 

   In the IPv6 network to IPv4 Internet scenario, assume multiple 
   stateful NAT64 devices are deployed at the border of the two address 
   realms for load-balancing [NAT-STANDBY] purpose. If the WKP is used, 
   they would have to synchronize their NAT states. Otherwise, internal 
   routing change will cause the interruption of the already 
   established sessions. Since it is unlikely that large networks will 
   be able to synchronize NAT state for tens to hundreds of millions of 
   users across thousands of kilometers, the network administrator 
   would have to use a unique NSP in each region to achieve proper 
   scale, redundancy, and fault isolation.  As mentioned before, IPv6 
   addresses synthesized with NSP can not be easily distinguished from 
   regular IPv6 addresses, which can result in a non-optimal situation 

Xu, et al.              Expires July 15, 2010                 [Page 4] 
Internet-Draft             Hybrid Type Prefix             January 2010 
   where dual-stack hosts may initiate communications to IPv4 hosts 
   through address family translators, even though they have native 
   IPv4 connectivities with the destination hosts. 

2. Applicability Scope 

   The proposed format is primary suitable for scenarios where the 
   IPv4-IPv6 interconnection service is not restricted to customers 
   attached to the same domain (e.g., AS) where the translator is 

   Hybrid Type Prefix should be used only for IPv4-Converted IPv6 
   addresses [Address Format] but never for IPv4-Translatable IPv6 ones. 

   This document defines prefixes to solve the following issues: 

   - NAT64 optimization when dual-stack hosts are involved; 

   - NAT64 Load balancing with a WKP prefix. 

   This draft can be positioned as part of the further works required 
   for solving some of unaddressed issues (mainly address selection) as 
   analyzed in [64-Analysis]. 

3. Hybrid Type Prefix 

   To address the issues mentioned in Section 1, this document proposes 
   a new type of prefix (called Hybrid Type Prefix, HTP in short) used 
   for IPv6 address synthesis (i.e., used for building IPv4-Converted 
   IPv6 addresses). This specific prefix integrates the benefits from 
   both WKP and NSP. 

                  | 0064(2)|  Network Specific Part(10) | 

                    Figure 2. Hybrid Type Prefix Format 

   As shown in Figure 2, the Hybrid Type Prefix is a special /96 prefix 
   which starts with a well-known two-octet value 0x0064 which is used 
   to identify synthetic IPv6 addresses.  The remaining part (i.e., 
   rightmost ten octets) of the prefix is network specific part which 
   should be allocated hierarchically in accordance with the current 
   IPv6 unicast address allocation scheme (e.g., The Hybrid Type Prefix 
   block will be allocated from IANA to RIRs, then from RIRs to LIRs, 
   finally from LIRs to subscribers).  These Hybrid Type Prefixes are 
   topologically aggregatable in the IPv6 Internet and can be 

Xu, et al.              Expires July 15, 2010                 [Page 5] 
Internet-Draft             Hybrid Type Prefix             January 2010 
   aggregated into 64::/16 to utmost extent. The Hybrid Type Prefix can 
   replace the NSP defined in [Address-Format] when deployed in the use 
   case described in Section 2. The format of IPv4 Embedded IPv6 
   address which is synthesized with the Hybrid Type Prefix is shown in 
   Figure 3.  

            | 0064(2)|  Network Specific Part(10) | v4 addr(4)| 

     Figure 3. Format of IPv4-Embeded IPv6 Address Synthesized with HTP 

   To facilitate the deployment of IPv6 network to the IPv4 Internet 
   scenario, a specific sub-block of prefixes which start with 
   64:FF9B::/80 is reserved from the Hybrid Type Prefix block. These 
   prefixes are called Well-Known Prefixes. As illustrated in Figure 4, 
   the rightmost two octets of the WKP are left for network 
   administrators to use. One possible usage of the WKP is to achieve 
   load-balancing on a set of NAT64 devices. For example, 
   64:FF9B:0:0:0:1::/96 is assigned to the first NAT64 device, 
   64:FF9B:0:0:0:2::/96 is assigned to the second NAT64 device, and so 
   on. For a single IPv6-only network, there could be up to 65536 NAT64 
   devices deployed for load-balancing purposes. Note that, as 
   specified in [Address-Format], 64:FF9B::/96 is reserved for hard-
   coding into host stacks. In order to distinguish 64:FF9B::/96 from 
   other WKPs, here, 64:FF9B::/96 is called the strong WKP, while 
   others are called weak WKPs.   

                  |0064:FF9B (4)|  all zeros (6) | (2)  |  

                    Figure 4. Well-Known Prefix Format 

   The relationship among the Hybrid Type Prefix block, the WKP block 
   and the strong WKP is shown in Figure 5: 

                |   HTP Block 64::/16                     | 
                | +----------------------------------+    | 
                | | WKP Block 64:FF9B::/80           |    | 
                | |  +-------------------------+     |    | 
                | |  | Strong WKP 64:FF9B::/96 |     |    | 
                | |  +-------------------------+     |    | 
                | +----------------------------------+    | 

Xu, et al.              Expires July 15, 2010                 [Page 6] 
Internet-Draft             Hybrid Type Prefix             January 2010 
                    Figure 5. Relationship between HTPs 

   As a counterpart, the cost of this solution is that it may require 
   an additional inter-domain advertisement to Hybrid Type Prefix. 
   However, since the Hybrid Type Prefixes are topologically 
   aggregatable, it will not cause the routing scalability issue in the 
   IPv6 routing system.  

4. Alternative Solutions 

   As defined above, 64::/16 is used as the Hybrid Type Prefix block. 
   For the IPv4-only networks in the IPv6 internet to IPv4 networks 
   scenario, they need to apply a unique sub-prefix block from the 
   Hybrid Type Prefix block for address synthesis purposes. Once these 
   networks are upgraded to support IPv6, they should apply a new 
   regular IPv6 prefix block while releasing the already applied Hybrid 
   Type Prefix block. Before obtaining a Hybrid Type Prefix, the IPv4-
   only networks can still use the NSP for address synthesis. Once the 
   issue mentioned in Section 1 needs to be solved, a Hybrid Type 
   Prefix would have to be applied from the LIRs to replace the NSP. 
   Hence, the use of Hybrid Type Prefix will not hinder the IPv6 

   To avoid multiple address applications, one alternative solution is 
   proposed: Use a reserved value for some special bits of the 
   interface ID part to identify IPv4-Embedded IPv6 addresses. For 
   example, a special binary value of bit 64 to 66, which is not 
   conflicted with any allocated OUIs, is reserved for identifying 
   IPv4-embeded IPv6 address. Furthermore, different types of IPv4-
   embeded IPv6 addresses can also be distinguished by the remaining 
   bits for that octet (e.g., bit 67 to 71). This alternative was 
   initially discussed in

   Another alternative solution, which does not require any change to 
   the address format defined in [Address-Format], is to define a new 
   DNS record type to unambiguously distinguish synthetic AAAA records 
   from native AAAA ones. This proposal is specified in [DNS-A64] 
   (Refer particularly to Section 3.1).  

5. Security Considerations 

   There is no new security risk introduced by using the Hybrid Type 
   Prefix for address synthesizing. 

Xu, et al.              Expires July 15, 2010                 [Page 7] 
Internet-Draft             Hybrid Type Prefix             January 2010 
6. IANA Considerations 

   No action is required from IANA.  

7. References 

7.1. Normative References 

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate               
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

7.2. Informative References 

   [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing        
             Architecture", RFC 2373, July 1998. 

   [RFC3484] Draves, R., "Default Address Selection for Internet                
             Protocol version 6 (IPv6)", RFC 3484, February 2003. 

   [Address-Format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., 
             and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", 
             draft-ietf-behave-address-format-02 (work in progress), 
             December 2009. 

   [NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 
             Address and Protocol Translation from IPv6 Clients to              
             IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-07 
             (work in progress), December 2009. 

   [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 
             "DNS64: DNS extensions for Network Address Translation 
             from IPv6 Clients to IPv4 Servers", draft-ietf-behave-
             dns64-03 (work in progress), December 2009. 

   [NAT-STANDBY] Xu, X., Boucadair, M., "Redundancy and Load Balancing 
             Mechanisms for Stateful Network Address Translators (NAT)", 
             draft-xu-behave-stateful-nat-standby-01 (work in progress),       
             June 2009. 

   [DNS-A64] Boucadair, M., Burgey, E., " A64: DNS Resource Record for 
             IPv4-mapped IPv6 Address", draft-boucadair-behave-dns-a64-
             01 (work in progress), October 2009.  

   [64-Analysis] Penno, R., Saxena, T., Wing, D., "Analysis of 64 
             Translation", draft-penno-behave-64-analysis-02 (work in 
             progress), January 2010. 

Xu, et al.              Expires July 15, 2010                 [Page 8] 
Internet-Draft             Hybrid Type Prefix             January 2010 
Authors' Addresses 

   Xiaohu Xu 
   Huawei Technologies, 
   No.3 Xinxi Rd., Shang-Di Information Industry Base,  
   Hai-Dian District, Beijing 100085, P.R. China 
   Phone: +86 10 82836073 
   Cameron Byrne 
   T-Mobile USA, Inc. 
   3617 131st Ave SE 
   Bellevue, WA 98006 
   Mohamed Boucadair 
   France Telecom 
   3, av Francois Chateau 
   Rennes 35000 
   Gang Chen 
   China Mobile