Network Working Group                                         C. Huitema
Internet-Draft                                     Microsoft Corporation
Obsoletes: 2765 (if approved)                                     C. Bao
Intended status: Standards Track       CERNET Center/Tsinghua University
Expires: February 27, April 29, 2010                                       M. Bagnulo
                                                                    UC3M
                                                            M. Boucadair
                                                          France Telecom
                                                                   X. Li
                                       CERNET Center/Tsinghua University
                                                         August
                                                        October 26, 2009

                IPv6 Addressing of IPv4/IPv6 Translators
                draft-ietf-behave-address-format-00.txt
                draft-ietf-behave-address-format-01.txt

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 February 27, April 29, 2010.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document discusses how an individual IPv6 address can be
   algorithmically translated to a corresponding IPv4 address, and vice
   versa, using only statically configured information.  This technique
   is used in IPv4/IPv6 translators, as well as other types of proxies
   and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.1.  IPv6 Addresses Assigned to IPv6 Hosts  Applicability Scope  . . . . . . . . . .  4
     1.2.  IPv6 Addresses Used to Represent IPv4 Hosts  . . . . . . .  5
   2.  Prefix Selection . . . . . . .  3
     1.2.  Notations  . . . . . . . . . . . . . . . .  5
     2.1.  Requirements . . . . . . . .  3
   2.  IPv4 Embedded IPv6 Address Format  . . . . . . . . . . . . . .  4
   3.  Deployment Guidelines and Choices  .  5
       2.1.1.  IPv6 Routing System Scalability . . . . . . . . . . .  6
       2.1.2.  Native Connectivity Preference for Dual-Stack Nodes .  6
       2.1.3.  Referral Support .  5
     3.1.  Deployment Using the Well Known Prefix . . . . . . . . . .  5
     3.2.  Impact on Inter-Domain Routing . . . . . . . .  7
       2.1.4.  Support for Multiple IPv4/IPv6 Translators . . . . . .  7
       2.1.5.  Appropriate  6
     3.3.  Choice of Prefix Length  . . . . . . . . . . for Stateless Translation Deployments . .  6
     3.4.  Choice of Prefix for Stateful Translation Deployments  . .  8
       2.1.6.  Uniqueness .
     3.5.  Choice of Suffix . . . . . . . . . . . . . . . . . . . . .  9
     2.2.  Types  8
     3.6.  Choice of Prefixes  . . . . . . . the Well Known Prefix  . . . . . . . . . . . . .  9
       2.2.1.  Network-Specific Prefix  . . . .
   4.  Security Considerations  . . . . . . . . . . .  9
       2.2.2.  Well-Known Prefix . . . . . . . . 10
     4.1.  Protection Against Spoofing  . . . . . . . . . .  9
     2.3.  Scenario-Specific Discussion and Recommendations . . . . . 10
       2.3.1.  Scenario 1: an IPv6 network to the IPv4 Internet
     4.2.  Secure Configuration . . . 10
       2.3.2.  Scenario 2: the IPv4 Internet to an IPv6 network . . . 12
       2.3.3.  Scenario 3: the IPv6 Internet to an IPv4 network . . . 12
       2.3.4.  Scenario 4: an IPv4 network to the IPv6 Internet . . . 12
       2.3.5.  Scenario 5: an IPv6 network to an IPv4 network . . . . 12
       2.3.6.  Scenario 6: an IPv4 network to an IPv6 network . . . . 13
       2.3.7.  Scenario 7: the IPv6 Internet to the IPv4 Internet . 11
   5.  IANA Considerations  . 13
       2.3.8.  Scenario 8: the IPv4 Internet to the IPv6 Internet . . 13
   3.  IPv6 Address Format and Translation Algorithms . . . . . . . . 13
     3.1.  Requirements . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . 13
     3.2.  Mechanisms . . . . . . . . . . 11
   7.  Contributors . . . . . . . . . . . . . . 15
       3.2.1.  IPv4-Mapped IPv6 Addresses . . . . . . . . . . . 11
   8.  References . . . 15
       3.2.2.  IPv4-Translatable Addresses . . . . . . . . . . . . . 15
       3.2.3.  Zero-Pad And Embed . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . 16
       3.2.4.  Compensation-Pad And Embed . . . . . . . . . . . 13
     8.2.  Informative References . . . 16
       3.2.5.  Embed And Zero-Pad . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . 17
       3.2.6.  Preconfigured Mapping Table . . . . . . . . . . . . . 18
     3.3.  Scenario-Specific Discussion and Recommendations . . . . . 18
       3.3.1.  Scenario 1: an IPv6 network to the IPv4 Internet . . . 18
       3.3.2.  Scenario 2: 14

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 IPv4 Internet to an IPv6 network . . . 18
       3.3.3.  Scenario 3: the IPv6 Internet to an IPv4 network . . . 18
       3.3.4.  Scenario 4: an IPv4 network to the IPv6 Internet . . . 18
       3.3.5.  Scenario 5: an IPv6 network to an IPv4 network . . . . 19
       3.3.6.  Scenario 6: an IPv4 network to an IPv6 network . . . . 19
       3.3.7.  Scenario 7: the IPv6 Internet to the IPv4 Internet . . 19
       3.3.8.  Scenario 8: the IPv4 Internet to the IPv6 Internet . . 19
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

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.baker-behave-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.

   In this document, an "IPv4/IPv6 translator" is 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.

   In this document, an "address translator" is 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.bagnulo-behave-dns64]) and
   possibly other types of Application Layer Gateways (ALGs).

   [OPEN ISSUE: addressing for encapsulation mechanisms such as Dual-
   Stack Lite, including use of port ranges, is currently treated as out
   of scope for this document.  Should such addressing be in scope?]

   In choosing a mapping between IPv4 and IPv6 addresses for a given
   scenario, there are two separate choices to make: choosing an IPv6
   prefix, and choosing an algorithm for constructing the remainder of
   the IPv6 address.  These two topics are covered in Section 2 and
   Section 3, respectively.

   Algorithmic derivation of an IPv4 address from an IPv6 address, or
   vice versa, is used with two different classes of IPv6 addresses,
   discussed in Section 1.1 and Section 1.2.

