summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6052.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6052.txt')
-rw-r--r--doc/rfc/rfc6052.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc6052.txt b/doc/rfc/rfc6052.txt
new file mode 100644
index 0000000..5b43898
--- /dev/null
+++ b/doc/rfc/rfc6052.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Bao
+Request for Comments: 6052 CERNET Center/Tsinghua University
+Updates: 4291 C. Huitema
+Category: Standards Track Microsoft Corporation
+ISSN: 2070-1721 M. Bagnulo
+ UC3M
+ M. Boucadair
+ France Telecom
+ X. Li
+ CERNET Center/Tsinghua University
+ October 2010
+
+
+ IPv6 Addressing of IPv4/IPv6 Translators
+
+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 is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6052.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 1]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 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 Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5
+ 2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
+ 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7
+ 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7
+ 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8
+ 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
+ 3.3. Choice of Prefix for Stateless Translation Deployments . . 9
+ 3.4. Choice of Prefix for Stateful Translation Deployments . . 11
+ 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
+ 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14
+ 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15
+ 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 2]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+1. Introduction
+
+ This document is part of a series of IPv4/IPv6 translation documents.
+ A framework for IPv4/IPv6 translation is discussed in
+ [v4v6-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 provides a summary of the discussions behind two specific
+ design decisions, the choice of a null suffix and the specific value
+ of the selected prefix.
+
+ Section 5 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 the
+ 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.
+
+
+
+
+
+Bao, et al. Standards Track [Page 3]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+1.2. Conventions
+
+ 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].
+
+1.3. Terminology
+
+ This document makes use of the following terms:
+
+ 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 [DNS64]) and possibly other types of
+ Application Layer Gateways (ALGs).
+
+ 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-embedded IPv6 addresses: IPv6 addresses in which 32 bits
+ contain an IPv4 address. Their format is described in
+ Section 2.2.
+
+ 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, meaning that per-flow state is created when the first
+ packet in a flow is received.
+
+ 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.
+
+ Network-Specific Prefix: an IPv6 prefix assigned by an organization
+ for use in algorithmic mapping. Options for the Network-Specific
+ Prefix are discussed in Sections 3.3 and 3.4.
+
+ Well-Known Prefix: the IPv6 prefix defined in this document for use
+ in an algorithmic mapping.
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 4]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+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
+ 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---------|
+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ |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
+ Prefix 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 trade-off between different prefix lengths
+ are discussed in Sections 3.3 and 3.4.
+
+
+
+
+
+Bao, et al. Standards Track [Page 5]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ 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 4 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:
+
+ 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. Address translators who receive IPv4-
+ embedded IPv6 addresses where these bits are not zero SHOULD ignore
+ the bits' value and proceed as if the bits' value were zero. (Future
+ extensions may specify a different behavior.)
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 6]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+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
+ 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 (bits 64 to 71), 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 bits long, extract the last 32 bits of the
+ IPv6 address;
+
+ o For the other prefix lengths, remove the "u" octet to obtain a
+ 120-bit sequence (effectively shifting bits 72-127 to positions
+ 64-119), 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 Tables 1 and 2.
+
+ +-----------------------+------------+------------------------------+
+ | 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
+
+
+
+
+
+Bao, et al. Standards Track [Page 7]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ +-------------------+--------------+----------------------------+
+ | 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]. The representation of IPv6 addresses is
+ compatible with [RFC5952].
+
+3. Deployment Guidelines
+
+3.1. Restrictions on the Use of the Well-Known Prefix
+
+ The Well-Known Prefix MUST NOT be used to represent non-global IPv4
+ addresses, such as those defined in [RFC1918] or listed in Section 3
+ of [RFC5735]. Address translators MUST NOT translate packets in
+ which an address is composed of the Well-Known Prefix and a non-
+ global IPv4 address; they MUST drop these packets.
+
+ The Well-Known Prefix SHOULD NOT be used to construct IPv4-
+ translatable IPv6 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 advertised 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.
+
+ The Well-Known Prefix MAY be used by organizations deploying
+ translation services, as explained in Section 3.4.
+
+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
+ according to inter-domain routing policies, e.g., through
+
+
+
+
+
+Bao, et al. Standards Track [Page 8]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ configuration of BGP [RFC4271]. Organizations that advertise 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, IPv4-
+ embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
+ advertised in BGP (especially External BGP) [RFC4271] because this
+ leads to importing the IPv4 routing table into the IPv6 one and
+ therefore introduces 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
+ 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 (i.e., "most specific match wins") will then
+ ensure that the IPv6 packets are delivered directly, without
+ requiring that translators receive the packets and then return them
+ in the direction from which they came.
+
+
+
+Bao, et al. Standards Track [Page 9]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ 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 5 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 for IPv4
+ subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. 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, are more efficient when
+ performed on the combination of the prefix and the IPv4 address. In
+ theory, routers are able to route on prefixes of any length, but in
+ practice there may be routers for which routing on prefixes larger
+ than 64 bits is slower. However, 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-zero identifiers.
+
+
+
+Bao, et al. Standards Track [Page 10]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ 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 lead to an all-zero interface identifier, which is an
+ issue that we discuss in Section 4.1.
+
+ 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 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 [v4v6-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), an ISP holding a /32
+ allocation SHOULD use a /40 prefix, and a site holding a /48
+ allocation SHOULD use a /56 prefix.
+
+ o For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6
+ (an IPv4 network to an IPv6 network), the deployment SHOULD use a
+ /64 or a /96 prefix.
+
+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.
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 11]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ 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 the same prefix
+ coordinate their state.
+
+ Stateful translation can be used in scenarios defined in
+ [v4v6-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 (for example, a /96 prefix) MUST be used
+ in that scenario.
+
+4. Design Choices
+
+ The prefix that we have chosen reflects two design choices, the null
+ suffix and the specific value of the Well-Known Prefix. We provide
+ here a summary of the discussions leading to those two choices.
+
+4.1. 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-
+ 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
+
+
+
+Bao, et al. Standards Track [Page 12]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ 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, i.e., selecting a prefix whose one's
+ complement checksum equals either 0 or 0xffff.
+
+ 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 is only
+ one node with an IPv4-translatable IPv6 address in the /64 subnet, so
+ the anycast semantic does 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.
+
+4.2. 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, or
+
+ o 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 Mac OS generate IPv4 packets, but will not
+ send IPv6 packets. If we used the IPv4-mapped prefix, these nodes
+ 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, i.e., decided to not reuse the IPv4-
+ mapped prefix, ::ffff:0:0/96.
+
+
+
+Bao, et al. Standards Track [Page 13]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+ 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 Session
+ Traversal Utilities for NAT (STUN) [RFC5389] 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 the 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.
+
+5. Security Considerations
+
+5.1. Protection against Spoofing
+
+ IPv4/IPv6 translators can be modeled as special routers, are subject
+ to the same risks, and can implement the same mitigations. (The
+ discussion of generic threats to routers and their mitigations is
+ beyond the scope of this document.) 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
+ throughout the network that packets are coming from an authorized
+ location.
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 14]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+5.2. Secure Configuration
+
+ The prefixes used for address translation are used by IPv6 nodes to
+ send packets to IPv6/IPv4 translators. Attackers could attempt to
+ fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
+ values for these parameters, resulting in network disruption, denial
+ of service, and possible information disclosure. To mitigate such
+ attacks, network administrators need to ensure that prefixes are
+ configured in a secure way.
+
+ The mechanisms for achieving secure configuration of prefixes are
+ beyond the scope of this document.
+
+5.3. Firewall Configuration
+
+ Many firewalls and other security devices filter traffic based on
+ IPv4 addresses. Attackers could attempt to fool these firewalls by
+ sending IPv6 packets to or from IPv6 addresses that translate to the
+ filtered IPv4 addresses. If the attack is successful, traffic that
+ was previously blocked might be able to pass through the firewalls
+ disguised as IPv6 packets. In all such scenarios, administrators
+ should assure that packets that send to or from IPv4-embedded IPv6
+ addresses are subject to the same filtering as those directly sent to
+ or from the embedded IPv4 addresses.
+
+ The mechanisms for configuring firewalls and security devices to
+ achieve this filtering are beyond the scope of this document.
+
+6. IANA Considerations
+
+ IANA has made the following changes in the "Internet Protocol Version
+ 6 Address Space" registry located at http://www.iana.org.
+
+ OLD:
+
+ IPv6 Prefix Allocation Reference Note
+ ----------- ---------------- ------------ ----------------
+ 0000::/8 Reserved by IETF [RFC4291] [1][5]
+
+ NEW:
+
+ IPv6 Prefix Allocation Reference Note
+ ----------- ---------------- ------------ ----------------
+ 0000::/8 Reserved by IETF [RFC4291] [1][5][6]
+
+ [6] 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 RFC 6052.
+
+
+
+Bao, et al. Standards Track [Page 15]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+7. Acknowledgements
+
+ Many people in the BEHAVE WG have contributed to the discussion that
+ led to this document, including Andrew Sullivan, Andrew Yourtchenko,
+ Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler,
+ David Harrington, 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.
+
+8. Contributors
+
+ The following individuals co-authored documents from which text has
+ been incorporated, and are listed in alphabetical order.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 16]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+
+
+9. References
+
+9.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.
+
+9.2. Informative References
+
+ [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
+ "DNS64: DNS extensions for Network Address Translation
+ from IPv6 Clients to IPv4 Servers", Work in Progress,
+ October 2010.
+
+ [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.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ October 2008.
+
+ [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+ BCP 153, RFC 5735, January 2010.
+
+ [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+ Address Text Representation", RFC 5952, August 2010.
+
+ [v4v6-FRAMEWORK]
+ Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation", Work in Progress, August 2010.
+
+
+
+
+
+
+
+
+Bao, et al. Standards Track [Page 17]
+
+RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 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
+ 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
+
+
+ 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. Standards Track [Page 18]
+