One document matched: draft-ietf-behave-address-format-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY rfc2026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2765 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2765.xml'>
<!ENTITY rfc2766 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml'>
<!ENTITY rfc3330 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3330.xml'>
<!ENTITY rfc3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY rfc3493 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3493.xml'>
<!ENTITY rfc3849 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3849.xml'>
<!ENTITY rfc4271 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'>
<!ENTITY rfc4291 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
<!ENTITY rfc5389 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml'>
<!ENTITY rfc5735 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5735.xml'>
<!ENTITY I-D.ietf-behave-dns64 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-dns64-04.xml'>
<!ENTITY I-D.baker-behave-v4v6-framework PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-behave-v4v6-framework.xml'>
<!ENTITY I-D.ietf-behave-v6v4-framework PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-v6v4-framework-03.xml'>
<!ENTITY I-D.wing-behave-nat64-referrals PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-behave-nat64-referrals.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc category="std"
docName="draft-ietf-behave-address-format-06.txt"
ipr="trust200902"
obsoletes="2765"
updates="4291"
>
<front>
<title abbrev="IPv6 Addressing of IPv4/IPv6 Translators">
IPv6 Addressing of IPv4/IPv6 Translators
</title>
<author fullname="Congxiao Bao" initials="C." role="" surname="Bao">
<organization>CERNET Center/Tsinghua University</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<region></region>
<country>China</country>
</postal>
<phone>+86 10-62785983</phone>
<email>congxiao@cernet.edu.cn</email>
</address>
</author>
<author fullname="Christian Huitema" initials="C." role="" surname="Huitema">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<code>98052-6399</code>
<region>WA</region>
<country>U.S.A.</country>
</postal>
<email>huitema@microsoft.com</email>
</address>
</author>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization>UC3M</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34-91-6249500</phone>
<facsimile></facsimile>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/marcelo</uri>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." role="" surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street> 3, Av Francois Chateaux</street>
<city>Rennes</city>
<code>350000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author initials="X." surname="Li" fullname="Xing Li"
role="">
<organization>
CERNET Center/Tsinghua University
</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city> <region> </region> <code>100084</code>
<country>China</country>
</postal>
<phone> +86 10-62785983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
This document discusses the algorithmic translation of an IPv6 address to a corresponding
IPv4 address, and vice versa, using only statically configured information. It defines a
well-known prefix for use in algorithmic translations, while allowing
organizations to also use network-specific prefixes when appropriate.
Algorithmic translation is used in IPv4/IPv6 translators, as well
as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document is part of a series of IPv4/IPv6 translation
documents. A framework for IPv4/IPv6 translation is discussed in
<xref target="I-D.ietf-behave-v6v4-framework"/>, including
a taxonomy of scenarios that will be used in this document.
Other documents specify the behavior of various types
of translators and gateways, including mechanisms for translating
between IP headers and other types of messages that include
IP addresses. This document specifies how an individual
IPv6 address is translated to a corresponding IPv4 address,
and vice versa, in cases where an algorithmic mapping is
used. While specific types of devices are used herein as examples,
it is the responsibility of the specification of such devices
to reference this document for algorithmic mapping of the addresses
themselves.
</t>
<t>
<xref target="addressAndFormat" /> describes the prefixes and the format of "IPv4-Embedded IPv6 addresses",
i.e., IPv6 addresses in which 32 bits contain an IPv4 address. This format is common to both
"IPv4-Converted" and "IPv4-Translatable" IPv6 addresses. This section also defines the algorithms
for translating addresses, and the text representation of IPv4-Embedded IPv6 addresses.
</t>
<t>
<xref target="choices" /> discusses the choice of prefixes,
the conditions in which they can be used, and the use of IPv4-Embedded
IPv6 addresses with stateless and stateful translation.
</t>
<t>
<xref target="security" /> discusses security concerns.
</t>
<t>
In some scenarios, a dual-stack host will unnecessarily
send its traffic through an IPv6/IPv4 translator. This can
be caused by host's default address selection algorithm
<xref target="RFC3484"/>, referrals, or other reasons. Optimizing these
scenarios for dual-stack hosts is for future study.
</t>
<section title="Applicability Scope">
<t>
This document is part of a series defining address translation services. We understand that
the address format could also be used by other interconnection methods between IPv6 and IPv4,
e.g., methods based on encapsulation. If encapsulation methods are developed by the IETF,
we expect that their descriptions will document their specific use of IPv4-Embedded
IPv6 addresses.
</t>
</section>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"></xref>.
</t>
</section>
<section title="Terminology">
<t>
This document makes use of the following terms:
</t>
<list style="hanging">
<t/>
<t hangText="IPv4/IPv6 translator:"> an entity that
translates IPv4 packets to IPv6 packets, and vice versa. It
may do "stateless" translation, meaning that there is no per-flow
state required, or "stateful" translation where per-flow state
is created when the first packet in a flow is received.
</t>
<t hangText="Address translator:"> any entity that has
to derive an IPv4 address from an IPv6 address or vice versa.
This applies not only to devices that do IPv4/IPv6 packet
translation, but also to other entities that manipulate addresses,
such as name resolution proxies (e.g.
DNS64 <xref target="I-D.ietf-behave-dns64"/>) and possibly
other types of Application Layer Gateways (ALGs).
</t>
<t hangText="Well-Known Prefix:"> the IPv6 prefix defined in this
document for use in an algorithmic mapping.
</t>
<t hangText="Network-Specific Prefix:"> an IPv6 prefix assigned by an
organization for use in algorithmic mapping. Options for the Network Specific Prefix
are discussed in <xref target="stateless" /> and <xref target="stateful" />.
</t>
<t hangText="IPv4-Embedded IPv6 addresses:"> IPv6 addresses in which 32 bits contain an
IPv4 address. Their format is described in <xref target="addressFormat" />.
</t>
<t hangText="IPv4-Converted IPv6 addresses:"> IPv6 addresses used to
represent IPv4 nodes in an IPv6 network. They are a variant of IPv4-Embedded IPv6 addresses,
and follow the format described in <xref target="addressFormat" />.
</t>
<t hangText="IPv4-Translatable IPv6 addresses:"> IPv6 addresses assigned to IPv6
nodes for use with stateless
translation. They are a variant of IPv4-Embedded IPv6 addresses, and follow the format
described in <xref target="addressFormat" />.
</t>
</list>
</section>
</section>
<section title="IPv4-Embedded IPv6 Address Prefix and Format" anchor="addressAndFormat">
<section title="Well Known Prefix" ancho="wkpDef">
<t>
This document reserves a "Well-Known Prefix" for
use in an algorithmic mapping. The value of this IPv6 prefix
is:
</t>
<list style="empty">
<t/>
<t>
64:FF9B::/96
</t>
</list>
</section>
<section title="IPv4-Embedded IPv6 Address Format" anchor="addressFormat">
<t>
IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses follow the
same format, described here as the IPv4-Embedded IPv6 address Format.
IPv4-Embedded IPv6 addresses are composed of a variable length prefix, the
embedded IPv4 address, and a variable length suffix, as presented in the
following diagram, in which PL designates the prefix length:</t>
<figure align="center" anchor="addressFigure">
<artwork align="left"><![CDATA[
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
<t>In these addresses, the prefix shall be either the "Well-Known Prefix",
or a "Network-Specific Prefix" unique to the organization deploying the
address translators. The prefixes can only have one of the following lengths:
32, 40, 48, 56, 64 or 96.
(The Well-Known prefic is 96 bits long, and can only
be used in the last form of the table.)
</t>
<t>
Various deployments justify different prefix lengths with Network-Specific
prefixes. The tradeoff between
different prefix lengths are discussed in <xref target="stateless" /> and
<xref target="stateful" />.
</t>
<t>
Bits 64 to 71 of the address are reserved for compatibility with the host identifier
format defined in the IPv6 addressing architecture <xref target="RFC4291" />.
These bits MUST be set to zero. When using a /96 Network-Specific Prefix,
the administrators MUST ensure that the bits 64 to 71 are set to zero.
A simple way to achieve that is to construct the /96 Network-Specific Prefix by
picking a /64 prefix, and then adding four octets set to zero.
</t>
<t>
The IPv4 address is encoded following the prefix, most significant bits first.
Depending of the prefix length, the 4 octets of the address may be separated by the
reserved octet "u", whose 8 bits MUST be set to zero. In particular:</t>
<list style='symbols'>
<t>When the prefix is 32 bits long, the IPv4 address is encoded in positions 32 to 63.</t>
<t>When the prefix is 40 bits long, 24 bits of the IPv4 address are encoded
in positions 40 to 63, with the remaining 8 bits in position 72 to 79.</t>
<t>When the prefix is 48 bits long, 16 bits of the IPv4 address are encoded in positions
48 to 63, with the remaining 16 bits in position 72 to 87.</t>
<t>When the prefix is 56 bits long, 8 bits of the IPv4 address are encoded in positions
56 to 63, with the remaining 24 bits in position 72 to 95.</t>
<t>When the prefix is 64 bits long, the IPv4 address is encoded in positions 72 to 103.</t>
<t>When the prefix is 96 bits long, the IPv4 address is encoded in positions 96 to 127.</t>
</list>
<t>
There are no remaining bits, and thus no suffix, if the prefix is 96 bits long.
In the other cases, the remaining bits of the address constitute the suffix.
These bits are reserved for future extensions, and SHOULD be set to zero.
</t>
</section>
<section title="Address Translation Algorithms" anchor="algorithm">
<t>
IPv4-Embedded IPv6 addresses are composed according to the following algorithm:
</t>
<list style='symbols'>
<t>
Concatenate the prefix, the 32 bits of the IPv4 address and the null suffix
if needed to obtain a 128 bit address.
</t>
<t>
If the prefix length is less than 96 bits, insert the null octet
"u" at the appropriate position, thus causing the least significant
octet to be excluded, as documented in <xref target="addressFigure" />.
</t>
</list>
<t>
The IPv4 addresses are extracted from the IPv4-Embedded IPv6 addresses
according to the following algorithm:
</t>
<list style='symbols'>
<t>
If the prefix is 96 bit long, extract the last 32 bits of the IPv6 address;
</t>
<t>
for the other prefix lengths, extract the "u" octet to obtain a 120 bit sequence,
then extract the 32 bits following the prefix.
</t>
</list>
</section>
<section title="Text Representation" anchor="textRep">
<t>
IPv4-Embedded IPv6 addresses will be represented in text in conformity with
section 2.2 of <xref target="RFC4291" />. IPv4-Embedded IPv6 addresses constructed
using the Well-Known
Prefix or a /96 Network-Specific Prefix may be represented using the alternative form presented in
section 2.2 of <xref target="RFC4291" />, with the embedded IPv4 address represented in
dotted decimal notation. Examples of such representations are presented in
<xref target="textTable" /> and <xref target="textTableWkp" />.
</t>
<texttable anchor="textTable" title="Text representation of IPv4-Embedded IPv6 addresses using Network-Specific Prefixes ">
<ttcol align='left'>Network-Specific Prefix</ttcol>
<ttcol align='center'>IPv4 address</ttcol>
<ttcol align='left'>IPv4-Embedded IPv6 address</ttcol>
<c>2001:DB8::/32</c>
<c>192.0.2.33</c>
<c>2001:DB8:C000:221::</c>
<c>2001:DB8:100::/40</c>
<c>192.0.2.33</c>
<c>2001:DB8:1C0:2:21::</c>
<c>2001:DB8:122::/48</c>
<c>192.0.2.33</c>
<c>2001:DB8:122:C000:2:2100::</c>
<c>2001:DB8:122:300::/56</c>
<c>192.0.2.33</c>
<c>2001:DB8:122:3C0:0:221::</c>
<c>2001:DB8:122:344::/64</c>
<c>192.0.2.33</c>
<c>2001:DB8:122:344:C0:2:2100::</c>
<c>2001:DB8:122:344::/96</c>
<c>192.0.2.33</c>
<c>2001:DB8:122:344::192.0.2.33</c>
</texttable>
<texttable anchor="textTableWkp" title="Text representation of IPv4-Embedded IPv6 addresses using the Well-Known Prefix">
<ttcol align='left'>Well Known Prefix</ttcol>
<ttcol align='center'>IPv4 address</ttcol>
<ttcol align='left'>IPv4-Embedded IPv6 address</ttcol>
<c>64:FF9B::/96</c>
<c>192.0.2.33</c>
<c>64:FF9B::192.0.2.33</c>
</texttable>
<t>
The Network-Specific Prefix examples in
<xref target="textTable" /> are derived from the
IPv6 prefix reserved for documentation in <xref target="RFC3849"/>.
The IPv4 address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for documentation in <xref target="RFC5735"/>.
</t>
</section>
</section>
<section title="Deployment Guidelines and Choices" anchor="choices">
<section title="Restrictions on the use of the Well-Known Prefix" anchor="wpfUsage">
<t>
The Well-Known Prefix MAY be used by organizations deploying translation services,
as explained in <xref target="stateful" />.
</t>
<t>
The Well-Known Prefix SHOULD NOT be used to construct IPv4-Translatable addresses.
The nodes served by IPv4-Translatable IPv6
addresses should be able to receive global IPv6 traffic
bound to their IPv4-Translatable IPv6 address
without incurring intermediate protocol translation.
This is only possible if the specific prefix used to build the
IPv4-Translatable IPv6 addresses
is advertized in inter-domain routing, but the advertisement of
more specific prefixes derived from the Well-Known Prefix
is not supported, as explained in <xref target="routing" />.
Network-Specific Prefixes SHOULD be used in these scenarios, as explained in
<xref target="stateless" />.
</t>
<t>
The Well-Known Prefix MUST NOT be used to represent non global IPv4 addresses, such as
those defined in <xref target="RFC1918"/>.</t>
</section>
<section title="Impact on Inter-Domain Routing" anchor="routing">
<t>
The Well-Known Prefix MAY appear in inter-domain routing tables, if service
providers decide to provide IPv6-IPv4 interconnection services to peers.
Advertisement of the Well-Known Prefix SHOULD be controlled either by upstream
and/or downstream service providers owing to inter-domain routing policies, e.g.,
through configuration of BGP <xref target="RFC4271"/>. Organizations that advertize the
Well-Known Prefix in
inter-domain routing MUST be able to provide IPv4/IPv6 translation service.
</t>
<t>
When the IPv4/IPv6 translation relies on the Well-Known Prefix,
embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be advertised
in BGP (especially e-BGP) <xref target="RFC4271"/> because this leads to importing
the IPv4 routing table
into the IPv6 one and therefore induces scalability issues to the global IPv6
routing table. Administrators of BGP nodes SHOULD configure filters that
discard advertisements of embedded
IPv6 prefixes longer than the Well-Known Prefix.
</t>
<t>
When the IPv4/IPv6 translation service relies on Network-Specific
Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless translation MUST
be advertised with proper aggregation to the IPv6 Internet.
Similarly, if translators are configured with multiple
Network-Specific Prefixes,these prefixes MUST be advertised to the
IPv6 Internet with proper aggregation.
</t>
</section>
<section title="Choice of Prefix for Stateless Translation Deployments"
anchor="stateless">
<t>
Organizations may deploy translation services using stateless translation. In these
deployments, internal IPv6 nodes are addressed using IPv4-Translatable IPv6 addresses,
which enable them to be accessed by IPv4 nodes. The addresses of these external IPv4
nodes are then represented in IPv4-Converted IPv6 addresses.
</t>
<t>
Organizations deploying stateless IPv4/IPv6 translation SHOULD
assign a Network-Specific Prefix to their IPv4/IPv6 translation service.
IPv4-Translatable and IPv4-Converted IPv6 addresses
MUST be constructed as specified in <xref target="addressFormat" />.
IPv4-Translatable IPv6 addresses MUST use the selected Network-Specific Prefix.
Both IPv4-Translatable IPv6 addresses and IPv4-Converted IPv6 addresses
SHOULD use the same prefix.
</t>
<t>
Using the same prefix ensures that IPv6 nodes internal to the organization
will use the most efficient paths to reach the nodes served by
IPv4-Translatable IPv6 addresses. Specifically, if a node
learns the IPv4 address of a target internal node without knowing that this target
is in fact located behind the same translator that the node also uses, translation
rules will ensure that the
IPv6 address constructed with the Network-Specific prefix is the same as
the IPv4-Translatable IPv6 address assigned to the target. Standard routing
preference (more specific wins)
will then ensure that the IPv6 packets are delivered directly, without
requiring "hair-pinning" at the translator.
</t>
<t>
The intra-domain routing protocol must be able to deliver packets to the nodes served by
IPv4-Translatable IPv6 addresses. This may require routing on some or all of the embedded
IPv4 address bits. Security considerations detailed in <xref target="security" /> require
that routers check the validity of the IPv4-Translatable IPv6 source addresses, using
some form of reverse path check.
</t>
<t>
The management of stateless address translation
can be illustrated with a small example. We will consider an IPv6 network
with the prefix 2001:DB8:122::/48. The network administrator has selected the Network-Specific
prefix 2001:DB8:122:344::/64 for managing stateless IPv4/IPv6 translation.
The IPv4-Translatable address block is
2001:DB8:122:344:C0:2::/96 and this block
is visible in IPv4 as the subnet 192.0.2.0/24. In this network, the host A is assigned the
IPv4-Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which corresponds to the
IPv4 address 192.0.2.33. Host A's address is configured either manually or through DHCPv6.
</t>
<t>
In this example, host A is not directly connected to the translator, but instead to
a link managed by a router R. The router R is configured to forward to A the packets
bound to 2001:DB8:122:344:C0:2:2100::. To receive these packets, R will advertise
reachability of the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain
routing protocol -- or perhaps a shorter prefix if many hosts on link have
IPv4-Translatable IPv6 addresses derived from the same IPv4 subnet. If a packet bound to
192.0.2.33 reaches the translator, the destination
address will be translated to 2001:DB8:122:344:C0:2:2100::, and the packet will be routed
towards R and then to A.
</t>
<t>
Let's suppose now that a host B
of the same domain learns the IPv4 address of A, maybe
through an application-specific referral. If B has translation-aware software,
B can compose a destination address by combining
the Network-Specific Prefix 2001:DB8:122:344::/64 and the IPv4 address 192.0.2.33,
resulting in the address 2001:DB8:122:344:C0:2:2100::. The packet sent by B will
be forwarded towards R, and then to A, avoiding protocol translation.
</t>
<t>
Forwarding, and reverse path checks, should be performed on the combination of the prefix
and the IPv4 address. In theory, routers should be able to route on prefixes of any length.
However, routing on prefixes larger than 64 bits may be slower on some routers.
But routing efficiency is not the only consideration
in the choice of a prefix length. Organizations also need to consider the availability of
prefixes, and the potential impact of all-zeroes identifiers.
</t>
<t>
If a /32 prefix is used, all the routing bits are contained in the top 64 bits of the IPv6
address, leading to excellent routing properties. These prefixes may however be hard to obtain,
and allocation of a /32 to a small set of
IPv4-Translatable IPv6 addresses may be seen as wasteful.
In addition, the /32 prefix and a zero suffix leads to an all-zeroes
interface identifier, an issue that we discuss in <xref target="suffixDiscuss" />.
</t>
<t>
Intermediate prefix lengths such as
/40, /48 or /56 appear as compromises. Only some of
the IPv4 bits are part of the /64 prefixes. Reverse path checks, in particular,
may have a limited efficiency.
Reverse path checks limited to the most significant bits of the IPv4 address will
reduce the possibility
of spoofing external IPv4 addresses, but would allow IPv6 nodes to spoof
internal IPv4-Translatable IPv6 addresses.
</t>
<t>
We propose here a compromise, based on using no more than 1/256th of an
organization's allocation of IPv6 addresses for the IPv4/IPv6 translation service.
For example, if the organization is an Internet Service Provider
with an allocated IPv6 prefix /32 or
shorter, the ISP could dedicate a /40 prefix to the translation service.
An end site with a /48 allocation could dedicate a /56 prefix to the translation
service, or possibly a /96 prefix if all IPv4-Translatable IPv6 addresses
are located on the same link.
</t>
<t>
The recommended prefix length is also a function of the deployment scenario.
The stateless translation can be used for Scenario 1, Scenario 2, Scenario 5,
and Scenario 6 defined in <xref target="I-D.ietf-behave-v6v4-framework" />.
For different scenarios, the prefix length recommendations are:</t>
<list style="symbols">
<t>
For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 2
(the IPv4 Internet to an IPv6 network), we recommend using a /40 prefix
for an ISP holding a /32 allocation, and a /56 prefix for
a site holding a /48 allocation.
</t>
<t>
For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6
(an IPv4 network to an IPv6 network), we recommend using a /64 or a /96 prefix.
</t>
</list>
<t>
IPv4-Translatable IPv6 addresses SHOULD follow the
IPv6 address architecture and SHOULD be compatible with the IPv4
address architecture. The first
IPv4-translatable address is the subnet-router anycast address in IPv6 and
network identifier in IPv4, the last IPv4-translatable address is the subnet
broadcast addresses in IPv4. Both of them SHOULD NOT be used for IPv6 nodes.
In addition, the minimum IPv4 subnet can be used for hosts is /30
(the router interface needs a valid address for the same subnet) and
this rule SHOULD also be applied to the corresponding subnet of the
IPv4-translatable addresses.
</t>
</section>
<section title="Choice of Prefix for Stateful Translation Deployments" anchor="stateful">
<t>
Organizations may deploy translation services based on stateful
translation technology. An organization may decide to use either a
Network-Specific Prefix or the Well-Known Prefix
for its stateful IPv4/IPv6 translation service.
</t>
<t>
When these services are used, IPv6 nodes are addressed through standard IPv6
addresses, while IPv4 nodes are represented by IPv4-Converted IPv6 addresses, as
specified in <xref target="addressFormat" />.
</t>
<t>
The stateful nature of the translation creates a potential stability issue
when the organization
deploys multiple translators. If several translators use the same prefix,
there is a risk that
packets belonging to the same connection may be routed to different
translators as the internal
routing state changes. This issue can be avoided either by assigning
different prefixes to
different translators, or by ensuring that all translators using same
prefix coordinate their state.
</t>
<t>
Stateful translation can be used in scenarios defined in
<xref target="I-D.ietf-behave-v6v4-framework"/>. The Well Known Prefix SHOULD be used
in these scenarios, with two exceptions:
</t>
<list style="symbols">
<t>
In all scenarios, the translation MAY use a Network-Specific Prefix, if deemed
appropriate for management reasons.
</t>
<t>
The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet to an
IPv4 network), as this would lead to using the Well-Known Prefix with non-global
IPv4 addresses. That means a Network-Specific Prefix MUST be used in that scenario,
for example a /96 prefix compatible with the Well-Known prefix format.
</t>
</list>
</section>
<section title="Choice of Suffix" anchor="suffixDiscuss">
<t>
The address format described in <xref target="addressFormat" /> recommends a zero suffix.
Before making this recommendation,
we considered different options: checksum neutrality; the encoding of a port range;
and a value different than 0.
</t>
<t>
In the case of stateless translation, there would be no need for the translator
to recompute a one's complement checksum if both the IPv4-Translatable and the
IPv4-Converted IPv6 addresses were constructed in a "checksum-neutral" manner, that is if the
IPv6 addresses would have the same one's complement checksum as the embedded IPv4
address. In the case of stateful translation, checksum neutrality does not eliminate checksum
computation during translation, as only one of the two addresses would be checksum neutral.
We considered reserving 16 bits in the suffix to guarantee checksum neutrality,
but declined because it would not help with stateful translation, and because checksum neutrality
can also be achieved by an appropriate choice of the Network-Specific Prefix,
as was done for example with the Well-Known Prefix.
</t>
<t>
There have been proposals to complement stateless translation with a port-range feature.
Instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would allow
several IPv6 nodes to share an IPv4 address, with each node managing a different range
of ports. If a port
range extension is needed, it could be defined later, using bits currently reserved as null
in the suffix.
</t>
<t>
When a /32 prefix is used, an all-zero suffix results in an
all-zero interface identifier.
We understand the conflict with Section 2.6.1 of RFC4291, which specifies
that all zeroes are used for the subnet-router anycast address. However,
in our specification, there would be only one node with an IPv4-Translatable
IPv6 address in
the /64 subnet, and the anycast semantic would not create confusion. We
thus decided to keep the null suffix for now.
This issue does not exist for prefixes larger than 32 bits, such as the /40,
/56, /64 and /96 prefixes that we recommend in <xref target="stateless" />.
</t>
</section>
<section title="Choice of the Well-Known Prefix" anchor="wpfDiscuss">
<t>
Before making our recommendation of the Well-Known Prefix, we were
faced with three choices:
</t>
<list style="symbols">
<t>
reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 2765 Section 2.1;
</t>
<t>
request IANA to allocate a /32 prefix,
</t>
<t>
or request allocation of a new /96 prefix.
</t>
</list>
<t>
We weighted the pros and cons of these choices before settling on the recommended
/96 Well-Known Prefix.
</t>
<t>
The main advantage of the existing IPv4-mapped prefix is that it is already defined.
Reusing that prefix would require minimal standardization efforts. However, being
already defined is not just an advantage, as there may be side effects of current
implementations. When presented with the IPv4-mapped prefix, current versions of
Windows and MacOS generate IPv4 packets, but will not send IPv6 packets. If
we used the IPv4-mapped prefix, these nodes would not be able to support translation
without modification. This will defeat the main purpose of the translation techniques.
We thus eliminated the first choice, and decided to not reuse
the IPv4-mapped prefix, ::FFFF:0:0/96.
</t>
<t>
A /32 prefix would have allowed the embedded
IPv4 address to fit within the top 64 bits of the IPv6 address. This would have
facilitated routing and load balancing when an organization deploys several
translators. However, such destination-address based load balancing may not
be desirable. It is not compatible with STUN in the deployments involving
multiple stateful translators, each one having a different pool of IPv4 addresses.
STUN compatibility would only be achieved if the translators managed the same pool
of IPv4 addresses and were able to coordinate their translation state, in which
case there is no big advantage to using a /32 prefix rather than a /96 prefix.
</t>
<t>
According to Section 2.2 of <xref target="RFC4291"/>, in the legal
textual representations of IPv6 addresses, dotted
decimal can only appear at the end. The /96 prefix is compatible with that
requirement. It enables the dotted
decimal notation without requiring an update to <xref target="RFC4291"/>. This
representation makes the address format easier to use, and log files easier to read.
</t>
<t>
The prefix that we recommend has the particularity of being "checksum neutral".
The sum of the hexadecimal numbers "0064" and "FF9B" is "FFFF", i.e. a value equal
to zero in one's complement arithmetic. An IPv4-Embedded IPv6 address constructed with this
prefix will have the same one's complement checksum as the embedded IPv4 address.
</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<section title="Protection Against Spoofing">
<t>
By and large, IPv4/IPv6 translators can be modeled as special routers, are subject to the same risks,
and can implement the same mitigations. There is however a particular risk that directly derives
from the practice of embedding IPv4 addresses in IPv6: address spoofing.
</t>
<t>
An attacker could use an IPv4-Embedded IPv6 address as the source address of malicious packets.
After translation, the packets will appear as IPv4 packets from the specified source, and
the attacker may be hard to track. If left without mitigation, the attack would allow
malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
</t>
<t>
The mitigation is to implement reverse path checks, and to verify throughout the network
that packets are coming from an authorized location.
</t>
</section>
<section title="Secure Configuration">
<t> The prefixes and formats need to be the configured consistently among
multiple devices
in the same network (e.g., nodes 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.
</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
The IANA is requested to add a note to the documentation of the 0000::/8 address
block in http://www.iana.org/assignments/ipv6-address-space to document
the assignment by the IETF of the Well Known Prefix.
For example:
</t>
<list style="empty">
<t/>
<t>
The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic mapping
between IPv4 to IPv6
addresses is defined out of the 0000::/8 address block, per (this document).
</t>
</list>
</section>
<section title="Acknowledgements">
<t> Many people in the Behave WG have contributed to the discussion
that led to this document, including Andrew Sullivan,
Andrew Yourtchenko, Brian Carpenter, Dan Wing, Ed
Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John
Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund,
Margaret Wasserman, Masahito Endo, Phil Roberts,
Philip Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
</t>
<t>
Marcelo Bagnulo is partly funded by
Trilogy, a research project supported by the European Commission
under its Seventh Framework Program.
</t>
</section>
<section title="Contributors">
<t> The following individuals co-authored drafts from which text has been
incorporated, and are listed in alphabetical order.
</t>
<figure align="center">
<artwork align="left"><![CDATA[
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 62785983
Email: congxiao@cernet.edu.cn
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
Email: fred@cisco.com
Hiroshi Miyata
Yokogawa Electric Corporation
2-9-32 Nakacho
Musashino-shi, Tokyo 180-8750
JAPAN
Email: h.miyata@jp.yokogawa.com
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
ESPANA
Email: marcelo@it.uc3m.es
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 62785983
Email: xing@cernet.edu.cn
]]></artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4291;
</references>
<references title="Informative References">
&rfc1918;
&rfc3484;
&rfc3849;
&rfc4271;
&rfc4380;
&rfc5214;
&rfc5735;
&I-D.ietf-behave-v6v4-framework;
&I-D.ietf-behave-dns64;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:14 |