1.1.  IPv6 Addresses Assigned to IPv6 Hosts

   In an IPv6 network, IPv6 addresses are assigned to IPv6 hosts, and
   these IPv6 addresses need to be translated to IPv4 addresses that can
   be used by IPv4 hosts.  Such IPv4 addresses are not assigned to a
   host, but packets destined to such addresses must be routed to an
   appropriate IPv4/IPv6 translator that handles a set of such IPv4
   addresses.  Thus, stateless address translation mechanisms typically
   put constraints on what IPv6 addresses can be assigned to IPv6 hosts
   that want to communicate with IPv4 destinations using an algorithmic
   mapping (although such hosts may have other IPv6 addresses used for
   other purposes such as link-local communication).  Without such
   constraints, stateful translation on such addresses must be done
   instead, which typically only supports initiation from the IPv6 side,
   and does not result in stable addresses that can be used in DNS and
   other protocols and applications that do not deal well with highly
   dynamic addresses.

   IPv6 addresses assigned to IPv6 hosts for use with stateless
   translation are referred to as "IPv4-translatable" IPv6 addresses in
   [RFC2765] although that term is also used to refer to a specific
   address format (defined in [RFC2765] section 2.1) and hence we avoid
   the use of this term herein except when referring to the specific
   IPv6 address format.

1.2.  IPv6 Addresses Used to Represent IPv4 Hosts

   In an IPv4 network, IPv4 addresses are assigned to IPv4 hosts, and
   these IPv4 addresses need to be translated to IPv6 addresses that can
   be used by IPv6 hosts.  Such IPv6 addresses are not assigned to a
   host, but packets destined to such addresses are routed to an
   appropriate IPv4/IPv6 translator that handles a set of such IPv6
   addresses.  Typically, there are no additional constraints put on the
   IPv4 addresses.  Unlike the addresses discussed in Section 1.1,
   algorithmic mapping of IPv6 addresses used to represent IPv4 hosts is
   used with both stateful and stateless translation.

   IPv6 addresses used to represent IPv4 hosts are referred to as "IPv4-
   mapped" IPv6 addresses in [RFC2765] although that term is also used
   to refer to a specific address format (defined in [RFC2765] section
   2.1) and hence we avoid the use of this term herein except when
   referring to the specific address format.

2.  Prefix Selection

   This section discusses the choice of IPv6 prefixes for use with the
   two classes of addresses outlined above.

2.1.  Requirements

   There are a number of important requirements to be considered for
   prefix selection.

2.1.1.  IPv6 Routing System Scalability

   One critical issue to consider to assess impact of the IPv6 prefix
   used is related to the scalability of the IPv6 routing system.  Since
   a goal of translation is to enable IPv4-only hosts and IPv6-only
   nodes to communicate, the IPv6 addresses used to represent IPv4 hosts
   need to be routable within the IPv6 network served by the IPv4/IPv6
   translator.  This implies that a prefix covering such addresses must
   be covered by one or more routes advertised in that IPv6 network.  In
   some scenarios a single IPv6 route may suffice, whereas other
   scenarios may require multiple (more specific) routes.  It is
   important, however, to avoid injecting an IPv6 route for every IPv4
   route in the Internet.

2.1.2.  Native Connectivity Preference for Dual-Stack Nodes

   When dual stack nodes are involved in communication, a potential
   issue arises if they prefer translated IPv4/IPv6 connectivity over
   native IPv4 or IPv6 connectivity.

   For communication initiated from an IPv6-only node towards a dual-
   stack node, there are two possibilities: communicating to the native
   IPv6 address of the destination, or communicating via an IPv4/IPv6
   translator to the IPv4 address of the destination (by using an IPv6
   address that is translated to the IPv4 address).  In some cases this
   may be solved by having the IPv6-only node only learn the native IPv6
   address and not the algorithmically derived one (e.g., by using a
   normal DNS resolver), but this is not possible in general due to the
   variety of mechanisms for learning the destination addresses (e.g.,
   referrals).  To cover those cases, an IPv6-only node SHOULD be able
   to distinguish a native IPv6 address from an IPv6 address used to
   represent an IPv4 host.

   For communication initiated from a dual-stack node toward an IPv4-
   only node, there are two possibilities: communicating to the native
   IPv4 address of the destination, or communicating via an IPv4/IPv6
   translator to the IPv4 address of the destination (by using an IPv6
   address that is translated to the IPv4 address).  In some cases, this
   may be solved by having the dual-stack node only learn the native
   IPv4 address and not the algorithmically derived one, but this is not
   possible in general due to the variety of mechanisms for learning the
   destination addresses.  Normally it is desirable for a dual-stack
   node to prefer an IPv6 destination address over an IPv4 destination
   address, but in this case the IPv6 destination address is worse
   because it will be translated.  Hence in general, a dual-stack node
   SHOULD be able to distinguish a native IPv6 address from an IPv6
   address used to represent an IPv4 host, so that the former can be
   preferred over an IPv4 destination address but not the latter.

   [RFC3484] today provides the ability for IPv6-capable hosts to be
   configured with prefixes used for address sorting sufficient to solve
   the native connectivity preference issue.  However the gap today is
   that this requires manual configuration of all such hosts, which is
   not practical.

2.1.3.  Referral Support

   A referral operation is when a host A passes the IP address of a Host
   B to a third Host C as application data.  The Host C may then
   initiate communication towards Host B using the IP address received.

   At this point in time, there are several widely-available protocols
   that operate on the IPv4 Internet and perform referrals, including
   HTTP, DNS, SIP, and BitTorrent.  The analysis in [I-D.wing-behave-
   nat64-referrals] of SIP (which does referrals between IPv4 and IPv6)
   shows that SIP needs to refer IPv4 addresses, not IPv6 addresses.
   Thus, it doesn't matter what IPv6 prefix is used because an IPv6
   address isn't referred.

   [EDITOR'S NOTE: The wing document discusses BitTorrent but the text
   pulled above from draft-xli-behave-v4v6prefix section 5.1.2.1 only
   summarizes SIP.  Furthermore, it doesn't cover other widely-deployed
   protocols that do referrals such as HTTP or DNS and hence is
   inconclusive.  Finally, it's unclear whether it applies to IPv6
   addresses of IPv4 hosts or of IPv6 hosts, or both.  Hence, referral
   support is still considered an OPEN ISSUE.  Another OPEN ISSUE is
   whether to incorporate text from draft-wing-behave-nat64-referrals
   into this document.  Other protocols are covered in I-D.carpenter-
   behave-referral-object]

2.1.4.  Support for Multiple IPv4/IPv6 Translators

   For IPv6 addresses assigned to IPv6 hosts, the choice of translator
   used in the IPv4-to-IPv6 direction is determined by the IPv4 address
   it is mapped to, rather than by the choice of IPv6 prefix.

   For IPv6 addresses used to represent IPv4 hosts, the choice of
   translator used in the IPv6-to-IPv4 direction is determined by the
   IPv6 address, but is somewhat orthogonal to the choice of prefix.  In
   general, it is possible to use a single IPv6 prefix for multiple
   IPv4/IPv6 translators, or different prefixes for different IPv4/IPv6
   translators.  Using different prefixes can be achieved by inserting
   additional subnet bits after a common prefix such that each IPv4/IPv6
   translator uses a separate range of subnets.  Often only the common
   prefix needs to be configured (as opposed to each more-specific
   prefix) in other types of address translators such as DNS64 devices.

   If the translation is stateful, routing must be configured to ensure
   that the return path flows through the same translator as the forward
   path.  (Stateless translation has no such requirement.)

