doc: Add RFC documents

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]
+