From: Automatic Updater Date: Sat, 10 Apr 2010 01:14:32 +0000 (+0000) Subject: sync X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=bd0084c1fb7d2d8d498f6f19b111f4a426aa6fa9;p=thirdparty%2Fbind9.git sync --- diff --git a/doc/draft/draft-ietf-behave-address-format-06.txt b/doc/draft/draft-ietf-behave-address-format-06.txt deleted file mode 100644 index 0c06166ff4e..00000000000 --- a/doc/draft/draft-ietf-behave-address-format-06.txt +++ /dev/null @@ -1,1009 +0,0 @@ - - - -Network Working Group C. Bao -Internet-Draft CERNET Center/Tsinghua University -Obsoletes: 2765 (if approved) C. Huitema -Updates: 4291 (if approved) Microsoft Corporation -Intended status: Standards Track M. Bagnulo -Expires: September 28, 2010 UC3M - M. Boucadair - France Telecom - X. Li - CERNET Center/Tsinghua University - March 27, 2010 - - - IPv6 Addressing of IPv4/IPv6 Translators - draft-ietf-behave-address-format-06.txt - -Abstract - - This document discusses the algorithmic translation of an IPv6 - address to a corresponding IPv4 address, and vice versa, using only - statically configured information. It defines a well-known prefix - for use in algorithmic translations, while allowing organizations to - also use network-specific prefixes when appropriate. Algorithmic - translation is used in IPv4/IPv6 translators, as well as other types - of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. - -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 September 28, 2010. - - - -Bao, et al. Expires September 28, 2010 [Page 1] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - -Copyright Notice - - Copyright (c) 2010 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 BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 - 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4 - 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 - 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4 - 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6 - 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6 - 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7 - 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7 - 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 - 3.3. Choice of Prefix for Stateless Translation Deployments . . 8 - 3.4. Choice of Prefix for Stateful Translation Deployments . . 11 - 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11 - 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 - 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 - - - - - - - -Bao, et al. Expires September 28, 2010 [Page 2] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - -1. Introduction - - This document is part of a series of IPv4/IPv6 translation documents. - A framework for IPv4/IPv6 translation is discussed in - [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios - that will be used in this document. Other documents specify the - behavior of various types of translators and gateways, including - mechanisms for translating between IP headers and other types of - messages that include IP addresses. This document specifies how an - individual IPv6 address is translated to a corresponding IPv4 - address, and vice versa, in cases where an algorithmic mapping is - used. While specific types of devices are used herein as examples, - it is the responsibility of the specification of such devices to - reference this document for algorithmic mapping of the addresses - themselves. - - Section 2 describes the prefixes and the format of "IPv4-Embedded - IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an - IPv4 address. This format is common to both "IPv4-Converted" and - "IPv4-Translatable" IPv6 addresses. This section also defines the - algorithms for translating addresses, and the text representation of - IPv4-Embedded IPv6 addresses. - - Section 3 discusses the choice of prefixes, the conditions in which - they can be used, and the use of IPv4-Embedded IPv6 addresses with - stateless and stateful translation. - - Section 4 discusses security concerns. - - In some scenarios, a dual-stack host will unnecessarily send its - traffic through an IPv6/IPv4 translator. This can be caused by - host's default address selection algorithm [RFC3484], referrals, or - other reasons. Optimizing these scenarios for dual-stack hosts is - for future study. - -1.1. Applicability Scope - - This document is part of a series defining address translation - services. We understand that the address format could also be used - by other interconnection methods between IPv6 and IPv4, e.g., methods - based on encapsulation. If encapsulation methods are developed by - the IETF, we expect that their descriptions will document their - specific use of IPv4-Embedded IPv6 addresses. - -1.2. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Bao, et al. Expires September 28, 2010 [Page 3] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3. Terminology - - This document makes use of the following terms: - - IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 - packets, and vice versa. It may do "stateless" translation, - meaning that there is no per-flow state required, or "stateful" - translation where per-flow state is created when the first packet - in a flow is received. - Address translator: any entity that has to derive an IPv4 address - from an IPv6 address or vice versa. This applies not only to - devices that do IPv4/IPv6 packet translation, but also to other - entities that manipulate addresses, such as name resolution - proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other - types of Application Layer Gateways (ALGs). - Well-Known Prefix: the IPv6 prefix defined in this document for use - in an algorithmic mapping. - Network-Specific Prefix: an IPv6 prefix assigned by an organization - for use in algorithmic mapping. Options for the Network Specific - Prefix are discussed in Section 3.3 and Section 3.4. - IPv4-Embedded IPv6 addresses: IPv6 addresses in which 32 bits - contain an IPv4 address. Their format is described in - Section 2.2. - IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4 - nodes in an IPv6 network. They are a variant of IPv4-Embedded - IPv6 addresses, and follow the format described in Section 2.2. - IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6 - nodes for use with stateless translation. They are a variant of - IPv4-Embedded IPv6 addresses, and follow the format described in - Section 2.2. - - -2. IPv4-Embedded IPv6 Address Prefix and Format - -2.1. Well Known Prefix - - This document reserves a "Well-Known Prefix" for use in an - algorithmic mapping. The value of this IPv6 prefix is: - - 64:FF9B::/96 - -2.2. IPv4-Embedded IPv6 Address Format - - IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses - follow the same format, described here as the IPv4-Embedded IPv6 - address Format. IPv4-Embedded IPv6 addresses are composed of a - - - -Bao, et al. Expires September 28, 2010 [Page 4] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - variable length prefix, the embedded IPv4 address, and a variable - length suffix, as presented in the following diagram, in which PL - designates the prefix length: - - - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |32| prefix |v4(32) | u | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |40| prefix |v4(24) | u |(8)| suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |48| prefix |v4(16) | u | (16) | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |56| prefix |(8)| u | v4(24) | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |64| prefix | u | v4(32) | suffix | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |96| prefix | v4(32) | - +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - Figure 1 - - In these addresses, the prefix shall be either the "Well-Known - Prefix", or a "Network-Specific Prefix" unique to the organization - deploying the address translators. The prefixes can only have one of - the following lengths: 32, 40, 48, 56, 64 or 96. (The Well-Known - prefic is 96 bits long, and can only be used in the last form of the - table.) - - Various deployments justify different prefix lengths with Network- - Specific prefixes. The tradeoff between different prefix lengths are - discussed in Section 3.3 and Section 3.4. - - Bits 64 to 71 of the address are reserved for compatibility with the - host identifier format defined in the IPv6 addressing architecture - [RFC4291]. These bits MUST be set to zero. When using a /96 - Network-Specific Prefix, the administrators MUST ensure that the bits - 64 to 71 are set to zero. A simple way to achieve that is to - construct the /96 Network-Specific Prefix by picking a /64 prefix, - and then adding four octets set to zero. - - The IPv4 address is encoded following the prefix, most significant - bits first. Depending of the prefix length, the 4 octets of the - address may be separated by the reserved octet "u", whose 8 bits MUST - be set to zero. In particular: - - - - -Bao, et al. Expires September 28, 2010 [Page 5] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - o When the prefix is 32 bits long, the IPv4 address is encoded in - positions 32 to 63. - o When the prefix is 40 bits long, 24 bits of the IPv4 address are - encoded in positions 40 to 63, with the remaining 8 bits in - position 72 to 79. - o When the prefix is 48 bits long, 16 bits of the IPv4 address are - encoded in positions 48 to 63, with the remaining 16 bits in - position 72 to 87. - o When the prefix is 56 bits long, 8 bits of the IPv4 address are - encoded in positions 56 to 63, with the remaining 24 bits in - position 72 to 95. - o When the prefix is 64 bits long, the IPv4 address is encoded in - positions 72 to 103. - o When the prefix is 96 bits long, the IPv4 address is encoded in - positions 96 to 127. - - There are no remaining bits, and thus no suffix, if the prefix is 96 - bits long. In the other cases, the remaining bits of the address - constitute the suffix. These bits are reserved for future - extensions, and SHOULD be set to zero. - -2.3. Address Translation Algorithms - - IPv4-Embedded IPv6 addresses are composed according to the following - algorithm: - o Concatenate the prefix, the 32 bits of the IPv4 address and the - null suffix if needed to obtain a 128 bit address. - o If the prefix length is less than 96 bits, insert the null octet - "u" at the appropriate position, thus causing the least - significant octet to be excluded, as documented in Figure 1. - - The IPv4 addresses are extracted from the IPv4-Embedded IPv6 - addresses according to the following algorithm: - o If the prefix is 96 bit long, extract the last 32 bits of the IPv6 - address; - o for the other prefix lengths, extract the "u" octet to obtain a - 120 bit sequence, then extract the 32 bits following the prefix. - -2.4. Text Representation - - IPv4-Embedded IPv6 addresses will be represented in text in - conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6 - addresses constructed using the Well-Known Prefix or a /96 Network- - Specific Prefix may be represented using the alternative form - presented in section 2.2 of [RFC4291], with the embedded IPv4 address - represented in dotted decimal notation. Examples of such - representations are presented in Table 1 and Table 2. - - - - -Bao, et al. Expires September 28, 2010 [Page 6] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - +-----------------------+------------+------------------------------+ - | Network-Specific | IPv4 | IPv4-Embedded IPv6 address | - | Prefix | address | | - +-----------------------+------------+------------------------------+ - | 2001:DB8::/32 | 192.0.2.33 | 2001:DB8:C000:221:: | - | 2001:DB8:100::/40 | 192.0.2.33 | 2001:DB8:1C0:2:21:: | - | 2001:DB8:122::/48 | 192.0.2.33 | 2001:DB8:122:C000:2:2100:: | - | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221:: | - | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: | - | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 | - +-----------------------+------------+------------------------------+ - - Table 1: Text representation of IPv4-Embedded IPv6 addresses using - Network-Specific Prefixes - - +-------------------+--------------+----------------------------+ - | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | - +-------------------+--------------+----------------------------+ - | 64:FF9B::/96 | 192.0.2.33 | 64:FF9B::192.0.2.33 | - +-------------------+--------------+----------------------------+ - - Table 2: Text representation of IPv4-Embedded IPv6 addresses using - the Well-Known Prefix - - The Network-Specific Prefix examples in Table 1 are derived from the - IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 - address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for - documentation in [RFC5735]. - - -3. Deployment Guidelines and Choices - -3.1. Restrictions on the use of the Well-Known Prefix - - The Well-Known Prefix MAY be used by organizations deploying - translation services, as explained in Section 3.4. - - The Well-Known Prefix SHOULD NOT be used to construct IPv4- - Translatable addresses. The nodes served by IPv4-Translatable IPv6 - addresses should be able to receive global IPv6 traffic bound to - their IPv4-Translatable IPv6 address without incurring intermediate - protocol translation. This is only possible if the specific prefix - used to build the IPv4-Translatable IPv6 addresses is advertized in - inter-domain routing, but the advertisement of more specific prefixes - derived from the Well-Known Prefix is not supported, as explained in - Section 3.2. Network-Specific Prefixes SHOULD be used in these - scenarios, as explained in Section 3.3. - - - - -Bao, et al. Expires September 28, 2010 [Page 7] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - The Well-Known Prefix MUST NOT be used to represent non global IPv4 - addresses, such as those defined in [RFC1918]. - -3.2. Impact on Inter-Domain Routing - - The Well-Known Prefix MAY appear in inter-domain routing tables, if - service providers decide to provide IPv6-IPv4 interconnection - services to peers. Advertisement of the Well-Known Prefix SHOULD be - controlled either by upstream and/or downstream service providers - owing to inter-domain routing policies, e.g., through configuration - of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix - in inter-domain routing MUST be able to provide IPv4/IPv6 translation - service. - - When the IPv4/IPv6 translation relies on the Well-Known Prefix, - embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be - advertised in BGP (especially e-BGP) [RFC4271] because this leads to - importing the IPv4 routing table into the IPv6 one and therefore - induces scalability issues to the global IPv6 routing table. - Administrators of BGP nodes SHOULD configure filters that discard - advertisements of embedded IPv6 prefixes longer than the Well-Known - Prefix. - - When the IPv4/IPv6 translation service relies on Network-Specific - Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless - translation MUST be advertised with proper aggregation to the IPv6 - Internet. Similarly, if translators are configured with multiple - Network-Specific Prefixes,these prefixes MUST be advertised to the - IPv6 Internet with proper aggregation. - -3.3. Choice of Prefix for Stateless Translation Deployments - - Organizations may deploy translation services using stateless - translation. In these deployments, internal IPv6 nodes are addressed - using IPv4-Translatable IPv6 addresses, which enable them to be - accessed by IPv4 nodes. The addresses of these external IPv4 nodes - are then represented in IPv4-Converted IPv6 addresses. - - Organizations deploying stateless IPv4/IPv6 translation SHOULD assign - a Network-Specific Prefix to their IPv4/IPv6 translation service. - IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be - constructed as specified in Section 2.2. IPv4-Translatable IPv6 - addresses MUST use the selected Network-Specific Prefix. Both IPv4- - Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD - use the same prefix. - - Using the same prefix ensures that IPv6 nodes internal to the - organization will use the most efficient paths to reach the nodes - - - -Bao, et al. Expires September 28, 2010 [Page 8] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - served by IPv4-Translatable IPv6 addresses. Specifically, if a node - learns the IPv4 address of a target internal node without knowing - that this target is in fact located behind the same translator that - the node also uses, translation rules will ensure that the IPv6 - address constructed with the Network-Specific prefix is the same as - the IPv4-Translatable IPv6 address assigned to the target. Standard - routing preference (more specific wins) will then ensure that the - IPv6 packets are delivered directly, without requiring "hair-pinning" - at the translator. - - The intra-domain routing protocol must be able to deliver packets to - the nodes served by IPv4-Translatable IPv6 addresses. This may - require routing on some or all of the embedded IPv4 address bits. - Security considerations detailed in Section 4 require that routers - check the validity of the IPv4-Translatable IPv6 source addresses, - using some form of reverse path check. - - The management of stateless address translation can be illustrated - with a small example. We will consider an IPv6 network with the - prefix 2001:DB8:122::/48. The network administrator has selected the - Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless - IPv4/IPv6 translation. The IPv4-Translatable address block is 2001: - DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet - 192.0.2.0/24. In this network, the host A is assigned the IPv4- - Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which - corresponds to the IPv4 address 192.0.2.33. Host A's address is - configured either manually or through DHCPv6. - - In this example, host A is not directly connected to the translator, - but instead to a link managed by a router R. The router R is - configured to forward to A the packets bound to 2001:DB8:122:344:C0: - 2:2100::. To receive these packets, R will advertise reachability of - the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain - routing protocol -- or perhaps a shorter prefix if many hosts on link - have IPv4-Translatable IPv6 addresses derived from the same IPv4 - subnet. If a packet bound to 192.0.2.33 reaches the translator, the - destination address will be translated to 2001:DB8:122:344:C0:2: - 2100::, and the packet will be routed towards R and then to A. - - Let's suppose now that a host B of the same domain learns the IPv4 - address of A, maybe through an application-specific referral. If B - has translation-aware software, B can compose a destination address - by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and - the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122: - 344:C0:2:2100::. The packet sent by B will be forwarded towards R, - and then to A, avoiding protocol translation. - - Forwarding, and reverse path checks, should be performed on the - - - -Bao, et al. Expires September 28, 2010 [Page 9] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - combination of the prefix and the IPv4 address. In theory, routers - should be able to route on prefixes of any length. However, routing - on prefixes larger than 64 bits may be slower on some routers. But - routing efficiency is not the only consideration in the choice of a - prefix length. Organizations also need to consider the availability - of prefixes, and the potential impact of all-zeroes identifiers. - - If a /32 prefix is used, all the routing bits are contained in the - top 64 bits of the IPv6 address, leading to excellent routing - properties. These prefixes may however be hard to obtain, and - allocation of a /32 to a small set of IPv4-Translatable IPv6 - addresses may be seen as wasteful. In addition, the /32 prefix and a - zero suffix leads to an all-zeroes interface identifier, an issue - that we discuss in Section 3.5. - - Intermediate prefix lengths such as /40, /48 or /56 appear as - compromises. Only some of the IPv4 bits are part of the /64 - prefixes. Reverse path checks, in particular, may have a limited - efficiency. Reverse path checks limited to the most significant bits - of the IPv4 address will reduce the possibility of spoofing external - IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- - Translatable IPv6 addresses. - - We propose here a compromise, based on using no more than 1/256th of - an organization's allocation of IPv6 addresses for the IPv4/IPv6 - translation service. For example, if the organization is an Internet - Service Provider with an allocated IPv6 prefix /32 or shorter, the - ISP could dedicate a /40 prefix to the translation service. An end - site with a /48 allocation could dedicate a /56 prefix to the - translation service, or possibly a /96 prefix if all IPv4- - Translatable IPv6 addresses are located on the same link. - - The recommended prefix length is also a function of the deployment - scenario. The stateless translation can be used for Scenario 1, - Scenario 2, Scenario 5, and Scenario 6 defined in - [I-D.ietf-behave-v6v4-framework]. For different scenarios, the - prefix length recommendations are: - o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario - 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 - prefix for an ISP holding a /32 allocation, and a /56 prefix for a - site holding a /48 allocation. - o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 - (an IPv4 network to an IPv6 network), we recommend using a /64 or - a /96 prefix. - - IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address - architecture and SHOULD be compatible with the IPv4 address - architecture. The first IPv4-translatable address is the subnet- - - - -Bao, et al. Expires September 28, 2010 [Page 10] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - router anycast address in IPv6 and network identifier in IPv4, the - last IPv4-translatable address is the subnet broadcast addresses in - IPv4. Both of them SHOULD NOT be used for IPv6 nodes. In addition, - the minimum IPv4 subnet can be used for hosts is /30 (the router - interface needs a valid address for the same subnet) and this rule - SHOULD also be applied to the corresponding subnet of the IPv4- - translatable addresses. - -3.4. Choice of Prefix for Stateful Translation Deployments - - Organizations may deploy translation services based on stateful - translation technology. An organization may decide to use either a - Network-Specific Prefix or the Well-Known Prefix for its stateful - IPv4/IPv6 translation service. - - When these services are used, IPv6 nodes are addressed through - standard IPv6 addresses, while IPv4 nodes are represented by IPv4- - Converted IPv6 addresses, as specified in Section 2.2. - - The stateful nature of the translation creates a potential stability - issue when the organization deploys multiple translators. If several - translators use the same prefix, there is a risk that packets - belonging to the same connection may be routed to different - translators as the internal routing state changes. This issue can be - avoided either by assigning different prefixes to different - translators, or by ensuring that all translators using same prefix - coordinate their state. - - Stateful translation can be used in scenarios defined in - [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be - used in these scenarios, with two exceptions: - o In all scenarios, the translation MAY use a Network-Specific - Prefix, if deemed appropriate for management reasons. - o The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 - Internet to an IPv4 network), as this would lead to using the - Well-Known Prefix with non-global IPv4 addresses. That means a - Network-Specific Prefix MUST be used in that scenario, for example - a /96 prefix compatible with the Well-Known prefix format. - -3.5. Choice of Suffix - - The address format described in Section 2.2 recommends a zero suffix. - Before making this recommendation, we considered different options: - checksum neutrality; the encoding of a port range; and a value - different than 0. - - In the case of stateless translation, there would be no need for the - translator to recompute a one's complement checksum if both the IPv4- - - - -Bao, et al. Expires September 28, 2010 [Page 11] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - Translatable and the IPv4-Converted IPv6 addresses were constructed - in a "checksum-neutral" manner, that is if the IPv6 addresses would - have the same one's complement checksum as the embedded IPv4 address. - In the case of stateful translation, checksum neutrality does not - eliminate checksum computation during translation, as only one of the - two addresses would be checksum neutral. We considered reserving 16 - bits in the suffix to guarantee checksum neutrality, but declined - because it would not help with stateful translation, and because - checksum neutrality can also be achieved by an appropriate choice of - the Network-Specific Prefix, as was done for example with the Well- - Known Prefix. - - There have been proposals to complement stateless translation with a - port-range feature. Instead of mapping an IPv4 address to exactly - one IPv6 prefix, the options would allow several IPv6 nodes to share - an IPv4 address, with each node managing a different range of ports. - If a port range extension is needed, it could be defined later, using - bits currently reserved as null in the suffix. - - When a /32 prefix is used, an all-zero suffix results in an all-zero - interface identifier. We understand the conflict with Section 2.6.1 - of RFC4291, which specifies that all zeroes are used for the subnet- - router anycast address. However, in our specification, there would - be only one node with an IPv4-Translatable IPv6 address in the /64 - subnet, and the anycast semantic would not create confusion. We thus - decided to keep the null suffix for now. This issue does not exist - for prefixes larger than 32 bits, such as the /40, /56, /64 and /96 - prefixes that we recommend in Section 3.3. - -3.6. Choice of the Well-Known Prefix - - Before making our recommendation of the Well-Known Prefix, we were - faced with three choices: - o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC - 2765 Section 2.1; - o request IANA to allocate a /32 prefix, - o or request allocation of a new /96 prefix. - - We weighted the pros and cons of these choices before settling on the - recommended /96 Well-Known Prefix. - - The main advantage of the existing IPv4-mapped prefix is that it is - already defined. Reusing that prefix would require minimal - standardization efforts. However, being already defined is not just - an advantage, as there may be side effects of current - implementations. When presented with the IPv4-mapped prefix, current - versions of Windows and MacOS generate IPv4 packets, but will not - send IPv6 packets. If we used the IPv4-mapped prefix, these nodes - - - -Bao, et al. Expires September 28, 2010 [Page 12] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - would not be able to support translation without modification. This - will defeat the main purpose of the translation techniques. We thus - eliminated the first choice, and decided to not reuse the IPv4-mapped - prefix, ::FFFF:0:0/96. - - A /32 prefix would have allowed the embedded IPv4 address to fit - within the top 64 bits of the IPv6 address. This would have - facilitated routing and load balancing when an organization deploys - several translators. However, such destination-address based load - balancing may not be desirable. It is not compatible with STUN in - the deployments involving multiple stateful translators, each one - having a different pool of IPv4 addresses. STUN compatibility would - only be achieved if the translators managed the same pool of IPv4 - addresses and were able to coordinate their translation state, in - which case there is no big advantage to using a /32 prefix rather - than a /96 prefix. - - According to Section 2.2 of [RFC4291], in the legal textual - representations of IPv6 addresses, dotted decimal can only appear at - the end. The /96 prefix is compatible with that requirement. It - enables the dotted decimal notation without requiring an update to - [RFC4291]. This representation makes the address format easier to - use, and log files easier to read. - - The prefix that we recommend has the particularity of being "checksum - neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is - "FFFF", i.e. a value equal to zero in one's complement arithmetic. - An IPv4-Embedded IPv6 address constructed with this prefix will have - the same one's complement checksum as the embedded IPv4 address. - - -4. Security Considerations - -4.1. Protection Against Spoofing - - By and large, IPv4/IPv6 translators can be modeled as special - routers, are subject to the same risks, and can implement the same - mitigations. There is however a particular risk that directly - derives from the practice of embedding IPv4 addresses in IPv6: - address spoofing. - - An attacker could use an IPv4-Embedded IPv6 address as the source - address of malicious packets. After translation, the packets will - appear as IPv4 packets from the specified source, and the attacker - may be hard to track. If left without mitigation, the attack would - allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. - - The mitigation is to implement reverse path checks, and to verify - - - -Bao, et al. Expires September 28, 2010 [Page 13] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - throughout the network that packets are coming from an authorized - location. - -4.2. Secure Configuration - - The prefixes and formats need to be the configured consistently among - multiple devices in the same network (e.g., nodes that need to prefer - native over translated addresses, DNS gateways, and IPv4/IPv6 - translators). As such, the means by which they are learned/ - configured MUST be secure. Specifying a default prefix and/or format - in implementations provides one way to configure them securely. Any - alternative means of configuration is responsible for specifying how - to do so securely. - - -5. IANA Considerations - - The IANA is requested to add a note to the documentation of the - 0000::/8 address block in - http://www.iana.org/assignments/ipv6-address-space to document the - assignment by the IETF of the Well Known Prefix. For example: - - The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic - mapping between IPv4 to IPv6 addresses is defined out of the - 0000::/8 address block, per (this document). - - -6. Acknowledgements - - Many people in the Behave WG have contributed to the discussion that - led to this document, including Andrew Sullivan, Andrew Yourtchenko, - Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, - Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus - Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip - Matthews, Remi Denis-Courmont, Remi Despres and William Waites. - - Marcelo Bagnulo is partly funded by Trilogy, a research project - supported by the European Commission under its Seventh Framework - Program. - - -7. Contributors - - The following individuals co-authored drafts from which text has been - incorporated, and are listed in alphabetical order. - - - - - - -Bao, et al. Expires September 28, 2010 [Page 14] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - Congxiao Bao - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - Phone: +86 62785983 - Email: congxiao@cernet.edu.cn - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - Phone: +1 425 703 8835 - Email: dthaler@microsoft.com - - Fred Baker - Cisco Systems - Santa Barbara, California 93117 - USA - Phone: +1-408-526-4257 - Fax: +1-413-473-2403 - Email: fred@cisco.com - - Hiroshi Miyata - Yokogawa Electric Corporation - 2-9-32 Nakacho - Musashino-shi, Tokyo 180-8750 - JAPAN - Email: h.miyata@jp.yokogawa.com - - Marcelo Bagnulo - Universidad Carlos III de Madrid - Av. Universidad 30 - Leganes, Madrid 28911 - ESPANA - Email: marcelo@it.uc3m.es - - Xing Li - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - Phone: +86 62785983 - Email: xing@cernet.edu.cn - - - - - - -Bao, et al. Expires September 28, 2010 [Page 15] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -8.2. Informative References - - [I-D.ietf-behave-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-04 (work in progress), - December 2009. - - [I-D.ietf-behave-v6v4-framework] - Baker, F., Li, X., Bao, C., and K. Yin, "Framework for - IPv4/IPv6 Translation", - draft-ietf-behave-v6v4-framework-03 (work in progress), - October 2009. - - [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and - E. Lear, "Address Allocation for Private Internets", - BCP 5, RFC 1918, February 1996. - - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. - - [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix - Reserved for Documentation", RFC 3849, July 2004. - - [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway - Protocol 4 (BGP-4)", RFC 4271, January 2006. - - [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", - BCP 153, RFC 5735, January 2010. - - - - - - - - - - - -Bao, et al. Expires September 28, 2010 [Page 16] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - -Authors' Addresses - - Congxiao Bao - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - - Phone: +86 10-62785983 - Email: congxiao@cernet.edu.cn - - - Christian Huitema - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - U.S.A. - - Email: huitema@microsoft.com - - - Marcelo Bagnulo - UC3M - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6249500 - Fax: - Email: marcelo@it.uc3m.es - URI: http://www.it.uc3m.es/marcelo - - - Mohamed Boucadair - France Telecom - 3, Av Francois Chateaux - Rennes 350000 - France - - Email: mohamed.boucadair@orange-ftgroup.com - - - - - - - - - - - -Bao, et al. Expires September 28, 2010 [Page 17] - -Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010 - - - Xing Li - CERNET Center/Tsinghua University - Room 225, Main Building, Tsinghua University - Beijing, 100084 - China - - Phone: +86 10-62785983 - Email: xing@cernet.edu.cn - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bao, et al. Expires September 28, 2010 [Page 18] - -