2.1.5.  Appropriate Prefix Length

   This section discusses several issues related to prefix length
   selection.

2.1.5.1.  Routing Policy

   [EDITOR'S NOTE: The text below needs to be rewritten somewhat.  It's
   currently hard to follow, and is missing justification for its
   statements.]

   The major issue for selecting the prefix length is the routing
   policy.  If IPv4/IPv6 translation is implemented within a subnet,
   then a /96 should be fine.  However, if IPv4/IPv6 translation is
   implemented in an ISP's backbone, then the minimum prefix should be
   /64 and in some cases should be /48.

2.1.5.2.  Forwarding Efficiency

   According to current specifications [EDITOR'S NOTE: need reference],
   routers must handle routes containing prefixes of any valid length,
   from 0 to 128.  However, some users have reported that routers
   exhibit worse performance when routing using prefixes longer than 80
   bits.  This implies that using routes with prefixes of 80 bits or
   fewer would result in better performance in some cases.

2.1.5.3.  EUI-64 Format

   The use of a prefix length longer than 64 bits may affect the
   Interface Identifier format.  Specifically, [RFC4291] section 2.5.1
   requires that for all unicast addresses, except those that start with
   the binary value 000, Interface IDs are required to be 64 bits long
   and to be constructed in Modified EUI-64 format.  While any method
   can be used to construct a Modified EUI-64, the format requires the
   71st bit (the universal/local bit) to be set with specific meaning,
   and hence it is not available for use by an address format unless the
   prefix starts with binary 000.

   Furthermore, for IPv6 addresses assigned to IPv6 hosts, the prefix
   must be 64 bits or less in order to work with stateless address
   autoconfiguration [RFC4862] on most links.

2.1.6.  Uniqueness

   An IPv6 address used to represent an IPv4 host must be unique (i.e.,
   not ambiguously map to multiple possible IPv4 hosts) within the IPv6
   network that can use that address.  For example, since private IPv4
   addresses can be reused within multiple IPv4 networks, an IPv6
   network that connects to multiple such IPv4 networks cannot rely on
   the IPv4 address to provide uniqueness.

2.2.  Types
   behavior of Prefixes

   A prefix may be intended for use in IPv6 addresses assigned to IPv6
   hosts, or for use in IPv6 addresses used to represent IPv4 hosts.  In
   either case, there are two various types of prefixes that can be used.

2.2.1.  Network-Specific Prefix

   IPv6 prefixes are assigned to a network operator by its regional
   internet registrar (RIR).  From an IPv6 prefix assigned to the
   operator, the operator chooses a longer prefix for use by the
   operator's translator(s).  Hence a given IPv4 address would have
   different IPv6 representations in different networks that use
   different prefixes.  A network-specific prefix is also known as a
   Local Internet Registry (LIR) prefix.

   If the network operator is an ISP that has been allocated a /32 or
   shorter, then it may be possible for the ISP to allocate a fairly
   short prefix such as a /40.  However, if the network operator is an
   end site with a /48, then the prefixes for the translator would be
   much longer, such as a /56.  Using a /56 prefix still leaves 24 bits
   that can be used (without routing on prefixes longer than 80 bits)
   for routes via different translators.  However, since a prefix that
   originates from an RIR will not start with binary 000, the use of the
   71st bit cannot be used by any format with a network-specific prefix.

2.2.2.  Well-Known Prefix

   A well-known prefix is an IPv6 prefix assigned by IANA translators and gateways, including
   mechanisms for use in an
   algorithmic mapping.  Hence a given IPv4 address would have the same
   IPv6 representation in all networks that use the same well-known
   prefix.

   Rather than requiring manual configuration translating between IP headers and other types of the
   messages that include IP addresses.  This document specifies how an
   individual IPv6 prefixes in
   each device in a network (and for each network to which a given
   device can connect), a well-known prefix can be implemented by
   default until there exists a protocol address is translated to learn the policies.  Using a
   network-specific prefix allows no such factory defaults.

   Another benefit corresponding IPv4
   address, and vice versa, in cases where an algorithmic mapping is
   used.  While specific types of a well-known prefix over a network-specific prefix devices are used herein as examples,
   it is that a short prefix length can be used, allowing greater
   flexibility in the choice responsibility of format and support the specification of such devices to
   reference this document for multiple
   translators, while not requiring routing on prefixes longer than 80
   bits.

   Finally, a well-known prefix can start with binary 000, allowing algorithmic mapping of the
   use addresses
   themselves.

   Section 2 of all subsequent bits.

   Two examples this document describes the format of well-known prefixes, as specified in [RFC2765]
   section 2.1, are:
   o  IPv4-mapped: This prefix is 0:0:0:0:0:ffff::/96, and "IPv4 Embedded
   IPv6 addresses", i.e.  IPv6 addresses in
      this prefix are which 32 bits contains an
   IPv4 address.  These addresses can be used to represent IPv4 hosts.
   o  IPv4-translatable: This prefix is 0:0:0:0:ffff:0::/96, and
      addresses hosts to
   hosts in this prefix are an IPv6 network.  IPv6 addresses assigned to IPv6 hosts.  However,
      since this prefix is longer than /64, this prefix does not work hosts for
   use with stateless address autoconfiguration.  Hence some other
      mechanism for configuring translation are referred to as "IPv4-translatable"
   IPv6 hosts must be used with this
      prefix.

   Note that both addresses; they are a variant of the above prefixes start with binary 000, embedded addresses, and hence
   there is no issue with follow
   the 71st bit.

2.3.  Scenario-Specific Discussion and Recommendations

   In this section we discuss four topologies format described in which IPv4/IPv6
   translation is interesting.  In each topology, initiating
   communication can be attempted from either Section 2.

   Section 3 discusses the IPv4 side or choice of prefixes, the IPv6
   side, though it may or may not be supported.

2.3.1.  Scenario 1: an IPv6 network to use of a well known
   prefix, and the IPv4 Internet

   [EDITOR'S NOTE: draft-xli-behave-v4v6-prefix-00 section 5.1.1.2 was
   hard to follow, use of embedded addresses with stateless and contained some statements stateful
   translation.

1.1.  Applicability Scope

   This document is part of a series defining address translation
   services.  We understand that got significant
   pushback on the list.  This section tries to take these into account,
   but there may still address format could also be some points missing.]

   The figure below shows an IPv6 network connected to the used
   by other interconnection methods between IPv6
   Internet, and IPv4, e.g. methods
   based on encapsulation.  If the WG so decides, a future version of
   this document could also to discuss the use of embedded addresses and
   prefixes for interconnection of IPv6 and IPv4 network via based on encapsulation.

1.2.  Notations

   In this document, an IPv4/IPv6 translator.

          ________                    _______       ________
         /        \   +----------+   /  An   \     /        \
        | "IPv4/IPv6 translator" is an entity that
   translates IPv4    |--|IPv4/IPv6 |--|  IPv6   |---|  IPv6    |
         \Internet/   |Translator|   \Network/     \Internet/
          --------    +----------+    -------       --------

   For the IPv6 prefix used packets to represent IPv4 hosts, all IPv6-capable
   devices served by the translator SHOULD be configurable with
   preference policies consistent with [RFC3484], IPv6 packets, and SHOULD default to
   having 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 Well-Known Mapped Prefix defined in Section 5 first packet in this
   table, with a lower preference than either native flow is received.

   In this document, an "address translator" is any entity that has to
   derive an IPv4 or native IPv6
   addresses.

   Similarly, all address translators MUST be configurable with the from an IPv6
   prefix address or vice versa.  This
   applies not only to use devices that do IPv4/IPv6 packet translation, but
   also to represent IPv4 hosts, other entities that manipulate addresses, such as name
   resolution proxies (e.g., DNS64 [I-D.bagnulo-behave-dns64]) and SHOULD
   possibly other types of Application Layer Gateways (ALGs).

   In this document, the "Well Known Prefix" is an IPv6 prefix assigned
   by IANA for use in an algorithmic mapping.  Options for the Well-Known
   Mapped actual
   allocation of the Well Known Prefix unless configured with are discussed in Section 3.6.

   In this document, a network-specific prefix.

   When any well-known prefix "Network Specific Prefix" is used an IPv6 prefix
   assigned by a given network, it MUST NOT be
   advertised into an organization for use in algorithmic mapping.  Options
   for the Network Specific Prefix are discussed in Section 3.3 and 3.4.

2.  IPv4 Embedded IPv6 Internet, to prevent pollution of the global Address Format

   IPv4 Embedded IPv6 routing table by elements Addresses are composed of a variable length
   prefix, the embedded IPv4 routing table.  Therefore,
   a site which also has a native IPv6 connection MUST NOT advertise address, and a
   well-known variable length suffix, as
   presented in the following diagram:

    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127-|
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/32 |     prefix on that connection, and native IPv6 network
   operators MUST filter out and discard any    |v4(32)         | u | suffix                        |
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |/40 |     prefix routing
   advertisements for the well-known prefix.

   Furthermore, to avoid being used as transit,        |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)      |
    +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   In these addresses, the IPv6 network MUST
   NOT advertise into prefix shall be either the IPv6 Internet "Well Known
   Prefix" defined in the IPv6 prefix used addressing architecture to represent IPv4 hosts, regardless of whether it is network-specific
   mapped addresses, or
   well-known.  This is easy a "Network Specific Prefix" unique to ensure when the IPv6 prefix used to
   represent IPv4 hosts is disjoint from
   organization deploying the IPv6 prefix used to
   represent IPv6 hosts.

   For address translators.  (Options for the IPv6
   well known prefix used to assign addresses to IPv6 hosts, the use
   differs are discussed in Section 3.6.)

   Various deployments justify different prefix lengths.  The tradeoff
   between stateless different prefix lengths are discussed in Sections 3.3 and stateful translation.

