[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-behave-translator-addressing) 00 01 02 03 04 05 06 07 08 09 10 RFC 6052

Network Working Group                                         C. Huitema
Internet-Draft                                     Microsoft Corporation
Obsoletes: 2765 (if approved)                                     C. Bao
Intended status: Standards Track       CERNET Center/Tsinghua University
Expires: June 20, 2010                                        M. Bagnulo
                                                                    UC3M
                                                            M. Boucadair
                                                          France Telecom
                                                                   X. Li
                                       CERNET Center/Tsinghua University
                                                       December 17, 2009


                IPv6 Addressing of IPv4/IPv6 Translators
                draft-ietf-behave-address-format-03.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 June 20, 2010.



Huitema, et al.           Expires June 20, 2010                 [Page 1]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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.  Notations  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  IPv4-Embedded IPv6 Address Format  . . . . . . . . . . . . . .  4
     2.1.  Address Translation Algorithms . . . . . . . . . . . . . .  6
     2.2.  Text Representation  . . . . . . . . . . . . . . . . . . .  6
   3.  Deployment Guidelines and Choices  . . . . . . . . . . . . . .  7
     3.1.  Restrictions to 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  . . 10
     3.5.  Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Choice of the Well-Known Prefix  . . . . . . . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     4.1.  Protection Against Spoofing  . . . . . . . . . . . . . . . 12
     4.2.  Secure Configuration . . . . . . . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15









Huitema, et al.           Expires June 20, 2010                 [Page 2]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


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.

   This document reserves a "Well-Known Prefix" for use in an
   algorithmic mapping.  The value of this IPv6 prefix is:

      64:FF9B::/96

   Section 2 describes 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
   addresses.

   Section 3 discusses the choice of prefixes, the conditions of use of
   the Well-Known Prefix and the Network Specific Prefixes, and the use
   of embedded addresses with stateless and stateful translation.

   Section 4 discusses security concerns.

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
   document are to be interpreted as described in RFC 2119 [RFC2119].



Huitema, et al.           Expires June 20, 2010                 [Page 3]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


1.3.  Notations

   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.
   IPv4-Converted IPv6 addresses:  IPv6 addresses used to represent IPv4
      hosts in an IPv6 network.  They are a variant of IPv4-Embedded
      addresses, and follow the format described in Section 2.
   IPv4-Translatable IPv6 addresses:  IPv6 addresses assigned to IPv6
      hosts for use with stateless translation.  They are a variant of
      IPv4-Embedded addresses, and follow the format described in
      Section 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:












Huitema, et al.           Expires June 20, 2010                 [Page 4]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


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

   Various deployments justify different prefix lengths.  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 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:
   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.




Huitema, et al.           Expires June 20, 2010                 [Page 5]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   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 a zero.

2.1.  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, remove the last octet
      insert the null octet "U" at the appropriate position, 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.2.  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.












Huitema, et al.           Expires June 20, 2010                 [Page 6]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


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

   The Network Specific Prefixes examples in Table 1 are derived from
   the IPv6 Prefix reserved for doocumentation in [RFC3849].  The IPv4
   address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
   documentation in [RFC3330].


3.  Deployment Guidelines and Choices

3.1.  Restrictions to 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 host served by IPv4-Translatable IPv6
   addresses should be able to receive 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, and this kind of specific prefix advertisement is not
   supported with the Well-Known Prefix as explained in Section 3.2.
   Network Specific Prefixes SHOULD be used in these scenarios, as
   explained in Section 3.3.




