Network working group X. Xu Internet Draft Huawei Category: Standard Track C. Byrne Expires: July 2010 T-Mobile USA M. Boucadair France Telecom G.Chen China Mobile January 15, 2010 Hybrid Type Prefix for IPv4-Embedded IPv6 Addresses draft-xu-behave-hybrid-type-prefix-00 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 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 (http://trustee.ietf.org/license-info). 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. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 document. 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 located. 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 deployment. 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 http://www.ietf.org/mail- archive/web/behave/current/msg07582.html 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 Email: xuxh@huawei.com Cameron Byrne T-Mobile USA, Inc. 3617 131st Ave SE Bellevue, WA 98006 USA Email: cameron.byrne@t-mobile.com Mohamed Boucadair France Telecom 3, av Francois Chateau Rennes 35000 France Email: mohamed.boucadair@orange-ftgroup.com Gang Chen China Mobile