2.3.1.1.  Stateful Translation

   When stateful translation is used, the choice
   3.4 of IPv6 prefix for
   addresses assigned to IPv6 hosts is unaffected, since algorithmic
   mapping is not used for these addresses.

2.3.1.2.  Stateless Translation

   "An IPv6 network" will advertise this document.

   Bits 64 to 71 of the IPv4/IPv6 translator the
   prefix address are reserved for IPv6 addresses assigned to IPv6 hosts (and similarly compatibility with the
   IPv4/IPv6 translator will advertise into "an IPv6 network"
   host identifier format defined in the IPv6
   prefix used addressing architecture.
   These bits MUST be set to represent IPv4 hosts).

   On the other side, towards zero.  The corresponding octet is noted "u"
   in the IPv6 Internet, above diagram.  When using a 96 prefix, the IPv6 network
   advertises into administrators
   MUST ensure that the IPv6 Internet an IPv6 prefix for IPv6 addresses
   assigned bits 64 to 71 are compatible with the IPv6 hosts.  This
   addressing architecture.

   The IPv4 address is encoded following the prefix, used to be reachable from most significant
   bits first.  Depending of the
   IPv6 Internet, may or prefix length, the 4 octets of the
   address may not be separated by the same as reserved octet "u".  In particular:
   o  When the prefix used to
   assign to hosts IPv6 addresses that are reachable from is 32 bit long, the IPv4
   Internet, but it seems simplest address is encoded in
      positions 32 to only require one 63.
   o  When the prefix (and hence
   one global IPv6 address per host).

2.3.2.  Scenario 2: is 40 bit long, 24 bits of the IPv4 Internet to an IPv6 network

   The considerations address are
      encoded in positions 40 to 63, with the same as remaining 8 bits in scenario 1, except that
   stateful translation only supports initiation from
      position 72 to 79.
   o  When the IPv6 side, and
   hence only stateless translation can be used prefix is 48 bit long, 16 bits of the IPv4 address are
      encoded in this scenario.

2.3.3.  Scenario 3: positions 48 to 63, with the IPv6 Internet remaining 8 bits in
      position 72 to an 87.
   o  When the prefix is 56 bit long, 8 bits of the IPv4 network

   For this scenario, shown address are
      encoded in positions 56 to 63, with the following figure, only stateful
   translation can be used remaining 8 bits in general, and an algorithmic mapping
      position 72 to 95.
   o  When the prefix is 64 bit long, the IPv4 address is encoded in
      positions 72 to 103.
   o  When the prefix is 96 bit long, the IPv4 address is not
   relevant for IPv6 addresses assigned encoded in
      positions 96 to IPv6 hosts since they 127.

   There are not
   under no remaining bits, and thus no suffix, if the prefix is 96
   bit long.  In the other cases, the control remaining bits of the same organization as address
   constitute the translator.  (Note
   that algorithmic mapping can suffix.  These bits are reserved for future
   extensions, and should be used if communication with only set to a
   small subset of null value.  (Different options
   for the IPv6 Internet is supported.  That scenario is
   covered suffix as discussed in Section 2.3.6.)

          ________                    _______       ________
         /        \   +----------+   /  An   \     /        \
        |  IPv6    |--|IPv4/IPv6 |--| 3.5.)

3.  Deployment Guidelines and Choices