Huitema, et al.           Expires June 20, 2010                 [Page 7]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   The Well-Known Prefix MUST NOT be used to represent non global IPv4
   addresses, such as those defined in [RFC1918].  Doing so would
   introduce ambiguous IPv6 addresses.

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 address
   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 IPv4 routing table into IPv6 one and therefore induces
   scalability issues to the global IPv6 routing table.  Adjacent BGP
   speakers MUST ignore advertisements of embedded IPv6 prefixes longer
   than the Well-Known Prefix.  BGP speakers SHOULD be able to be
   configured with the default Well-Known Prefix.

   When the IPv4/IPv6 translation service relies on Network Specific
   Prefixes and stateless translation is used, the IPv4-Translatable
   IPv6 prefixes 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

   Organization may deploy translation services using stateless
   translation.  In these deployments, internal IPv6 hosts are addressed
   using "IPv4-Translatable" IPv6 addresses, which enable them to be
   accessed by IPv4 hosts.  The addresses of these external hosts 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" addresses MUST be
   constructed as specified in Section 2.  IPv4-Translatable IPv6
   addresses MUST use the selected Network Specific Prefix.  Both types
   of addresses SHOULD use the same prefix.

   Using the same prefix ensures that internal IPv6 hosts will use the
   most efficient paths to reach the hosts served by "IPv4-Translatable"



Huitema, et al.           Expires June 20, 2010                 [Page 8]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   addresses.  Specifically, if an internal host learns the IPv4 address
   of a target internal host without knowing that this target is in fact
   located behind the same translator, translation rules will ensure
   that the IPv6 address constructed with the network specific prefix is
   the same as the IPv4-Translatable address assigned to the target.
   Standard routing preference 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 hosts 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.

   Forwarding, and reverse path checks, should be performed on the
   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.  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 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 checks limited to the most significant bits of
   the IPv4 address will reduce the possibility of spoofing external
   IPv4 address, but would allow IPv6 hosts to spoof internal IPv4-
   Translatable 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 ISP,
   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.



Huitema, et al.           Expires June 20, 2010                 [Page 9]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   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.

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 hosts are addressed through
   standard IPv6 addresses, while IPv4 hosts are represented by IPv4-
   Converted addresses, as specified in Section 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
   mitigated 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 most 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 recommends a zero suffix.
   Before making this recommendation, we considered different options:



Huitema, et al.           Expires June 20, 2010                [Page 10]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   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 complement to 1 checksum if both the IPv4-
   Translatable addresses and the IPv4-Converted address were
   constructed in a "checksum-neutral" manner, that is if the IPv6
   addresses would have the some complement to 1 checksum as the
   embedded IPv4 address.  In the case of stateful translation, checksum
   neutrality does eliminate checksums 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, because checksum neutrality can also be achieved by an
   appropriate choice of the Network Specific Prefix.  The Well Known
   Prefix was chosen to provide checksum neutrality.

   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 hosts to share
   an IPv4 address, with each host managing a different range of ports.
   But these schemes are not yet specified in work group documents.  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 IPv4-Translatable node 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



Huitema, et al.           Expires June 20, 2010                [Page 11]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   already defined.  Reusing that prefix will require minimal
   standardization efforts.  However, being already defined is not just
   and 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 hosts
   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 complement to 1 arithmetic.  An
   IPv4-Embedded IPv6 address constructed with this prefix will have the
   same complement to 1 checksum as the embedded IPv4 address.


4.  Security Considerations

4.1.  Protection Against Spoofing

   By and large, address 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 address as the source address



Huitema, et al.           Expires June 20, 2010                [Page 12]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   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.

4.2.  Secure Configuration

   The prefixes and formats need to be the configured consistently among
   multiple devices in the same network (e.g., hosts 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 Well Known Prefix falls into the range ::/8 reserved by the IETF.
   The prefix definition does not require an IANA action.


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.






Huitema, et al.           Expires June 20, 2010                [Page 13]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


       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






Huitema, et al.           Expires June 20, 2010                [Page 14]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


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.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
              September 2002.

   [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.














Huitema, et al.           Expires June 20, 2010                [Page 15]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


Authors' Addresses

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399
   U.S.A.

   Email: huitema@microsoft.com


   Congxiao Bao
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   China

   Phone: +86 10-62785983
   Email: congxiao@cernet.edu.cn


   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











Huitema, et al.           Expires June 20, 2010                [Page 16]

Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators   December 2009


   Xing Li
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   China

   Phone: +86 10-62785983
   Email: xing@cernet.edu.cn











































Huitema, et al.           Expires June 20, 2010                [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/