behave X. Li, Ed. Internet-Draft C. Bao, Ed. Intended status: Standards Track CERNET Center/Tsinghua University Expires: October 24, 2009 F. Baker, Ed. Cisco Systems April 22, 2009 IPv4/IPv6 Translation Prefix Recommendation draft-xli-behave-v4v6-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 October 24, 2009. 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). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document is part of a series of the IPv4/IPv6 translation Li, et al. Expires October 24, 2009 [Page 1] Internet-Draft IPv4/IPv6 Prefix April 2009 documents. In this document, the address format and the corresponding prefix are recommended for representing IPv4 addresses in IPv6 and/or for representing IPv6 addresses in IPv4. Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Embedded Address Format . . . . . . . . . . . . . . . . . . . 4 4. Uses of the Embedded Address Format . . . . . . . . . . . . . 5 4.1. Representing the IPv4 addresses in IPv6 . . . . . . . . . 5 4.2. Representing the relationship between IPv4 and IPv6 addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Stateless Translation . . . . . . . . . . . . . . . . 6 4.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 7 5. Parameter Analysis of the Embedded Address Format . . . . . . 8 5.1. PREIX Analysis . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. IPv6 Routing System Scalability . . . . . . . . . . . 8 5.1.2. Other Issues . . . . . . . . . . . . . . . . . . . . . 10 5.2. Prefix Length Analysis . . . . . . . . . . . . . . . . . . 12 5.2.1. Routing Policy . . . . . . . . . . . . . . . . . . . . 12 5.2.2. IPv6 Address Consumption . . . . . . . . . . . . . . . 12 5.2.3. Forwarding Efficiency . . . . . . . . . . . . . . . . 13 5.2.4. SUFFIX . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.5. EUI-64 format . . . . . . . . . . . . . . . . . . . . 13 5.3. SUFFIX Analysis . . . . . . . . . . . . . . . . . . . . . 13 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. PREFIX Recommendation . . . . . . . . . . . . . . . . . . 14 6.2. Prefix Length Recommendation . . . . . . . . . . . . . . . 14 6.3. SUFFIX Recommendation . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Li, et al. Expires October 24, 2009 [Page 2] Internet-Draft IPv4/IPv6 Prefix April 2009 1. Introduction This document is part of a series of the IPv4/IPv6 translation documents. In order to perform the translation function between the IPv4 and IPv6, the translator needs to represent the IPv4 addresses in the IPv6 Internet and the IPv6 addresses in the IPv4 Internet. In this document, the embedded address format and the corresponding prefix are recommended. The address format and the corresponding prefix selection are related to the translation scenarios and the operation mode, discussed in the framework document [I-D.baker-behave-v4v6-framework]. For the stateless translator, this address format is used to represent the IPv4 addresses in IPv6 and to represent the IPv6 addresses in IPv4. For the stateful translator, this address format is used to represent the IPv4 addresses in IPv6 only and the session initiated states are used to represent the IPv6 addresses in IPv4. The technical specification of the translation is in the translation document [I-D.baker-behave-v4v6-translation], which uses the recommendations in this document. The DNS ALG document [I-D.bagnulo-behave-dns64] uses the recommendation in this document. 2. Terminology The following terminology is used in this document and other documents related to it. Embedded Address: The IPv6 address with IPv4 address embedded. PREFIX: The most significant bits before the embedded IPv4 address. SUFFIX: The least significant bits after the embedded IPv4 address. IPG4: The global IPv4 addresses. ISP4: The ISP's IPv4 prefix. IPv4 pool: The ISP4 configured in the stateful translator. Li, et al. Expires October 24, 2009 [Page 3] Internet-Draft IPv4/IPv6 Prefix April 2009 ISP6: The ISP's IPv6 prefix. IPG4prefix: The IPv6 address representation of IPG4. ISP4prefix: The IPv6 address representation of ISP4. ISP6prefix: Same as ISP6. Note that IPG4prefix is a subset of ISP6prefix and ISP4prefix is a subset of IPG4prefix. Stateless Translation: A translation algorithm that is not "stateful" is "stateless". It may require configuration of a static translation table, or may derive its needed information algorithmically from the messages it is translating. Stateful Translation: A translation algorithm may be said to "require state in a network element" or be "stateful" if the transmission or reception of a packet creates or modifies a data structure in the relevant network element. LIR (LIR Prefix): The IPv6 prefix assigned by the network operator for embedding IPv4 addresses into IPv6 addresses. In this case, each network running a translator will create a representation of the whole IPv4 address space in the IPv6 address space. WKP (Well-Known Prefix): The IPv6 prefix assigned by IANA for embedding IPv4 addresses into IPv6 addresses. In this case, there would be a single representation of a public IPv4 address in the IPv6 address space. 3. Embedded Address Format Embedding IPv4 address in IPv6 address (defined as IPv4-embedded IPv6 address) will be formed by concatenating a prefix to the IPv4 address and optionally a suffix. The prefix is called the PREFIX and the suffix is called SUFFIX. The resulting IPv6 representation is depicted in the figure below. 0 8 16 24 32 40 48 56 64 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX | IPv4 addr | SUFFIX | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |<--- network part ---->|<--- host part --->| Figure 1: Embedded Address Format Li, et al. Expires October 24, 2009 [Page 4] Internet-Draft IPv4/IPv6 Prefix April 2009 As shown in Figure 1, the embedded address format has three components: bits 0..n-1 (PREFIX): An LIR-specified prefix, either 32..63 bits long or 96 bits long, bits n..n+31 An embedded IPv4 address. Except in the case of a 96 bit prefix, this address intentionally straddles the boundary between [RFC4291]'s 64 bit "subnet" locator and its 64 bit host identifier. The intention is that the /64 be used in routing and the bits in the host part be used for host identification as described in the address architecture. bits n+32..127 (SUFFIX): Entirely zero; note that if n=96, this is null. The selection of the PREFIX, the prefix length and SUFFIX is discussed in the following sections. 4. Uses of the Embedded Address Format The embedded address format is used both for the stateless translator and the stateful translator. For the stateless translator, this address format is used to represent the IPv4 addresses in IPv6 and to represent the IPv6 addresses in IPv4. For the stateful translator, this address format is used to represent the IPv4 addresses in IPv6 only and the session initiated states are used to represent the IPv6 addresses in IPv4. 4.1. Representing the IPv4 addresses in IPv6 To represent the IPv4 addresses in IPv6, a PREFIX is selected and the global IPv4 addresses is embedded in this PREFIX, as shown in the following figure. This special IPv6 prefix (as IPG4prefix) is the image of the global IPv4 addresses and the IPv6 hosts will communicate with the global IPv4 addresses via this IPv6 prefix. The SUFFUX are all zeros. Li, et al. Expires October 24, 2009 [Page 5] Internet-Draft IPv4/IPv6 Prefix April 2009 +-+-+-+-+-+-+ |Global IPv4| +-+-+-+-+-+-+ || Mapping is based on the algorithm \ / \/ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ IPG4prefix | PREFIX | IPv4 addr | SUFFIX | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2: Represent the IPv4 addresses in IPv6 4.2. Representing the relationship between IPv4 and IPv6 addresses In the IPv6 domain, the addresses of IPv4 systems are represented using IPv4 embedded addresses, which can be translated without the maintenance of dynamic state. However, addresses in the IPv6 domain are different depending on the function of the system using them; IPv4-accessible servers in the IPv6 domain use the IPv4 embodied address format (4.2.1), while client systems that are inaccessible from the IPv4 domain can use stateful translation (4.2.2) to access IPv4 services. 4.2.1. Stateless Translation To represent the IPv6 addresses in IPv4, each provider can borrow a portion of its IPv4 addresses (ISP4) and maps them into IPv6 (as ISP4prefix) based on the above embedded address format, as shown in the following figure. These special IPv6 addresses will be physically used by IPv6 hosts. The original IPv4 form of the borrowed addresses is the image of these special IPv6 addresses and the global IPv4 addresses will communicate with ISP4 via this more specific prefix. Note that ISP4prefix is "more specifics" of IPG4prefix in the IPv6 Internet. The SUFFIX can either be all zeros or for the future extensions. Li, et al. Expires October 24, 2009 [Page 6] Internet-Draft IPv4/IPv6 Prefix April 2009 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ISP4prefix| PREFIX | |ISP4| | SUFFIX | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ || Mapping is based on the algorithm \ / \/ -+-+-+ |ISP4| -+-+-+ Figure 3: Represent the IPv6 addresses in IPv4 (stateless) Note that in the stateless case, o This mode is suitable for the "an IPv6 Network connecting to the IPv4 Internet" scenarios, since only a subset of the IPv6 addresses can be represented by IPv4. o This subset of the IPv6 addresses supports both IPv6 initiated and IPv4 initiated communications. Therefore, it can be used for the IPv6 only servers. o When the IPv4 address sharing technique is used, this subset of the IPv6 addresses will be big enough to meet the IPv4 address requirements in the IPv4 to IPv6 transition stages. The details of the technical specification will be discussed in other documents. 4.2.2. Stateful Translation The session initiated states are used to represent the IPv6 addresses (as ISP6prefix) in IPv4 for the stateful translator, as shown in the following figure. Li, et al. Expires October 24, 2009 [Page 7] Internet-Draft IPv4/IPv6 Prefix April 2009 +--+--+--+--+--+--+--+--+--+--+--+--+--+-+-+-+ ISP6prefix| ISP6 | +--+--+--+--+--+--+--+--+--+--+--+--+--+-+-+-+ \ / \ / Mapping is based on session initiated states \ / \/ -+-+-+ |IPv4| |pool| -+-+-+ Figure 4: Represent the IPv6 addresses in IPv4 (stateful) Note that in the stateful case, o This mode is suitable for both the "an IPv6 Network connecting to the IPv4 Internet" and "an IPv4 Network connecting to the IPv6 Internet" scenarios. But due to the stateful nature, it may have scalability problem and is suitable for small sized network. o It only supports IPv6 initiated communication. Therefore, it can be used for the IPv6 only clients. 5. Parameter Analysis of the Embedded Address Format 5.1. PREIX Analysis The PREFIX Recommendation Section discusses the selection of the PREIFX in the address format. The possible candidates are LIR (Local Internet Registry) and WKP (Well-Known Prefix). The major evaluation criterion is the IPv6 routing system scalability. 5.1.1. IPv6 Routing System Scalability 5.1.1.1. An IPv4 Network connecting to the IPv6 Internet For "an IPv4 Network connecting to the IPv6 Internet" scenario, only stateful translation can be used, as shown in the following figure. Li, et al. Expires October 24, 2009 [Page 8] Internet-Draft IPv4/IPv6 Prefix April 2009 ------ ----- ------ / The \ ----- / An \ / The \ | IPv6 |-----|Xlate|------| IPv4 |-----| IPv4 | \Internet/ ----- \Network/ \Internet/ ------ ----- ------ A Figure 5: An IPv4 Network connecting to the IPv6 Internet With private IPv4 addresses, the WKP doesn't work, since there is no distinction among IPv4 hosts using the private IPv4 blocks. With public IPv4 addresses, each IPv4 site will inject a route in the IPv6 routing table in border A, i.e. importing IPv4 routing table entropy into IPv6 routing table. Therefore, the LIR should be selected in "An IPv4 Network connecting to the IPv6 Internet" scenario. 5.1.1.2. An IPv6 Network connecting to the IPv4 Internet For "an IPv6 Network connecting to the IPv4 Internet" scenario, as shown in the following Figure, the stateless and stateful mode should be discussed separately. ------ ----- ------ / The \ ----- / An \ / The \ | IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 | \Internet/ ----- \Network/ \Internet/ ------ ----- ------ A B Figure 6: An IPv6 Network connecting to the IPv4 Internet With private IPv4 addresses, the WKP doesn't work, since there is no distinction among IPv4 hosts using the private IPv4 blocks. 5.1.1.2.1. Stateless Mode If Xlate is stateless, "an IPv6 network" will consist of hosts using IPv6 addresses of ISP4prefix (more specifics). o In border A, "an IPv6 network" will advertise ISP4prefix to the Xlate and the Xlate will advertise IPG4prefix (corresponding to 0.0.0.0) to "an IPv6 network". Li, et al. Expires October 24, 2009 [Page 9] Internet-Draft IPv4/IPv6 Prefix April 2009 o In border B, "an IPv6 network" will advertise ISP4prefix addresses with proper aggregation to the IPv6 Internet and the IPv6 Internet will advertise the global IPv6 routing table or 2000::/3 to "an IPv6 network". In other words, "an IPv6 network" should advertise the aggregated prefix of "an IPv6 network" and should neither advertise the IPG4prefix corresponding to 0.0.0.0/0 nor ISP4prefix. This can be achieved easily if LIR is used, since ISP4prefix is "a more specific" in IPG4prefix and IPG4prefix is "a more specific" in ISP6prefix. However, it cannot be achieved if WKP is used, since WKP is independent of the ISP6prefix of "an IPv6 network". In the case when WKP is used, the ISP6prefix must be advertised to the IPv6 Internet in order to communicate with other IPv6 hosts in the IPv6 Internet and this advertisement will eventually result in the injecting of the global IPv4 routing table into the global IPv6 routing system. 5.1.1.2.2. Stateful Mode If Xlate is stateful, "an IPv6 network" will consist of ordinary IPv6 addresses and Xlate maintains session-initiated states to map between ordinary IPv6 addresses and the IPv4 addresses in the IPv4 address pool. o In border A, "an IPv6 network" will advertise the aggregated prefix (ISP6prefix) of "an IPv6 network" to the Xlate and the Xlate will advertise the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 (IPG4prefix) to "an IPv6 network". o In border B, "an IPv6 network" will advertise the aggregated prefix of "an IPv6 network" (ISP6prefix) to the IPv6 Internet and the IPv6 Internet will advertise the global IPv6 routing table or 2000::/3 to "an IPv6 network". There is no need to advertise the IPv4 embedded IPv6 addresses corresponding to 0.0.0.0/0 (IPG4prefix) to the IPv6 Internet, if translation service of "an IPv6 Internet" is not supported to other IPv6 networks. Therefore, the selection of WKP versus LIR is mainly the operational consideration. 5.1.2. Other Issues When the public IPv4 addresses are used in the "an IPv6 network connecting to the IPv4 Internet" scenario and it is in stateful operation mode, there are several issues concerning the selection of LIR or WKP. These issues are: the referral support, the native connectivity preference in communications involving dual stack nodes, the DNS ALG configuration and the support for multiple translators. Li, et al. Expires October 24, 2009 [Page 10] Internet-Draft IPv4/IPv6 Prefix April 2009 5.1.2.1. Referral support A referral operation is when a host A passes the IP address of a Host B to a third Host C as application data. The Host C will then initiate a communication towards the Host B using the IP address received. At this point in time, there are two widely-available protocols that operate on the IPv4 Internet which perform referrals: SIP and BitTorrent. The analysis in [I-D.wing-behave-nat64-referrals] of SIP (which does referrals between IPv4 and IPv6) shows that SIP needs to refer IPv4 addresses -- not IPv6 addresses. Thus, it doesn't matter if WKP or LIR is used, because an IPv6 address isn't referred anyway: the IPv4 address is referred. 5.1.2.2. Native connectivity preference in communications involving dual stack nodes When dual stack nodes are involved in the communication, the potential issue is that they prefer translated connectivity over the native connectivity. Communication initiated from an IPv6-only node towards a dual stack node: In this case, the IPv6 only node will query for the FQDN of the dual stack node. The DNS ALG function will try first to get the AAAA RR. Since there is one available, it will return it and no AAAA RR will be synthesized from the A RR of the dual stack node. The selection of the WKP or LIR will be discussed in the following section. Communication initiated from a dual stack node toward an IPv4 only node. In this case, the dual stack node MUST use normal DNS (not the DNS ALG) and the native connectivity is ensured. Thus, it doesn't matter if WKP or LIR is used. 5.1.2.3. DNS ALG configuration The DNS ALG function can be placed either in the DNS server or in the end host. In order to synthesize AAAA RR, the DNS ALG function needs to know the PREFIX. In the case that a WKP is used, the PREFIX information can be hardcoded in the DNS ALG code, requiring no additional tools for learning it. In the case that a LIR is used, the DNS ALG needs to discover the PREFIX information. In the case that the DNS ALG is located in the servers, it may be a viable option to manually configure the PREFIX in the DNS ALG for a few servers. However, in the case the DNS ALG is located in the hosts, the manual option seems inconvenient and alternative automatic means need to be provisioned. Moreover, since this information is used for DNSSEC Li, et al. Expires October 24, 2009 [Page 11] Internet-Draft IPv4/IPv6 Prefix April 2009 operations, the mechanism to configure the PREFIX need to be secure. The result is that the LIR option requires more tools than the WKP. 5.1.2.4. Support for multiple translators This issue is somehow orthogonal on whether the prefix is WKP or LIR. In both cases, it is possible to use a single prefix for multiple translators or different prefixes for different translators. In any case, this would be achieved by inserting (or not) some subnet bits between the prefix and the embedded IPv4 address that would be used to identify the translator box. This issue does have implications on some of the different issues considered before. In particular, if a per translator prefix is used, then there is the need to configure the prefix in the DNS ALG, so the non configuration feature of the WKP is no longer achieved. 5.2. Prefix Length Analysis There are three issues related to the prefix length selection, routing policy, IPv6 address consumption and the forwarding efficiency, etc. 5.2.1. Routing Policy The major issue for selecting the prefix length is the routing policy. If the IPv4/IPv6 translation is implemented in a subnet, then a /96 should be fine. However, if the IPv4/IPv6 translation is implemented in an ISP's backbone, then the minimum prefix should be /64 and in some cases should be /48. 5.2.2. IPv6 Address Consumption One issue that is worth considering is the one related to IPv6 address consumption. In particular, depending on the selected prefix length, IPv6 address consumption can become an issue. For LIR case, the prefix must come out of the IPv6 allocation for the site running the translator. If the site running the translator is an ISP, then probably the allocation of the ISP is a /32 or shorter, so, it may be possible for the ISP to allocate a somehow short prefix for this, maybe a /40. However, if the translator is run by an end site, which normal allocation is a /48, then the LIR prefix for the translator should be much longer than that, possibly a /56. So, in the case the site needs to route based on the IPv4 prefix embedded in the IPv6 address (e.g. in order to access to different parts of the IPv4 space through different routes), then it is likely that it will need to route on the lower 64 bits of the IPv6 address. Li, et al. Expires October 24, 2009 [Page 12] Internet-Draft IPv4/IPv6 Prefix April 2009 For the WKP case, the prefix would be allocated by IANA for this particular purpose. As such, it seems reasonable that a short prefix can be obtained for this. Requesting for a /24 or even a few bits shorter seems feasible. The potential benefit of this is that IPv4 prefixes can be represented as IPv6 prefixes that are shorter than 64 bits. This would result in routing based on the upper 64 bits, which is compatible with current IPv6 practices. For instance, if we use a /24 for the WKP, an IPv4 /24 would result in an IPv6 /48, which seems somehow equivalent from the routing perspective. 5.2.3. Forwarding Efficiency According to current specifications, routers must handle routes containing prefixes of any valid length, from 0 to 128. However, some users have reported that routers exhibit worse performance when routing using long prefixes, in particular when using prefixes longer than 80 bits. This implies that using prefixes shorter than that would result in better performance in some cases. 5.2.4. SUFFIX If the optional SUFFIX is required, the prefix should leave the space for the SUFFIX. 5.2.5. EUI-64 format The selection of the prefix length may affect the EUI-64 format, since the subnet may not be in the 64 bit boundary. However, there is no contradiction to [RFC4291], which states that first, an interface identifier has to be unique on the LAN-or-whatever it is on. And second, when the interface identifier is a MAC address it should be in a format related to a MAC Address - except that it is different. So, especially given privacy addressing, we can't really assume that the router or neighboring host is going to extract a MAC address from the interface identifier and directly use it to direct a datagram to another host; rather, the relationship between a MAC address and an interface identifier has a level of indirection managed by Neighbor Discovery. 5.3. SUFFIX Analysis In the current implementation of the stateless mode, the suffix is entirely zero. For the stateful mode when using Well-Known prefix, the suffix can be used to represent different NAT boxes. Li, et al. Expires October 24, 2009 [Page 13] Internet-Draft IPv4/IPv6 Prefix April 2009 6. Conclusions The embedded address format is defined in this document, which can be used to represent IPv4 addresses in IPv6 for both stateless and stateful translations. The embedded address format is also used to represent IPv6 addresses in IPv4 for stateless translation. The PREFIX, prefix length and SUFFIX in the embedded address format are defined as well in this document. 6.1. PREFIX Recommendation The PREFIX Recommendations are: o In the case when different sites are using same IPv4 addresses (for example, [RFC1918] space), the LIR MUST be used. o In the "an IPv4 network connecting to IPv6 Internet scenario, the LIR MUST be used. o In the stateless mode of large scale networks, the LIR MUST be used. o In other cases, the LIR is RECOMMENDED and all of the relevant protocols and software need to accommodate the ability to configure that LIR prefix. o If for some reason, you cannot use LIR (e.g. in an isolated network), you should use this WKP allocated by IANA for this purpose, rather than pulling one out of thin air, or using a prefix allocated for a different purpose. o When the WKP is used, it MUST be treated same as the 6to4 prefixes and the corresponding routing practice MUST be taken. (6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table by elements of the IPv4 routing table. Therefore, a 6to4 site which also has a native IPv6 connection MUST NOT advertise its 2002::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2002:: routing prefix advertisements longer than /16. 6.2. Prefix Length Recommendation For the prefix length selection, there are some obvious values that might be popular, including /40, /44, and /96, but there is no requirement than any of them be used; this is left to the operator's discretion. Li, et al. Expires October 24, 2009 [Page 14] Internet-Draft IPv4/IPv6 Prefix April 2009 6.3. SUFFIX Recommendation For the SUFFIX selection, it is entirely zero at this time. However, it could be used for the future extension of the translation functions. 7. IANA Considerations The future versions of this memo will require WKP assignment from IANA. It is an IPv6 block, but the prefix length of this block has not be determined. The possibilities are /16 (similar to 6to4 block), /32, /48 or /96. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 8. Security Considerations One "security" issue has been raised, with an address format that was considered and rejected for that reason. At this point, the editor knows of no other security issues raised by the address format that are not already applicable to the addressing architecture in general. 9. Acknowledgements This is under development by a large group of people. Those who have posted to the list during the discussion include Andrew Sullivan, Andrew Yourtchenko, Brian Carpenter, Congxiao Bao, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, William Waites and Xing Li. 10. References 10.1. Normative References [I-D.bagnulo-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and Li, et al. Expires October 24, 2009 [Page 15] Internet-Draft IPv4/IPv6 Prefix April 2009 M. Endo, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-dns64-02 (work in progress), March 2009. [I-D.bagnulo-behave-nat64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03 (work in progress), March 2009. [I-D.baker-behave-v4v6-framework] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 Translation", draft-baker-behave-v4v6-framework-02 (work in progress), February 2009. [I-D.baker-behave-v4v6-translation] Baker, F., "IP/ICMP Translation Algorithm", draft-baker-behave-v4v6-translation-02 (work in progress), February 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 10.2. Informative References [I-D.baker-behave-ivi] Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in progress), September 2008. [I-D.durand-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-durand-softwire-dual-stack-lite-01 (work in progress), November 2008. [I-D.ietf-v6ops-addcon] Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", draft-ietf-v6ops-addcon-10 (work in progress), September 2008. Li, et al. Expires October 24, 2009 [Page 16] Internet-Draft IPv4/IPv6 Prefix April 2009 [I-D.miyata-v6ops-snatpt] Miyata, H. and M. Endo, "sNAT-PT: Simplified Network Address Translation - Protocol Translation", draft-miyata-v6ops-snatpt-02 (work in progress), September 2008. [I-D.wing-behave-nat64-referrals] Wing, D., "Referrals Across a NAT64", draft-wing-behave-nat64-referrals-00 (work in progress), March 2009. [I-D.xli-behave-ivi] Li, X., Chen, M., Bao, C., Zhang, H., and J. Wu, "Prefix- specific and Stateless Address Mapping (IVI) for IPv4/IPv6 Coexistence and Transition", draft-xli-behave-ivi-01 (work in progress), February 2009. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Li, et al. Expires October 24, 2009 [Page 17] Internet-Draft IPv4/IPv6 Prefix April 2009 Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. Authors' Addresses Xing Li (editor) CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China Phone: +86 62785983 Email: xing@cernet.edu.cn Li, et al. Expires October 24, 2009 [Page 18] Internet-Draft IPv4/IPv6 Prefix April 2009 Congxiao Bao (editor) CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China Phone: +86 62785983 Email: congxiao@cernet.edu.cn Fred Baker (editor) Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Li, et al. Expires October 24, 2009 [Page 19]