3.1.  Deployment Using the Well Known Prefix

   The Well Known Prefix MAY be used by organizations deploying
   translation services.

   The Well Known Prefix SHOULD NOT be used to construct IPv4   |---|
   translatable addresses.  The host served by IPv4    |
         \Internet/   |Translator|   \Network/     \Internet/
          --------    +----------+    -------       --------

   For IPv6 translatable
   addresses used should be able to represent the receive IPv6 traffic bound to their IPv4 hosts,
   translatable address without incurring intermediate protocol
   translation.  This is only possible if the following
   considerations apply.  If specific prefix used to
   build the IPv4 network uses private IPv4
   addresses, a well-known translatable addresses is advertized in inter-domain
   routing, and this kind of specific prefix will not work since there advertisement is no
   distinction among IPv4 networks using not
   supported with the same private IPv4 address
   block.  Therefore, a network-specific prefix Well Known Prefix, as explained in Section 3.2.

   The Well Known Prefix MUST NOT be used.  If the
   IPv4 network uses public used to represent non global IPv4
   addresses, it will inject a route into
   the such as those defined in RFC 1918.  Doing so would
   introduce ambiguous IPv6 address.

3.2.  Impact on Inter-Domain Routing

   The Well Known Prefix MAY appear in inter-domain routing table pointing tables, if
   service providers decide to its translator(s).  Hence 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 scalability requirement requires policies, e.g., through configuration
   of BGP.  Organizations that an IPv6 network-
   specific prefix again advertize the Well Known Prefix in inter-
   domain routing MUST be used.

2.3.4.  Scenario 4: an IPv4 network able to provide address translation service.

   When the IPv6 Internet

   The considerations are the same as in scenario 3, except that
   stateful translation only supports initiation from relies on the Well Known Prefix, IPv4-mapped
   IPv6 side, and
   hence only stateless translation can prefixes longer than the Well Known Prefix MUST NOT be used
   advertised in BGP (especially e-BGP) [rfc4271] because this scenario.

2.3.5.  Scenario 5: an imports
   IPv4 routing table into IPv6 network one and therefore induces scalability
   issues to an IPv4 network

   TO BE FILLED IN

       ________       _______                    _______       ________
      /        \     /  An   \   +----------+   /  An   \     /        \
     |  IPv4    |---|  IPv4   |--|IPv4/IPv6 |--| the global IPv6   |---| routing table.  Adjacent BGP speakers MUST
   ignore advertisements of IPv4-mapped IPv6    |
      \Internet/     \Network/   |Translator|   \Network/     \Internet/
       --------       -------    +----------+    -------       --------

2.3.6.  Scenario 6: an IPv4 network prefixes longer than the
   Well Known Prefix.  BGP speakers SHOULD be able to an IPv6 network

   The considerations are be configured with
   the default Well Known Prefix.

   When the same as in scenario 5, except that
   stateful translation only supports initiation from service relies on Network Specific Prefixes, the
   global IPv6 side, and
   hence only routing policy guideline MUST be followed.  In
   particular, if stateless translation can be used in this scenario.

2.3.7.  Scenario 7: is used, the IPv6 Internet IPv4-translatable
   addresses MUST be advertised with proper aggregation to the IPv4 Internet

   This scenario need not be supported.

          ________                    ________
         /        \   +----------+   /        \
        |  IPv4    |--|IPv4/IPv6 |--| IPv6   |
         \Internet/   |Translator|   \Internet/
          --------    +----------+    --------

2.3.8.  Scenario 8: the IPv4 Internet
   Internet.  Similarly, if translators are configured with multiple
   Network Specific Prefixes, these prefixes MUST be advertised to the
   IPv6 Internet

   This scenario need not be supported.

3.  IPv6 Address Format and with proper aggregation.

3.3.  Choice of Prefix for Stateless Translation Algorithms

   There Deployments

   Organization may deploy translation services using stateless
   translation.  In these deployments, internal IPv6 hosts are multiple mechanisms used today to algorithmically map
   between an addressed
   using "IPv4 translatable" IPv6 address and an IPv4 address, and more may addresses, which enable them to be defined
   over time.  In this section, we first present a set
   accessed by IPv4 hosts.  The addresses of requirements
   for such mechanisms, and then evaluate these external hosts are
   represented in "IPv4 Embedded" IPv6 addresses.

   Organizations deploying stateless translation SHOULD assign a number of existing
   mechanisms.

