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 22, 2010 M. Bagnulo
UC3M
M. Boucadair
France Telecom
X. Li
CERNET Center/Tsinghua University
August 21, 2009
IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-translator-addressing-00.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 22, 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
Huitema, et al. Expires February 22, 2010 [Page 1]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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
1.1. IPv6 Addresses Assigned to IPv6 Hosts . . . . . . . . . . 4
1.2. IPv6 Addresses Used to Represent IPv4 Hosts . . . . . . . 5
2. Prefix Selection . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 7
2.1.4. Support for Multiple IPv4/IPv6 Translators . . . . . . 7
2.1.5. Appropriate Prefix Length . . . . . . . . . . . . . . 8
2.1.6. Uniqueness . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Types of Prefixes . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Network-Specific Prefix . . . . . . . . . . . . . . . 9
2.2.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . 9
2.3. Scenario-Specific Discussion and Recommendations . . . . . 10
2.3.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . 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 . . 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 . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . 15
3.2.2. IPv4-Translatable Addresses . . . . . . . . . . . . . 15
3.2.3. Zero-Pad And Embed . . . . . . . . . . . . . . . . . . 16
3.2.4. Compensation-Pad And Embed . . . . . . . . . . . . . . 16
3.2.5. Embed And Zero-Pad . . . . . . . . . . . . . . . . . . 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: the IPv4 Internet to an IPv6 network . . . 18
Huitema, et al. Expires February 22, 2010 [Page 2]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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
Huitema, et al. Expires February 22, 2010 [Page 3]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 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.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
Huitema, et al. Expires February 22, 2010 [Page 4]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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.
Huitema, et al. Expires February 22, 2010 [Page 5]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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.
Huitema, et al. Expires February 22, 2010 [Page 6]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
[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.
Huitema, et al. Expires February 22, 2010 [Page 7]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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.
Huitema, et al. Expires February 22, 2010 [Page 8]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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 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 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 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 of the 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 to learn the policies. Using a
network-specific prefix allows no such factory defaults.
Huitema, et al. Expires February 22, 2010 [Page 9]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
Another benefit of a well-known prefix over a network-specific prefix
is that a short prefix length can be used, allowing greater
flexibility in the choice of format and support for multiple
translators, while not requiring routing on prefixes longer than 80
bits.
Finally, a well-known prefix can start with binary 000, allowing the
use of all subsequent bits.
Two examples 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 addresses in
this prefix are used to represent IPv4 hosts.
o IPv4-translatable: This prefix is 0:0:0:0:ffff:0::/96, and
addresses in this prefix are assigned to IPv6 hosts. However,
since this prefix is longer than /64, this prefix does not work
with stateless address autoconfiguration. Hence some other
mechanism for configuring IPv6 hosts must be used with this
prefix.
Note that both of the above prefixes start with binary 000, and hence
there is no issue with the 71st bit.
2.3. Scenario-Specific Discussion and Recommendations
In this section we discuss four topologies in which IPv4/IPv6
translation is interesting. In each topology, initiating
communication can be attempted from either the IPv4 side or the IPv6
side, though it may or may not be supported.
2.3.1. Scenario 1: an IPv6 network to the IPv4 Internet
[EDITOR'S NOTE: draft-xli-behave-v4v6-prefix-00 section 5.1.1.2 was
hard to follow, and contained some statements that got significant
pushback on the list. This section tries to take these into account,
but there may still be some points missing.]
The figure below shows an IPv6 network connected to the IPv6
Internet, and also to the IPv4 network via an IPv4/IPv6 translator.
________ _______ ________
/ \ +----------+ / An \ / \
| IPv4 |--|IPv4/IPv6 |--| IPv6 |---| IPv6 |
\Internet/ |Translator| \Network/ \Internet/
-------- +----------+ ------- --------
For the IPv6 prefix used to represent IPv4 hosts, all IPv6-capable
devices served by the translator SHOULD be configurable with
Huitema, et al. Expires February 22, 2010 [Page 10]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
preference policies consistent with [RFC3484], and SHOULD default to
having the Well-Known Mapped Prefix defined in Section 5 in this
table, with a lower preference than either native IPv4 or native IPv6
addresses.
Similarly, all address translators MUST be configurable with the IPv6
prefix to use to represent IPv4 hosts, and SHOULD use the Well-Known
Mapped Prefix unless configured with a network-specific prefix.
When any well-known prefix is used by a given network, it MUST NOT be
advertised into the IPv6 Internet, to prevent pollution of the global
IPv6 routing table by elements of the IPv4 routing table. Therefore,
a site which also has a native IPv6 connection MUST NOT advertise a
well-known prefix on that connection, and native IPv6 network
operators MUST filter out and discard any prefix routing
advertisements for the well-known prefix.
Furthermore, to avoid being used as transit, the IPv6 network MUST
NOT advertise into the IPv6 Internet the IPv6 prefix used to
represent IPv4 hosts, regardless of whether it is network-specific or
well-known. This is easy to ensure when the IPv6 prefix used to
represent IPv4 hosts is disjoint from the IPv6 prefix used to
represent IPv6 hosts.
For the IPv6 prefix used to assign addresses to IPv6 hosts, the use
differs between stateless and stateful translation.
2.3.1.1. Stateful Translation
When stateful translation is used, the choice 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 to the IPv4/IPv6 translator the
prefix for IPv6 addresses assigned to IPv6 hosts (and similarly the
IPv4/IPv6 translator will advertise into "an IPv6 network" the IPv6
prefix used to represent IPv4 hosts).
On the other side, towards the IPv6 Internet, the IPv6 network
advertises into the IPv6 Internet an IPv6 prefix for IPv6 addresses
assigned to IPv6 hosts. This prefix, used to be reachable from the
IPv6 Internet, may or may not be the same as the prefix used to
assign to hosts IPv6 addresses that are reachable from the IPv4
Internet, but it seems simplest to only require one prefix (and hence
one global IPv6 address per host).
Huitema, et al. Expires February 22, 2010 [Page 11]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
2.3.2. Scenario 2: the IPv4 Internet to an IPv6 network
The considerations are the same as in scenario 1, except that
stateful translation only supports initiation from the IPv6 side, and
hence only stateless translation can be used in this scenario.
2.3.3. Scenario 3: the IPv6 Internet to an IPv4 network
For this scenario, shown in the following figure, only stateful
translation can be used in general, and an algorithmic mapping is not
relevant for IPv6 addresses assigned to IPv6 hosts since they are not
under the control of the same organization as the translator. (Note
that algorithmic mapping can be used if communication with only a
small subset of the IPv6 Internet is supported. That scenario is
covered in Section 2.3.6.)
________ _______ ________
/ \ +----------+ / An \ / \
| IPv6 |--|IPv4/IPv6 |--| IPv4 |---| IPv4 |
\Internet/ |Translator| \Network/ \Internet/
-------- +----------+ ------- --------
For IPv6 addresses used to represent the IPv4 hosts, the following
considerations apply. If the IPv4 network uses private IPv4
addresses, a well-known prefix will not work since there is no
distinction among IPv4 networks using the same private IPv4 address
block. Therefore, a network-specific prefix MUST be used. If the
IPv4 network uses public IPv4 addresses, it will inject a route into
the IPv6 routing table pointing to its translator(s). Hence the
routing scalability requirement requires that an IPv6 network-
specific prefix again MUST be used.
2.3.4. Scenario 4: an IPv4 network to the IPv6 Internet
The considerations are the same as in scenario 3, except that
stateful translation only supports initiation from the IPv6 side, and
hence only stateless translation can be used in this scenario.
2.3.5. Scenario 5: an IPv6 network to an IPv4 network
TO BE FILLED IN
________ _______ _______ ________
/ \ / An \ +----------+ / An \ / \
| IPv4 |---| IPv4 |--|IPv4/IPv6 |--| IPv6 |---| IPv6 |
\Internet/ \Network/ |Translator| \Network/ \Internet/
-------- ------- +----------+ ------- --------
Huitema, et al. Expires February 22, 2010 [Page 12]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
2.3.6. Scenario 6: an IPv4 network to an IPv6 network
The considerations are the same as in scenario 5, except that
stateful translation only supports initiation from the IPv6 side, and
hence only stateless translation can be used in this scenario.
2.3.7. Scenario 7: the IPv6 Internet 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 to the IPv6 Internet
This scenario need not be supported.
3. IPv6 Address Format and Translation Algorithms
There are multiple mechanisms used today to algorithmically map
between an IPv6 address and an IPv4 address, and more may be defined
over time. In this section, we first present a set of requirements
for such mechanisms, and then evaluate a number of existing
mechanisms.
3.1. Requirements
1. An algorithm MUST be one-to-one and reversible.
2. Unless the IPv6 prefix starts with binary 000, an address format
MUST NOT use the 71st bit for any purpose other than indicating
universal/local as specified in [RFC4291],
3. An IPv6 address format SHOULD provide support for multiple IPv4/
IPv6 translators using different routes advertised into the IPv6
network (and different routes advertised into the IPv4 network).
4. An IPv6 address format intended to be used with a stateless
translator SHOULD be checksum-neutral. That is, the IPv6 address
and its corresponding IPv4 address should result in the same
one's complement checksum to avoid having to parse or modify the
transport header. Simply relying on an administrator to choose a
checksum-neutral prefix is tricky 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 to have
Huitema, et al. Expires February 22, 2010 [Page 13]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
transport-specific behavior anyway.
5. For ease of readability and debugging, an IPv6 address format
that is not designed to intentionally hide the IPv4 address
SHOULD allow accepting and/or displaying an embedded IPv4 address
in dotted-decimal form. This is done today for a variety 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, 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 is embedded
elsewhere in the address (as in a 6to4 address). Displaying an
address using dotted-decimal can only be done when some other
portion of the IPv6 address is used 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, the algorithm SHOULD provide
a way to hide the details of the internal IPv4 subnetting scheme.
Note that there may be other mechanisms of discovering the
topology beyond merely inspecting addresses, so while this is not
sufficient in itself, it is a necessary component of any larger
solution. Also note that providing this capability conflicts
with the requirement 5.
7. An algorithm MAY provide the ability to hide an IPv4 address from
"helpful" IPv4 NATs. Consider the scenarios depicted below with
IPv4 NATs that attempt to be "helpful" by looking for the NAT's
public IPv4 address in inbound application payloads and then
translating it to a private IPv4 address, and similarly
translating a private IPv4 address to the NAT's public IPv4
address in outbound payloads. While this can break applications
since the same bytes that appear in the IPv4 address can appear
normally in the payload purely by coincidence, the fact remains
that many NATs have been observed to do this in an attempt to
make other protocols work.
In the first scenario (an IPv6 address assigned to an IPv6 host),
an IPv4 NAT has IPv4 public address Y, and an address translator
uses IPv4 address X to map to an IPv6 address assigned 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 may be translated by
the IPv4 NAT to ::ffff:0:X. This may or may not be desirable.
________
X Y / IPv4 \
IPv6 ---- IPv4/IPv6 ------- "Helpful" ---| Internet |- IPv4
Huitema, et al. Expires February 22, 2010 [Page 14]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
Host Translator IPv4 NAT \________/ Host
In the second scenario (an IPv6 address used to represent an IPv4
host), the IPv4 NAT has public address Y, and the IPv4 host
behind it has address Z. If the IPv6 host sends an application
payload that includes an IPv6 address that directly embeds Y
(e.g., ::ffff:Y) then this may be translated by the IPv4 NAT to
::ffff:Z, and similarly if the IPv4 host sends an application
payload that includes ::ffff:Z then this may be translated by the
IPv4 NAT to ::ffff:Y. This may 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 the IPv4 address
using XOR.
Note that providing this capability conflicts with requirement 5,
but anything that meets requirement 6 will also meet this
requirement.
3.2. Mechanisms
In this section we discuss a number of mechanisms for algorithmic
mapping. [EDITOR'S NOTE: currently the subsections are ordered from
most specific to most general. Would the opposite order 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 to represent IPv4 hosts, using the format
::ffff:a.b.c.d, where a.b.c.d is the corresponding IPv4 address.
IPv4-mapped IPv6 addresses are 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 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 in [RFC2765] Section 2.1 as addresses assigned to IPv6
Huitema, et al. Expires February 22, 2010 [Page 15]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
hosts, using the format ::ffff:0:a.b.c.d, where a.b.c.d is a
corresponding IPv4 address used by a translator. IPv4-translatable
addresses are used on the wire ([RFC2765]) when translation is done
in the network. Hypothetically they could be used within hosts when
translation is done in the end system, but there is no specification
of this at present. This format was also designed to be checksum-
neutral, and obviously uses a well-known-prefix. It is not known to
be widely deployed today.
OPEN ISSUE: Should IPv4-translatable addresses be deprecated by this
document, or should it continue to be used as the well-known default
prefix for this purpose? For now, we assume it will continue to be
used as the well-known default prefix for this purpose.
3.2.3. Zero-Pad And Embed
In this mechanism, the IPv4 address is placed in the last 32-bits,
after a 96-bit configured prefix. That is, a well-known or network-
specific prefix is zero-padded to 96 bits. This is referred to as
PREFIX::/96 in the deprecated [RFC2766], resulting in addresses of
the form PREFIX::a.b.c.d, where a.b.c.d is the corresponding IPv4
address. Note that typically the dotted-decimal form can only be
used for input and in documentation, but not display since display
would require the PREFIX to be known to all displaying systems to
indicate the use of dotted-decimal.
| 96 bits | 32 bits |
+-------------------------------------------+---------------------+
| PREFIX | IPv4 address |
+-------------------------------------------+---------------------+
This format is not checksum-neutral unless the PREFIX is checksum-
neutral. Hence, a well-known prefix can ensure checksum neutrality,
but using this format with network-specific prefixes in general
cannot.
The universal/local bit in the Modified EUI-64 occurs in the prefix
and MUST be set to zero unless the IPv4 address is known to be global
(but can be set to zero even if it is known to be global).
Note that IPv4-mapped and IPv4-translatable addresses are a special
case of 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 and
hence benefits stateless IPv4/IPv6 translators. A configured well-
Huitema, et al. Expires February 22, 2010 [Page 16]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
known or network-specific PREFIX::/80 is followed 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 the Modified EUI-64 occurs in the prefix
and MUST be set to zero unless the IPv4 address is known to be global
(but can be set to zero even if it is known to be global).
3.2.5. Embed And Zero-Pad
In this mechanism (often referred to as "IVI"), the IPv4 address is
embedded immediately after a routable prefix, and then zero-padded at
the end.
| n bits | 32 bits | 96-n bits |
+--------------------------+---------------------+----------------+
| PREFIX | IPv4 address | Zero |
+--------------------------+---------------------+----------------+
[EDITOR'S NOTE: draft-baker-behave-v4v6-framework disallowed PREFIX
being 64-95 bits long, without explanation. IPv6 addresses 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 not understand why
this is needed and hence still consider this an OPEN ISSUE.]
The IPv4 address is intended to straddle the boundary between the
prefix used in routable tables and the bits in the host portion. For
IPv6 addresses assigned to IPv6 hosts, this would require a PREFIX of
length 32..63 bits. For IPv6 addresses used to represent IPv4 hosts,
any PREFIX length is sufficient.
However, if the PREFIX is a network-specific prefix, rather than a
well-known prefix, this mechanism requires the prefix to be less than
38 bits (so that the IPv4 address would end prior to the universal/
local bit), or at least 71 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 and the SUFFIX is 0
bits.
Huitema, et al. Expires February 22, 2010 [Page 17]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
3.2.6. Preconfigured Mapping Table
In this, the most general, mechanism, an IPv4/IPv6 address translator
is preconfigured with a mapping table including all legal pairs. Any
IPv6 and IPv4 addresses can be used. This mechanism is not checksum-
neutral. Since the IPv4 address is not embedded in any way, it need
not reveal any details of the IPv4 topology, and minimizes issues
with "helpful" IPv4 NATs.
3.3. Scenario-Specific Discussion and Recommendations
In this section we discuss four topologies in which IPv4/IPv6
translation is interesting. In each topology, initiating
communication can be attempted from either the IPv6 side or the IPv4
side.
3.3.1. Scenario 1: an IPv6 network to the IPv4 Internet
Since the IPv4 network is the Internet, there is negligible value in
trying to hide the topology details of the IPv4 network 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 to an IPv6 network
The considerations are the same as 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 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 IPv4 network to the IPv6 Internet
The considerations are the same as in scenario 3, except as follows.
TO BE FILLED IN
Huitema, et al. Expires February 22, 2010 [Page 18]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
3.3.5. Scenario 5: an IPv6 network to an IPv4 network
Typically the IPv4 network and the IPv6 network are managed by the
same organization in this scenario, and hence it is not necessary to
hide the topology details of the IPv4 network and requirement 6 does
not apply in this case. The other requirements all apply normally.
TO BE FILLED IN
3.3.6. Scenario 6: an IPv4 network to an IPv6 network
The considerations are the same as in scenario 5, except as follows.
TO BE FILLED IN
3.3.7. Scenario 7: the IPv6 Internet to the IPv4 Internet
This scenario need not be supported.
3.3.8. Scenario 8: the IPv4 Internet to the IPv6 Internet
This scenario need not be supported.
4. Security Considerations
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.
Huitema, et al. Expires February 22, 2010 [Page 19]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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.
Huitema, et al. Expires February 22, 2010 [Page 20]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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
Huitema, et al. Expires February 22, 2010 [Page 21]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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]
Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
Translation", draft-baker-behave-v4v6-framework-02 (work
in progress), February 2009.
[I-D.wing-behave-nat64-referrals]
Wing, D., "Referrals Across a NAT64",
draft-wing-behave-nat64-referrals-00 (work in progress),
March 2009.
[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.
[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
Huitema, et al. Expires February 22, 2010 [Page 22]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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
Huitema, et al. Expires February 22, 2010 [Page 23]
Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators August 2009
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
Huitema, et al. Expires February 22, 2010 [Page 24]