3.1.  Requirements
   1.  An algorithm Network
   Specific Prefix to their translation service.  Both "IPv4
   translatable" and "IPv4 Embedded" MUST be one-to-one and reversible. constructed as specified in
   section 2.  Unless the IPv6 prefix starts with binary 000, an address format  "IPv4 translatable" addresses MUST NOT use the 71st bit for any purpose other than indicating
       universal/local as specified in [RFC4291],
   3.  An IPv6 address format selected
   Network Specific Prefix.  Both types of addresses SHOULD provide support for multiple IPv4/
       IPv6 translators using different routes advertised into use the IPv6
       network (and different routes advertised into same
   prefix.  Using the IPv4 network).
   4.  An same prefix ensures that internal IPv6 address format intended hosts will
   use the most efficient paths to reach the hosts served by "IPv4
   translatable" addresses.

   The intra-domain routing protocol must be used with a stateless
       translator SHOULD be checksum-neutral.  That is, able to deliver packets to
   the IPv6 address
       and its corresponding hosts served by "IPv4 translatable" addresses.  This may require
   routing on some or all of the embedded IPv4 address should result bits.  Security
   considerations detailed in the same
       one's complement checksum to avoid having to parse or modify security section requires that routers
   check the validity of the
       transport header.  Simply relying "IPv4 translatable" source addresses, using
   some form of reverse path check.

   Forwarding, and reverse path checks, should be performed on an administrator to choose a
       checksum-neutral prefix is tricky the
   combination of the "prefix" and hence error-prone.  An
       algorithm that automatically compensates no matter what the
       administrator types is less harmful that one that does not.  Note
       that checksum-neutral translation only benefits stateless
       translators that maintain a one-to-one mapping between an IPv4
       address and an IPv6 address, since otherwise it has address.  In theory, routers
   should be able to have
       transport-specific behavior anyway.
   5.  For ease route on prefixes of readability and debugging, an IPv6 address format any length.  However, there is
   some suspicion that routing on prefixes larger than 64 bit may be
   slower, or possibly not supported by some router.  But routing
   efficiency is not designed to intentionally hide the IPv4 address
       SHOULD allow accepting and/or displaying an embedded IPv4 address only consideration in dotted-decimal form.  This is done today for the choice of a variety prefix
   length.  Organization also need to consider the availability of
       address formats (e.g., IPv4-mapped and IPv4-translatable
       addresses as discussed below, IPv4-compatible addresses which
       were deprecated by [RFC4291] Section 2.5.5.1,
   prefixes, and ISATAP
       [RFC5214] addresses).  Per [RFC4291] Section 2.2, this can only
       be done when the embedded IPv4 address appears in the low-order
       32 bits.  It is not done when an IPv4 address potential impact of null identifiers.

   If a /32 prefix is embedded
       elsewhere in used, all the address (as routing bits are contained in a 6to4 address).  Displaying an
       address using dotted-decimal can only the
   top 64 bits of the IPv6 address, leading to excellent routing
   properties.  These prefixes may however be done when some other
       portion hard to obtain, and
   allocation of the IPv6 address is used a /32 to indicate displaying the
       low-order 32 bits in dotted-decimal form.
   6.  When the IPv4 network is a private network for which the topology
       is considered sensitive information, small set of IPv4 translatable addresses may
   be seen as wasteful.  In addition, the algorithm SHOULD provide /32 prefix and a way null suffix
   leads to hide the details a null identifier, an issue that we discuss in section 3.5.

   Intermediate prefixes like /40, /48 or /56 appear as compromise.
   Only some of the internal IPv4 subnetting scheme.
       Note that there may be other mechanisms bits are part of discovering the
       topology beyond merely inspecting addresses, so while this is not
       sufficient /64 addresses.  Reverse
   checks, in itself, it is particular, may have a necessary component of any larger
       solution.  Also note that providing this capability conflicts
       with limited efficiency.  Reverse checks
   limited the requirement 5.
   7.  An algorithm MAY provide most significant bits of the ability to hide an IPv4 address from
       "helpful" IPv4 NATs.  Consider will reduce the scenarios depicted below with
       IPv4 NATs that attempt
   possibility of spoofing external address, but would allow internal
   hosts to be "helpful" by looking spoof internal addresses.

   We propose here a compromise, based on using no more than 1/256th of
   an organization's allocation of IPv6 addresses for the NAT's
       public IPv4 address in inbound application payloads and then
       translating it translation
   service.  For example, if the organization is an ISP, with an
   allocated prefix /32 or shorter, the ISP could dedicate a /40 prefix
   to the translation service.  An end site with a private IPv4 address, and similarly
       translating /48 allocation could
   dedicate a private IPv4 address /56 prefix to the NAT's public IPv4
       address in outbound payloads.  While this can break applications
       since the same bytes that appear in translation service.

   The recommended prefix length is also a function of the IPv4 address deployment
   scenario.  The stateless translation can appear
       normally be used for Scenario 1,
   Scenario 2, Scenario 5 and Scenario 6 defined in
   [I-D.ietf-behave-v6v4-framework].  For different scenarios, the payload purely by coincidence,
   prefix length recommendations are:
   o  For scenario 1 (an IPv6 network to the fact remains
       that many NATs have been observed IPv4 Internet) and scenario
      2 (the IPv4 Internet to do this in an attempt to
       make other protocols work.

       In the first IPv6 network), we recommend using a /40
      prefix for an ISP holding a /32 allocation, and a /56 prefix for a
      site holding a /40 allocation.

   o  For scenario 5 (an IPv6 address assigned network to an IPv6 host),
       an IPv4 NAT has IPv4 public address Y, network) and an address translator
       uses scenario 6
      (an IPv4 address X to map to an IPv6 address assigned network to the
       IPv6 host.  If the IPv6 host sends an application payload that
       includes an IPv6 address that directly embeds X (e.g.,
       ::ffff:0:X) then this may be translated by the IPv4 NAT to
       ::ffff:0:Y, and similarly if the IPv4 host sends an application
       payload that includes ::ffff:0:Y then this network), we recommend using a /64
      prefix.

3.4.  Choice of Prefix for Stateful Translation Deployments

   Organizations MAY deploy translation services based on stateful
   translation technology.  The organizations may be translated by
       the IPv4 NAT decide to ::ffff:0:X. This may use either a
   Network Specific Prefix or may not the Well Known Prefix.  The Well Known
   Prefix SHOULD be desirable.

                                              ________
                       X                 Y   /  IPv4  \ used when no Network Specific Prefix is available.

   When these services are used, internal hosts are addressed through
   standard IPv6 ---- IPv4/IPv6 ------- "Helpful" ---| Internet |- IPv4
   Host      Translator addresses, while IPv4 NAT     \________/   Host

       In the second scenario (an IPv6 address used to represent an hosts are represented by IPv4
       host),
   embedded addresses, as specified in section 2.

   The stateful nature of the IPv4 NAT has public address Y, and translation creates potential stability
   issue when the IPv4 host
       behind it has address Z. organization deploys multiple translators.  If several
   translators use the IPv6 host sends an application
       payload that includes an IPv6 address same prefix, there is a risk that directly embeds Y
       (e.g., ::ffff:Y) then this packet
   belonging to the same connection may be translated by the IPv4 NAT routed to
       ::ffff:Z, and similarly if different
   translators as the IPv4 host sends an application
       payload that includes ::ffff:Z then this may internal routing state changes.  This issue can be translated
   mitigated either by the
       IPv4 NAT assigning different prefixes to ::ffff:Y. This may different
   translators, or may not be desirable.

                           ________
                          /  IPv4  \     Y             Z
   IPv6 ---- IPv4/IPv6 --| Internet |----- "Helpful" --- IPv4
   Host      Translator   \________/        IPv4 NAT     Host

       As a result, protocols such as Teredo [RFC4380] and STUN
       [RFC5389] today avoid such problems by obscuring ensuring that all translators using same prefix
   coordinate their state.

   The stateful translation can be used in the scenarios defined in
   [I-D.ietf-behave-v6v4-framework].  The general recommendation is to
   use the IPv4 address
       using XOR.

       Note that providing this capability conflicts Well Known Prefix, with requirement 5,
       but anything that meets requirement 6 will also meet this
       requirement.

3.2.  Mechanisms two exceptions:
   o  In this section we discuss all scenarios, the translation MAY use a number of mechanisms Network Specific
      Prefix, if deemed appropriate for algorithmic
   mapping.  [EDITOR'S NOTE: currently the subsections are ordered from
   most specific to most general.  Would the opposite order management reasons.
   o  The Well Known Prefix MUST NOT be more or
   less readable?]

3.2.1.  IPv4-Mapped IPv6 Addresses

   IPv4-mapped IPv6 addresses are defined in [RFC4291] Section 2.5.5.2
   as IPv6 addresses used for scenario 3 (the IPv6
      Internet to represent an IPv4 hosts, network), as this would lead to using the format
   ::ffff:a.b.c.d, where a.b.c.d is the corresponding Well
      Known Prefix with non global IPv4 address.
   IPv4-mapped IPv6 addresses are addresses.  That means a Network
      Specific Prefix MUST be used both on the wire ([RFC2765]) when
   translation is done in the network, as well as within hosts (e.g.,
   [RFC3493]) when translation is done in the end system.  This that scenario.

3.5.  Choice of Suffix

   The address format
   was designed to be checksum-neutral, and obviously uses a well-known
   prefix.  It is widely deployed in host operating systems today.

3.2.2.  IPv4-Translatable Addresses

   IPv4-translatable addresses (also known as IPv4-translated addresses)
   are defined described in [RFC2765] Section 2.1 as addresses assigned to IPv6
   hosts, using 2 recommends a null suffix.
   Before making this recommendation, we considered different options:
   checksum neutrality; the format ::ffff:0:a.b.c.d, where a.b.c.d is encoding of a
   corresponding IPv4 address used by port range; and a translator.  IPv4-translatable
   addresses are used on value
   different than 0.

   The "neutrality checksum" option would give a chosen value to 16 of
   the wire ([RFC2765]) when translation is done
   in suffix bits to ensure that the network.  Hypothetically they could be used within hosts when
   translation is done in "IPv4 embedded" IPv6 address has
   the end system, but there is no specification same 16 bit complement to 1 checksum as the embedded IPv4
   address.  There have been discussion of this at present.  This format was also designed to be checksum-
   neutral, checksum in the working
   group mailing list, and obviously uses a well-known-prefix.  It is not known some push to
   be widely deployed today.

   OPEN ISSUE: Should IPv4-translatable standardize a checksum format.
   However, we observed that the neutrality checksum alone does
   eliminate checksums computation during stateful translation, as only
   one of the two addresses would be deprecated by this
   document, or should it continue checksum neutral.  In the case of
   stateless translation, translators may want to be used as recomputed the well-known default
   prefix for this purpose?  For now, we assume it will continue
   checksum anyhow, to be
   used as verify the well-known default prefix for this purpose.

3.2.3.  Zero-Pad And Embed validity of the translated datagrams.
   In this mechanism, doubt, we picked the simplest alternative, to not specify a
   neutrality checksum.

   There have been proposals to complement stateless translation with a
   port-range feature.  Instead of mapping an IPv4 address is placed in to exactly
   one IPv6 prefix, the last 32-bits,
   after options would allow several IPv6 hosts to share
   an IPv4 address, with each host managing a 96-bit configured prefix.  That is, different range of ports.
   But these schemes are not yet specified in work group documents.  If
   a well-known or network-
   specific prefix is zero-padded to 96 bits.  This port range extension is referred to needed, it could be defined later, using
   bits currently reserved as
   PREFIX::/96 null in the deprecated [RFC2766], resulting in addresses of
   the form PREFIX::a.b.c.d, where a.b.c.d suffix.

   When a /32 prefix is used, the corresponding IPv4
   address.  Note that typically null suffix results in a null
   identifier.  We understand the dotted-decimal form can only be conflict with Section 2.6.1 of
   RFC4291, which specifies that all zeroes are used for input and the subnet-
   router anycast address.  However, in documentation, but not display since display our specification, there would require the PREFIX to
   be known to all displaying systems to
   indicate the use of dotted-decimal.

   |                96 bits                    |      32 bits        |
   +-------------------------------------------+---------------------+
   |                PREFIX                     | only one IPv4 address     |
   +-------------------------------------------+---------------------+

   This format is not checksum-neutral unless translatable host in the PREFIX is checksum-
   neutral.  Hence, a well-known prefix can ensure checksum neutrality,
   but using /64 subnet, and the anycast
   semantic would not create confusion.  We thus decided to keep the
   null suffix for now.  (Different authors of this format with network-specific prefixes in general
   cannot.

   The universal/local bit in document have
   different opinions.)

3.6.  Choice of the Modified EUI-64 occurs in Well Known Prefix

   We are faced with three choices for the prefix
   and MUST be set to zero unless Well Known Prefix:
   o  reuse the IPv4 address is known to be global
   (but can be set to zero even if it is known IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
      2765 Section 2.1;
   o  request allocation of a new /96 prefix;
   o  or request IANA to be global).

   Note that IPv4-mapped and IPv4-translatable addresses are allocate a special
   case /32 prefix.

   Each of these choices has pros and cons.  We expect this mechanism, where the PREFIX is well-known.

3.2.4.  Compensation-Pad And Embed

   This potential mechanism is the same as Zero-Pad And Embed
   (Section 3.2.3), except that it provides checksum neutrality issue to be
   debated and
   hence benefits stateless IPv4/IPv6 translators.  A configured well-
   known or network-specific PREFIX::/80 is followed resolved by 16 bits that
   result in the first 96 bits being checksum-neutral.

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+----+---------------------+
   |                PREFIX                |comp|    IPv4 address     |
   +--------------------------------------+----+---------------------+

   The universal/local bit in BEHAVE working group, and present here
   our analysis of the Modified EUI-64 occurs in options.

   The main advantage of the existing IPv4-mapped prefix
   and MUST be set to zero unless the IPv4 address is known to be global
   (but can be set to zero even if that it is known to be global).

3.2.5.  Embed And Zero-Pad

   In this mechanism (often referred to
   already defined.  Reusing that prefix will require minimal
   standardization efforts.  However, being already defined is not just
   and advantage, as "IVI"), there may be side effects of current
   implementations.  When presented with the IPv4 address is
   embedded immediately after a routable IPv4-mapped prefix, several
   versions of Windows and then zero-padded at
   the end.

   |           n bits         |      32 bits        |    96-n bits   |
   +--------------------------+---------------------+----------------+
   |           PREFIX         | MAcOS may generate IPv4 address     |      Zero      |
   +--------------------------+---------------------+----------------+

   [EDITOR'S NOTE: draft-baker-behave-v4v6-framework disallowed PREFIX
   being 64-95 bits long, without explanation. packets, but will not
   send IPv6 addresses packets.  If we used to
   represent IPv4 hosts should be fine to use prefixes of other lengths.
   Hence suggested clarifying text below.  For IPv6 addresses assigned
   to IPv6 hosts, kept the restriction though I do IPv4-mapped prefix, these hosts
   would not understand why
   this is needed and hence still consider this an OPEN ISSUE.]

   The IPv4 address is intended be able to straddle support translation without modification.  This
   will defeat the boundary between main purpose of the translation techniques.

   Allocating a new prefix used in routable tables and would diminish the bits risk of undesirable side
   effects in current implementations.  The main cost will be the host portion.  For
   IPv6 addresses assigned
   registration cost with IANA.  We will also need to IPv6 hosts, this would require a PREFIX update the
   recommendation for textual representations of
   length 32..63 bits.  For IPv6 addresses used to represent IPv4 hosts,
   any PREFIX length is sufficient.

   However, IPv6 addresses, if we
   want to ensure the PREFIX is dotted decimal representation of the IPv4
   component in the IPv4 embedded IPv6 addresses.

   If we allocate a network-specific new prefix, rather than choosing a
   well-known prefix, this mechanism requires the /32 prefix to be less than
   38 bits (so that would allow the
   embedded IPv4 address would end prior to fit within the universal/
   local bit), or at least 71 top 64 bits (so that the IPv4 address would begin
   after the universal/local bit).

   Note that Zero-Pad and Embed can be considered to be a special case of this mechanism, where the PREFIX is 96 bits IPv6
   address.  This would facilitate routing and the SUFFIX is 0
   bits.

3.2.6.  Preconfigured Mapping Table

   In this, the most general, mechanism, load balancing when an IPv4/IPv6
   organization deploys several translators.  However, such destination-
   address translator based load balancing may not be desirable, as it is preconfigured not
   compatible with STUN in the deployments involving multiple stateful
   translators, each one having a mapping table including all legal pairs.  Any
   IPv6 and different pool of IPv4 addresses can addresses.
   STUN compatibility would only be used.  This mechanism is not checksum-
   neutral.  Since achieved if the IPv4 address is not embedded in any way, it need
   not reveal any details of translators managed
   the same pool of IPv4 topology, and minimizes issues
   with "helpful" IPv4 NATs.

3.3.  Scenario-Specific Discussion addresses and Recommendations

   In this section we discuss four topologies in which IPv4/IPv6 were able to coordinate their
   translation is interesting.  In each topology, initiating
   communication can be attempted from either state.

   We should also note that according to Section 2.2 of RFC 4291, in the
   legal textual representations of IPv6 side or addresses, dotted decimal can
   only appear at the IPv4
   side.

3.3.1.  Scenario 1: an IPv6 network end.  We could simply forego the dotted decimal
   notation, but that would make the address format harder to use, and
   log files harder to read.  We could also update RFC4291 to allow
   textual representation of addresses using the IPv4 Internet

   Since assigned WKP and having
   the IPv4 network is interface identifier set to all zeros.  We could also embed the Internet, there is negligible value
   IPv4 address both in
   trying to hide the topology details last 32 bits of the IPv4 network interface identifier and hence
   requirement 6 does not apply.  The other requirements all apply
   normally.

   TO BE FILLED IN

3.3.2.  Scenario 2:
   the IPv4 Internet last 32 bits of the 64 bit prefix, allowing to an IPv6 network

   The considerations are use the same textual
   representation as defined in scenario 1, except as follows.

   TO BE FILLED IN

3.3.3.  Scenario 3: the IPv6 Internet to an IPv4 network

   In this scenario, only stateful translation can be used RFC4291 and hence
   requirement 4 (checksum-neutrality) does not apply.  The other
   requirements all apply normally.

   TO BE FILLED IN

3.3.4.  Scenario 4: an also have the possibility of
   including the IPv4 network address in the prefix part.  Moreover, we could
   request for IANA to assign a /32 for the IPv6 Internet

   The considerations are WKP and then operators could
   simply decide whether to use it as a /32 or pad it with zeros and use
   it as a /96.

   Allocating a new /96 prefix would not enable the same routing and
   load balancing options as in scenario 3, except as follows.

   TO BE FILLED IN

3.3.5.  Scenario 5: a /32 prefix, but would allow for decimal
   notation of IPv4 addresses without requiring an IPv6 network update to an IPv4 network

   Typically the IPv4 network RFC 4291.

4.  Security Considerations

4.1.  Protection Against Spoofing

   By and the IPv6 network large, address translators can be modeled as special routers,
   are managed by subject to the same organization in this scenario, risks, and hence it can implement the same mitigation.
   There is not necessary to
   hide however a particular risk that directly derived from the topology details
   practice of the embedding IPv4 network and requirement 6 does
   not apply addresses in this case.  The other requirements all apply normally.

   TO BE FILLED IN

3.3.6.  Scenario 6: IPv6: address spoofing.

   An attacker could use an IPv4 network to an IPv6 network

   The considerations are the same as in scenario 5, except embedded address as follows.

   TO BE FILLED IN

3.3.7.  Scenario 7: the IPv6 Internet to source address
   of malicious packets.  After translation, the packets will appear as
   IPv4 Internet

   This scenario need not packets from the specified source, and the attacker may be supported.

3.3.8.  Scenario 8: hard
   to track.  If left without mitigation, the attack would allow
   malicious IPv6 nodes to spoof arbitrary IPv4 Internet addresses.

   The mitigation is to implement reverse path checks, and to verify
   throughout the IPv6 Internet

   This scenario need not be supported.

4.  Security Considerations network that packets are coming from an authorized
   location.

4.2.  Secure Configuration

   The prefix and format need to be the same 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

   A future version of this memo will request an IPv6 prefix assignment
   as a Well-Known Mapped Prefix, that is used to represent IPv4 hosts,
   and which must start with binary 000.

   [EDITOR'S NOTE: 0/8 is reserved by the IETF (and not allocated by
   IANA), so all that is needed is to specify the prefix herein since it
   is an allocation from IETF not from IANA.]

   OPEN ISSUE: The prefix length of this block has not yet been
   determined.  Some possibilities are /16, /32, /48 or /96.

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, Congxiao Bao, Dan Wing, Ed Jankiewicz, Fred Baker,
   Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore,
   Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret
   Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-
   Courmont, Remi Despres, William Waites and Xing Li.

7.  Contributors

   The following individuals co-authored drafts 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

       Congxiao Bao
       CERNET Center/Tsinghua University
       Room 225, Main Building, Tsinghua University
       Beijing,   100084
       China
       Phone: +86 62785983
       Email: congxiao@cernet.edu.cn

       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

8.  References

8.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

8.2.  Informative References

   [I-D.bagnulo-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
              M. Endo, "DNS64: DNS extensions for Network Address
              Translation from IPv6 Clients to  IPv4 Servers",
              draft-bagnulo-behave-dns64-02 (work in progress),
              March 2009.

   [I-D.baker-behave-v4v6-framework]

   [I-D.ietf-behave-v6v4-framework]
              Baker, F., Li, X., and C. Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", draft-baker-behave-v4v6-framework-02
              draft-ietf-behave-v6v4-framework-03 (work in progress), February
              October 2009.

   [I-D.wing-behave-nat64-referrals]
              Wing, D., "Referrals Across a NAT64",
              draft-wing-behave-nat64-referrals-00 an IPv6/IPv4 Translator",
              draft-wing-behave-nat64-referrals-01 (work in progress),
              March
              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.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, February 2003.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

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

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

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