One document matched: draft-baker-behave-v4v6-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict='yes' ?>
<!-- Items used when reviewing the document -->
<?rfc comments='no' ?>
<!-- Controls display of <cref> elements -->
<?rfc inline='no' ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing='no' ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc='yes'?>
<?rfc tocompact='yes'?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes' ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info"
docName="draft-baker-behave-v4v6-framework-00" ipr="full3978">
<front>
<title>Framework for IPv4/IPv6 Translation</title>
<author fullname="Fred Baker" initials="F.J." role="editor"
surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<phone>+1-408-526-4257</phone>
<facsimile>+1-413-473-2403</facsimile>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2008" />
<area>Transport</area>
<workgroup>behave</workgroup>
<abstract>
<t>This note describes a framework for IPv4/IPv6 translation. This is in
the context of replacing NAT-PT, which was deprecated by RFC 4966, and
to enable networks to have IPv4 and IPv6 coexist in a somewhat rational
manner while transitioning to an IPv6 network.</t>
</abstract>
<!--
<note title='Foreword'>
</note>
-->
<note title="Requirements Language">
<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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
<!--
<?rfc needLines='10' ?>
<texttable anchor='table_example' title='A Very Simple Table'>
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align='center'>ttcol #1</ttcol>
<ttcol align='center'>ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: 'symbols', 'letters', 'numbers',
'hanging', 'format', etc.
</t>
<t>
<list style='symbols'>
<t>First bullet
</t>
<t>Second bullet
</t>
</list>
</t>
-->
<!--
<figure anchor='xml_happy' title='Figure N'>
<artwork align='center'>
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>This note describes a framework for IPv4/IPv6 translation. This is in
the context of replacing <xref target="RFC2766">NAT-PT</xref>, which was
deprecated by <xref target="RFC4966"></xref>, and to enable networks to
have IPv4 and IPv6 coexist in a somewhat rational manner while
transitioning to an IPv6-only network.</t>
<t>Deprecation of NAT-PT wasn't intended to say that NAT-PT was "bad",
nor did the IETF think that deprecating the technology would stop people
from using it. As with the 1993 deprecation of the RIP routing protocol
at the time the Internet was converting to CIDR, the point was to inform
the community that NAT-PT had operational issues and was not considered
a viable medium or long term strategy for either coexistence or
transition. The point was to encourage network operators to actually
move in the direction of transition.</t>
<t><xref target="RFC4213"></xref> describes the IETF's view of the most
sensible transition model. The IETF recommends, in short, that network
operators (transit providers, service providers, enterprise networks,
small and medium business, SOHO and residential customers, and any other
kind of network that may currently be using IPv4) obtain an IPv6 prefix,
turn on IPv6 routing within their networks and between themselves and
any peer, upstream, or downstream neighbors, enable it on their
computers, and use it in normal processing. This should be done while
leaving IPv4 stable, until a point is reached that any communication
that can be carried out could use either protocol equally well. At that
point, the economic justification for running both becomes debatable,
and network operators can justifiably turn IPv4 off. This process is
comparable to that of <xref target="RFC4192"></xref>, which describes
how to renumber a network using the same address family without a flag
day. While running stably with the older system, deploy the new. Use the
coexistence period to work out such kinks as arise. When the new is also
running stably, shift production to it. When network and economic
conditions warrant, remove the old, which is now no longer
necessary.</t>
<t>The question arises: what if that is infeasible due to the time
available to deploy or other considerations? What if the process of
moving a network and its components or customers is starting too late
for contract cycles to effect IPv6 turn-up on important parts at a point
where it becomes uneconomical to deploy global IPv4 addresses in new
services? How does one continue to deploy new services without
balkanizing the network?</t>
<t>This set of documents describes translation as one of the tools
networks might use to facilitate coexistence and ultimate
transition.</t>
<section anchor="why" title="Why translation?">
<t>Besides dual stack deployment, there are two fundamental approaches
one could take to interworking between IPv4 and IPv6: tunneling and
translation. One could - and in the 6NET we did - build an overlay
network using the new protocol inside tunnels. Various proposals take
that model, including <xref target="RFC3056">6to4</xref>, <xref
target="RFC4380">Teredo</xref>, <xref
target="RFC5214">ISATAP</xref>,and <xref
target="I-D.durand-softwire-dual-stack-lite">DS-Lite</xref>. The
advantage of doing so is that the new is enabled to work without
disturbing the old protocol, providing connectivity between users of
the new protocol. There are two disadvantages to tunneling:<list
style="symbols">
<t>operators of those networks are unable to offer services to
users of the new architecture, and those users are unable to use
the services of the underlying infrastructure - it is just
bandwidth, and</t>
<t>it doesn't enable new protocol users to communicate with old
protocol users.</t>
</list></t>
<t>As noted, in this work, we look at Internet Protocol translation as
a transition strategy. <xref target="RFC4864"></xref> forcefully makes
the point that many of the reasons people use Network Address
Translators are met as well by routing or protocol mechanisms that
preserve the end to end addressability of the Internet. What it did
not consider is the case in which there is an ongoing requirement to
communicate with IPv4 systems, but configuring IPv4 routing is not in
the network operator's view the most desirable strategy, or is
infeasible due to a shortage of global address space. Translation
enables the client of a network, whether a transit network, an access
network, or an edge network, to access the services of the network and
communicate with other network users regardless of their protocol
usage - within limits. Like NAT-PT, IPv4/IPv6 translation under this
rubric is not a long term support strategy, but it is a medium term
coexistence strategy that can be used to facilitate a long term
program of transition.</t>
</section>
<section anchor='glossary' title="Terminology">
<t>The following terminology is used in this document and other
documents related to it. <list style="hanging">
<t hangText="Advertised IPv4 Prefix:">The IPv4 prefix, if any,
subdivided into Mapped IPv4 Prefixes in the IPv6-only domain. This is
advertised in routing in the IPv4 domain to attract traffic
intended for mapped IPv4 addresses in the IPv6-only domain.</t>
<t hangText="Dual Stack impementation:">A Dual Stack
implementation, in this context, comprises an enabled end system
stack plus routing in the network. It implies that two application
instances are capable of communicating using either IPv4 or IPv6 -
they have stacks, they have addresses, and they have any necessary
network support including routing.</t>
<t hangText="IPv4-only:">An IPv4-only implementation, in this
context, comprises an enabled end system stack plus routing in the
network. It implies that two application instances are capable of
communicating using either IPv4 but not IPv6 - they have an IPv4
stack, addresses, and network support including IPv4 routing and
potentially IPv4/IPv4 translation, but some element is missing
that prevents communication using IPv6.</t>
<t hangText="IPv6-only:">An IPv6-only implementation, in this
context, comprises an enabled end system stack plus routing in the
network. It implies that two application instances are capable of
communicating using either IPv6 but not IPv4 - they have an IPv6
stack, addresses, and network support including routing in IPv6,
but some element is missing that prevents communication using
IPv4.</t>
<t hangText="LIR Prefix:">The IPv6 prefix assigned by the network
operator for direct mapping of IPv6 addresses to IPv4.</t>
<t hangText="LIR:">See Local Internet Registry.</t>
<t hangText="Local Internet Registry:">A Local Internet Registry
(LIR) is an organization which has received an IP address
allocation from a Regional Internet Registry (RIR), and which may
assign parts of this allocation to its own internal network or
those of its customers. An LIR is thus typically an Internet
service provider or an enterprise network.</t>
<t hangText="Mapped IPv4 Address:">An IPv6 address within a Mapped
IPv4 Prefix.</t>
<t hangText="Mapped IPv4 Prefix:">An IPv6 prefix constructed from
an LIR prefix and an IPv4 prefix.</t>
<t hangText="Overlay IPv4 Prefix:">Zero or more IPv4 addresses
used in stateful translation.</t>
<t hangText="State:">"State" refers to dynamic information that is
stored in a network element. For example, if two systems are
connected by a TCP connection, each stores information about the
connection, which is called "connection state". In this context,
the term refers to correlations between IP addresses on either
side of a translator, or {IP Address, Transport type, transport
port number} tuples on either side of the translator. Of stateful
algorithms, there are at least two major flavors depending on the
kind of state they maintain: <list style="hanging">
<t hangText="Hidden state:">the existence of this state is
unknown outside the network element that contains it.</t>
<t hangText="Known state:">the existence of this state is
known by other network elements.</t>
</list></t>
<t hangText="Stateful Translation:">A translation algorithm may be
said to "require state in a network element" or be "stateful" if
the transmission or reception of a packet creates or modifies a
data structure in the relevant network element.</t>
<t hangText="Stateless Translation:">A translation algorithm that
is not "stateful" is "stateless". It may require configuration of
a translation table, or may derive its needed information
algorithmically from the messages it is translating.</t>
</list></t>
</section>
<section anchor="requirements" title="Translation objectives">
<t>In any translation model, there is a question of objectives.
Ideally, one would like to make any system and any application running
on it able to "talk with" - exchange datagrams supporting applications
- with any other system running the same application regardless of
whether they have an IPv4 stack and connectivity or IPv6 stack and
connectivity. That was the model NAT-PT, and the things it
necessitated led to scaling and operational difficulties.</t>
<t>So the question comes back to what different kinds of connectivity
can be easily supported and what are harder, and what technologies are
needed to at least pick the low-hanging fruit. We observe that
applications today fall into three main categories:<list
style="hanging">
<t hangText="Client/Server Application:">Per whatis.com,
"'Client/server' describes the relationship between two computer
programs in which one program, the client, makes a service request
from another program, the server, which fulfills the request." In
networking, the behavior of the applications is that connections
are initiated from client software and systems to server software
and systems. Examples include mail handling between an end user
and his mail system (POP3, IMAP, and MUA->MTA SMTP), FTP, the
web, and DNS name translation.</t>
<t hangText="Peer to Peer Application:">Peer to peer applications
are those that transfer information directly, rather than through
the use of an intermediate repository such as a bulletin board or
database. In networking, any system (peer) might initiate a
session with any other system (peer) at any time. These in turn
fall broadly into two categories:<list style="hanging">
<t
hangText="Peer to peer inrastructure applications:">Examples
of "infrastructure applications" include SMTP between MTAs,
Network News, and SIP. Any MTA might open an SMTP session with
any other at any time; any SIP Proxy might similarly connect
with any other SIP Proxy. An important characteristic of these
applications is that they use ephemeral sessions - they open
sessions when they are needed and close them when they are
done.</t>
<t
hangText="Peer to peer file exchange applications:">Examples
of these include Limewire, BitTorrent, and UTorrent. These are
applications that open some sessions between systems and leave
them open for long periods of time, and where ephemeral
sessions are important, are able to learn about the
reliability of peers from history or by reputation. They use
the long term sessions to map content availability. Short term
sessions are used to exchange content. They tend to prefer to
ask for content from servers that they find reliable and
available.</t>
</list></t>
</list></t>
<t>NAT-PT is an example of a facility with known state - at least two
software components (the data plane translator and the DNS Application
Layer Gateway, which may be implemented in the same or different
systems) share and must coordinate translation state. A typical
IPv4/IPv4 NAT implements an algorithm with hidden state. Obviously,
stateless translation requires less computational overhead than
stateful translation, and less memory to maintain the state, because
the translation tables and their associated methods and processes
exist in a stateful algorithm and don't exist in a stateless one.</t>
<t>If the key questions are the ability to open connections between
systems, then one must ask who opens connections. <list
style="symbols">
<t>We need a technology that will enable systems that act as
clients to be able to open sessions with other systems that act as
servers, whether in the IPv6->IPv4 direction or the
IPv4->IPv6 direction. Ideally, this is stateless; especially in
a carrier infrastructure, the preponderance of accesses will be to
servers, and this optimizes access to them. However, a stateful
algorithm is acceptable if the complexity is minimized and a
stateless algorithm cannot be constructed.</t>
<t>We also need a technology that will allow peers to connect with
each other, whether in the IPv6->IPv4 direction or the
IPv4->IPv6 direction. Again, it would be ideal if this was
stateless, but a stateful algorithm is acceptable if the
complexity is minimized and a stateless algorithm cannot be
constructed. In the case of infrastructure applications, which
know nothing of choosing among peers by reputation, the
IPv4->IPv6 direction is a stronger requirement. Peer to peer
file exchange applications, however, may be more forgiving - it
may well be adequate to make a subset of IPv4->IPv6 connections
work instead of all. (EDITOR'S NOTE: I would be very interested in
comments on this assertion)</t>
<t>We do not need an algorithm that enables clients to connect to
clients, because they don't connect.</t>
</list></t>
<t>The complexity arguments bring us in the direction of hidden state:
if state must be shared between the application and the translator or
between translation components, complexity and deployment issues are
greatly magnified. We would very much prefer that any software changes
be confined to the translator.</t>
</section>
<section anchor="plan" title="Transition Plan">
<t>While IPv6 was "by design" incompatible with IPv4, the designers
intended that it would coexist with IPv4 during a period of
transition. The primary mode of coexistence was dual-stack operation -
routers would be dual-stacked so that the network could carry both
address families, and IPv6-capable hosts could be dual-stack to
maintain access to IPv4-only partners. The goal was that the
preponderance of hosts and routers in the Internet would be
IPv6-capable long before IPv4 address space allocation was completed.
At this time, it appears the exhaustion of IPv4 address space will
occur before significant IPv6 adoption.</t>
<t>Curran's <xref target="RFC5211">"A Transition Plan for IPv6"
</xref> proposes a three-phase progression: <list style="hanging">
<t hangText="Preparation Phase (current):">characterized by pilot
use of IPv6, primarily through transition mechanisms defined in
RFC 4213, and planning activities.</t>
<t hangText="Transition Phase (2010 through 2011):">characterized
by general availability of IPv6 in provider networks which SHOULD
be native IPv6; organizations SHOULD provide IPv6 connectivity for
their Internet-facing servers, but SHOULD still provide IPv4-based
services via a separate service name.</t>
<t
hangText="Post-Transition Phase (2012 and beyond):">characterized
by a preponderance of IPv6-based services and diminishing support
for IPv4-based services.</t>
</list></t>
<t>In each of these phases, the coexistence problem and solution space
has a different focus: <list style="hanging">
<t hangText="Preparation Phase:">Coexistence tools are needed to
facilitate early adopters by removing impediments to IPv6
deployment, and to assure that nothing is lost by adopting IPv6,
in particular that the IPv6 adopter has unfettered access to the
global IPv4 Internet regardless of whether they have a global IPv4
address (or any IPv4 address or stack at all.) While it might
appear reasonable for the cost and operational burden to be borne
by the early adopter, the shared goal of promoting IPv6 adoption
would argue against that model. Additionally, current IPv4 users
should not be forced to retire or upgrade their equipment and the
burden remains on service providers to carry and route native
IPv4.</t>
<t hangText="Transition Phase:">While IPv6 adoption can be
expected to accelerate, there will still be a significant portion
of the Internet operating in IPv4-only or preferring IPv4. During
this phase the norm shifts from IPv4 to IPv6, and coexistence
tools evolve to ensure interoperability between domains that may
be restricted to IPv4 or IPv6.</t>
<t hangText="Post-Transition Phase:">In this phase, IPv6 is
ubiquitous and the burden of maintaining interoperability shifts
to those who choose to maintain IPv4-only systems. While these
systems should be allowed to live out their economic life cycles,
the IPv4-only legacy users at the edges should bear the cost of
coexistence tools, and at some point service provider networks
should not be expected to carry and route native IPv4 traffic.</t>
</list></t>
<t>The choice between the terms "transition" versus "coexistence" has
engendered long philosophical debate. "Transition" carries the sense
that we are going somewhere, while "coexistence" seems more like we
are sitting somewhere. Historically with IETF, "transition" has been
the term of choice <xref target="RFC4213"></xref><xref
target="RFC5211"></xref>, and the tools for interoperability have been
called "transition mechanisms". There is some perception or
conventional wisdom that adoption of IPv6 is being impeded by the
deficiency of tools to facilitate interoperability of nodes or
networks that are constrained (in some way, fully or partially) from
full operation in one of the address families. In addition, it is
apparent that transition will involve a period of coexistence; the
only real question is how long that will last.</t>
<t>Thus, coexistence is an integral part of the transition plan, not
in conflict with it, but there will be a balancing act. It starts out
being a way for early adopters to easily exploit the bigger IPv4
Internet, and ends up being a way for late/never adopters to hang on
with IPv4 (at their own expense, with minimal impact or visibility to
the Internet). One way to look at solutions is that cost incentives
(both monetary cost and the operational overhead for the end user)
should encourage IPv6 and discourage IPv4. That way natural market
forces will keep the transition moving - especially as the legacy
IPv4-only stuff ages out of use. There will come a time to set a date
after which no one is obligated to carry native IPv4 but it would be
premature to attempt to do so yet. The end goal should not be to
eliminate IPv4 by fiat, but rather render it redundant through
ubiquitous IPv6 deployment. IPv4 may never go away completely, but
rational plans should move the costs of maintaining IPv4 to those who
insist on using it after wide adoption of IPv6.</t>
</section>
<section anchor="uses" title="Expected uses of translation">
<t>There are several potential uses of translation. They are all
easily described in terms of "interoperation between a set of systems
that only communicate using IPv4 and a set of systems that only
communicate using IPv6", but the differences at a detail level make
them interesting. At minimum, these include:<list style="symbols">
<t>Connection of IPv4-only islands to an IPv6-only network</t>
<t>Connection of IPv6-only islands to an IPv4-only network</t>
<t>Connecting IPv4-only devices with IPv6-only devices regardless of
network type</t>
<t>Connections between IPv4-only networks and IPv6-only networks, especially
as a service within a large network such as an enterprise or ISP
network or between peer networks.</t>
</list></t>
<section anchor="v4island"
title="Connection of IPv4-only islands to an IPv6-only network">
<t>While the basic issue is the same, there are at least two
interesting special cases of this: connecting a small pool of legacy
equipment with a view to eventual obsolescence, and connecting a
legacy network with a view to eventual transition.</t>
<figure anchor="case1"
title="Printer pool or other legacy equipment">
<artwork align="center"><![CDATA[
+----+ +----+ +----+ +----+
|IPv6| |IPv6| |IPv6| +----------+ |IPv4|
|Host| |Host| |Host| |Translator| |Host|
+--+-+ +--+-+ +--+-+ +-+------+-+ +--+-+
| | | | | |
---+------+------+-----+- -+------+--
]]></artwork>
</figure>
<t>In the first case, <xref target="case1"></xref>, one might have a
pool of equipment (printers, perhaps) that is IPv4-capable, but
either the network it serves or some equipment in that network is
IPv6-only. One pools the IPv4-only devices behind a translator,
which enables IPv6-only systems to connect to the IPv4-only equipment. If the
network is dual stack and only some of the equipment is IPv6-only,
the translator should be a function of a router, and the router
should provide normal IPv4 routing services as well as IPv6->IPv4
translation.</t>
<figure anchor="case2" title="Customer dual stack network">
<artwork align="center"><![CDATA[
----------
/// \\\
// IPv6 \\ 192.168.1.0/24
// ISP \\ +------+2001:db8:0:1::0/64
|/ \| | +---------------
| Allocates | | |
| 2001:db8::/60 to | |CPE |192.168.2.0/24
| Customer | |Router|2001:db8:0:2::0/64
| +--+ +---------------
| Doesn't know it, | | |
| but sees customer | | |192.168.3.0/24
|\ IPv4 as /| | |2001:db8:0:3::0/64
\\2001:db8::a.b.c.d // | +---------------
\\ // +------+
\\\ ///
---------- LIR prefix is 2001:db8::0/96
]]></artwork>
</figure>
<t><xref target="case2"></xref> creates transition options to a
customer network connected to an IPv6-only ISP, or some equivalent
relationship. The customer might internally be using traditional
IPv4 with NAT services, and the ISP might change its connection to
an IPv6-only network and encourage it to transition. If the ISP
assigns a /60 prefix to a SOHO, for example, the CPE router in the
SOHO could distribute several dual stack subnets internally, one for
wireless and one for each of several fixed LANs (the entertainment
system, his office, her office, etc). One of the /64 prefixes would
be dedicated to representing the SOHO's IPv4 addresses in the ISP or
the IPv4 network beyond it, and the other prefixes for the various
internal subnets. Internally, the subnets might carry prefix pairs
192.168.n.0/24 and 2001:db8:0.n::/64 for n in 1..15 (1..0xF), and
externally might appear as 2001:db8:0:n::/64 for the IPv6 subnets
and 2001:db8::192.168.n.0/120 for the IPv4 devices. Note that to
connect to an IPv4-only network beyond, RFC 1918 addresses would have to
be statefully mapped using traditional IPv4 mechanisms somewhere; if
this is done by the ISP, collusion on address mapping is required,
and the case in <xref target="iviservice"></xref> is probably a
better choice.</t>
<t>In this environment, the key issue is that one wants a prefix
that enables the entire <xref target="RFC1918"></xref> address space
to be embedded in a single /64 prefix, with the assumption that any
routing structure behind the translator is managed by IPv4
routing.</t>
</section>
<section anchor="v6island"
title="Connection of IPv6-only islands to an IPv4-only network">
<t>To be completed</t>
</section>
<section anchor="v4v6connect"
title="Connecting IPv4-only devices with IPv6-only devices">
<t>To be completed</t>
</section>
<section anchor="iviservice"
title="ISP-supported connections between IPv4-only networks and IPv6-only networks">
<t>In this case (see <xref target="cloud"></xref>) we presume that a
service provider or equivalent is offering a service in a network in
which IPv4 routing is not supported, but customers are allocated
relatively large pools of general IPv6 addresses, suitable for
clients of IPv4 or IPv6 hosts, and relatively small pools of
addresses mapped to global IPv4 addresses that are intended to be
accessible to IPv4 peers and clients through translation.
Presumably, there are a number of such customers, and the
administration wishes to use normal routing to manage the issues. As
a carrier offering, there is also a need for stateless
translation.</t>
<figure anchor="cloud"
title="Service provider translation with multiple interchange points">
<artwork align="center"><![CDATA[
-------- --------
// IPv4 \\ // IPv6 \\
/ Domain \ / Domain \
/ +----+ +--+ \
| |XLAT| |S3| | Sn: Servers
| +--+ +----+ +--+ | Hn: Clients
| |S1| +----+ |
| +--+ |DNS | +--+ | XLAT: translator
\ +--+ +----+ |H3| / DNS: DNS Server
\ |H1| / \ +--+ /
\ +--+ / \ /
/ \ / \
/ +----+ \
| +--+ |XLAT| +--+ |
| |S2| +----+ |S4| |
| +--+ +----+ +--+ |
| +--+ |DNS | +--+ |
\ |H2| +----+ |H4| /
\ +--+ / \ +--+ /
\\ // \\ //
-------- --------
]]></artwork>
</figure>
<t>Since <xref target="RFC4291"></xref> specifies that IPv6 prefixes
are 64 bits or shorter apart from host routes, one wishes to
allocate each customer a /64 mapped to a few IPv4 addresses and a
shorter prefix for his general use. The customer's CPE advertises
the two prefixes into the IPv6 routing domain to attract relevant
traffic. The translator advertises the mapped equivalent of an IPv4
default route into the IPv6 domain to attract all other traffic to
it, for translation into the IPv4 routing domain. It also advertises
an appropriate IPv4 prefix aggregating the mapped prefixes into the
IPv4 domain to attract traffic intended for these customers.</t>
<t>In this case, the LIR prefix MUST be within /32../63; a /64 puts
the entire IPv4 address space into the host part, which is
equivalent to the case in <xref target="v4island"></xref>, and a
prefix shorter than /32 wastes space with no redeeming argument. In
general, the LIR prefix should be 64 bits less the length of IPv4
prefixes it allocates to its IPv4-mapped customers. For example, if
it is allocating a mapped IPv4 /24 to each customer, the LIR prefix
used for mapping between IPv4 and IPv6 addresses should be a /40,
and the least significant bits in the IPv4 address form the host
part of the address.</t>
</section>
</section>
</section>
<section anchor="proposal" title="Framework">
<t>Having laid out the preferred transition model and the options for
implementing it (<xref target="why"></xref>), defined terms(),
considered the requirements (<xref target="requirements"></xref>),
considered the transition model (<xref target="plan"></xref>), and
considered the kinds of networks the facility would support (<xref
target="uses"></xref>), we now turn to a framework for IPv4/IPv6
translation. This framework has three main parts: <list style="symbols">
<t>The recommended address format</t>
<t>The functional components of a translation solution, which
include <list style="symbols">
<t>A DNS Application Layer Gateway,</t>
<t>An optional stateless translator, and</t>
<t>An optional stateful translator.</t>
</list></t>
<t>The operational characteristics of the solution.</t>
</list></t>
<section anchor="address" title="Mapped Address Format">
<figure anchor="mappedAddress" title="Mapped Address Format">
<artwork align="center"><![CDATA[
0 8 16 24 32 40 48 56 64 127
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LIR Prefix | IPv4 addr | entirely 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|<-----prefix part ---->|<--- host part --->|
]]></artwork>
</figure>
<t>As shown in <xref target="mappedAddress"></xref>, the mapped
address format has three components:<list style="hanging">
<t hangText="bits 0..n-1:">An LIR-specified prefix, either 32..63
bits long or 96 bits long,</t>
<t hangText="bits n..n+31">An embedded IPv4 address. Except in the
case of a 96 bit prefix, this address intentionally straddles the
boundary between <xref target="RFC4291"></xref>'s 64 bit "subnet"
locator and its 64 bit host identifier. The intention is that the
/64 be used in routing and the bits in the host part be used for
host identification as described in the address architecture.</t>
<t hangText="bits n+32..127:">Entirely zero; note that if n=96,
this is null.</t>
</list></t>
<t>The length of the LIR-specified prefix is itself specified by the
LIR to achieve its objectives. There are some obvious values that
might be popular, including /40, /44, and /96, but there is no
requirement than any of them be used; this is left to the operator's
discretion.</t>
</section>
<section anchor="components" title="Translation components">
<t>As noted in <xref target="uses"></xref>,translation involves
several components. An IPv4 client or peer must be able to determine
the address of its server by obtaining an A record from DNS even if
the server is IPv6-only - only has an IPv6 stack, or is in an
IPv6-only network. Similarly, an IPv6 client or peer must be able to
determine the address of its server by obtaining an AAAA record from
DNS even if the server is IPv4-only - only has an IPv4 stack, or is in
an IPv4-only network. Given the address, the client/peer must be able
to initiate a connection to the server/peer, and the server/peer must
be able to reply. It would be very nice if this scaled to the size of
regional networks with straightforward operational practice.</t>
<t>To that end, we describe four subsystems:<list style="symbols">
<t>A Domain Name System Translator</t>
<t>A stateless IPv4/IPv6 translator</t>
<t>A stateful IPv4/IPv6 translator</t>
<t>Application Layer Gateways for some applications</t>
</list></t>
<section anchor="dns" title="DNS Application Layer Gateway">
<t></t>
<t><xref target="DNS"></xref> describes the mechanisms by which a
DNS Translator is intended to operate. It is designed to operate on
the basis of known but fixed state: the resource records, and
therefore the names and addresses, that it translates are known to
the network outside of the translator, but the process of serving
them to applications does not interact with the translator in any
way.</t>
<t>There are at least three possible implementations of a DNS
Translator: <list style="hanging">
<t hangText="Static records:">One could literally program DNS
with corresponding A and AAAA records. This is most appropriate
for stub services such as access to a legacy printer pool.</t>
<t hangText="Dynamic Translation of static records:">In more
general operation, the expected behavior is for the application
to request both A and AAAA records, and for an A record to be
(retrieved and) translated by the DNS translator if and only if
no reachable AAAA record exists. This has ephemeral issues with
cached translations, which can be dealt with by caching only the
source record and forcing it to be translated whenever
accessed.</t>
<t
hangText="Static or Dynamic Translation of Dynamic DNS records:">In
Dynamic DNS usage, a system could potentially report the
translation of a name using a Mapped IPv4 Address, or using both
a Mapped IPv4 Address and some other address. The DNS translator
has several options; it could store a AAAA record for the Mapped
IPv4 Address and depend on translation of that for A records
inline, it could store both an A and a AAAA record, or (when
there is another IPv6 address as well which is stored as the
AAAA record) it could store only the A record.</t>
</list></t>
</section>
<section anchor="stateless"
title="Stateless Translation - mapped addresses">
<t><xref target="XLAT"></xref> describes and defines the behavior of
a stateless translator. This is an optional facility; one could
implement or deploy only the stateful mode described in <xref
target="stateful"></xref>. Stateless translation enables IPv4-only
clients and peers to initiate connections to IPv6-only servers or
peers equipped with Mapped IPv4 Addresses, as described in <xref
target="cloud"></xref>. It also enables scalable coordination of
IPv4-only stubs of larger enterprise or ISP IPv6-only networks as
described in <xref target="case2"></xref>.</t>
<t>In addition, since <xref target="RFC3484"></xref>address
selection would select a Mapped IPv4 Address when it is available,
stateless translation enables IPv6 clients and peers with Mapped
IPv4 Addresses to open connections with IPv4 servers and peers in a
scalable fashion, supporting aysnchronous routes.</t>
</section>
<section anchor="stateful"
title="Stateful translation - unmapped IPv6 address">
<t><xref target="XLAT"></xref> also describes and defines the
behavior of the data plane component of a stateful translator. <xref
target="I-D.bagnulo-behave-nat64"></xref> describes the management
of the state tables necessitated by stateful translation. Like
stateful translation, this is an optional facility; one could
implement or deploy only the stateful mode described in <xref
target="stateless"></xref>. Stateful translation is defined to
enable IPv6 clients and peers without Mapped IPv4 Addresses to
connect to IPv4-only servers and peers.</t>
<t>Stateful translation could be defined to enable IPv4 clients and
peers to connect to IPv6-only servers and peers without Mapped IPv4
Addresses. This is far more complex, however, and is out of scope in
the present work.</t>
</section>
<section anchor="other" title="Translation gateway technologies">
<t>In addition, some applications require special support. An
example is FTP. FTP's active mode doesn't work well across NATs
without extra support such as SOCKS. Across NATs, it generally uses
passive mode. However, the designers of FTP inexplicably wrote
different and incompatible passive mode implementations for IPv4 and
IPv6 networks. Hence, either they need to fix FTP, or a translator
must be written for the application.</t>
<t>Other applications may be similarly broken.</t>
</section>
</section>
<section anchor="ops" title="Translation in operation">
<t></t>
</section>
<section title="Unsolved problems">
<t>Just say "multicast"; this framework could support multicast, but
at this point does not. This is a place for future work.</t>
<t>As noted, IPv4 client/peer access to IPv6 servers and peers lacking
Mapped IPv4 Addresses is not solved.</t>
<t>Interoperation between IPv4-only clients and IPv6-only clients is
not supported, and is not believed to be needed.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo requires no parameter assignment by the IANA.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author's perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor's discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>One "security" issue has been raised, with an address format that was
considered and rejected for that reason. At this point, the editor knows
of no other security issues raised by the address format that are not
already applicable to the addressing architecture in general.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This is under development by a large group of people. Those who have
posted to the list during the discussion include Andrew Sullivan, Andrew
Yourtchenko, Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker,
Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Kevin Yin, Magnus
Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo,
Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, and
Xing Li.</t>
<t>The appendix is largely derived from Hiroshi Miyata's analysis, which
is in turn based on documents by many of those just named.</t>
<t>Ed Jankiewicz described the transition plan.</t>
<t>The definition of a "Local Internet Registry" came from the
Wikipedia, and was slightly expanded to cover the present case.
(EDITOR'S QUESTION: Would it be better to describe this as an
"operator-defined prefix"?)</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.4291'?>
<reference anchor="DNS">
<front>
<title>Domain Name System Translator -
draft-bagnulo-behave-dns64</title>
<author fullname="Marcelo Bagnulo Braun" initials="M" role="editor"
surname="Bagnulo">
<organization>University of Madrid</organization>
</author>
<date month="October" year="2008" />
</front>
</reference>
<reference anchor="XLAT">
<front>
<title>IP/ICMP Translation Algorithm -
draft-baker-behave-v4v6-translation</title>
<author fullname="Xing Li" initials="X." role="editor" surname="Li">
<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 62785983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<author fullname="Congxiao Bao" initials="C." role="editor"
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 62785983</phone>
<email>congxiao@cernet.edu.cn</email>
</address>
</author>
<author fullname="Fred Baker" initials="F." role="editor"
surname="Baker">
<organization>Cisco Systems</organization>
</author>
<date month="October" year="2008" />
</front>
</reference>
<?rfc include='reference.I-D.bagnulo-behave-nat64' ?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.baker-behave-ivi'?>
<?rfc include='reference.I-D.ietf-v6ops-addcon' ?>
<?rfc include='reference.I-D.miyata-v6ops-snatpt' ?>
<?rfc include='reference.I-D.xli-behave-ivi' ?>
<?rfc include='reference.RFC.1918' ?>
<?rfc include='reference.RFC.2765'?>
<?rfc include='reference.RFC.2766' ?>
<?rfc include='reference.RFC.3142' ?>
<?rfc include='reference.RFC.3484' ?>
<?rfc include='reference.RFC.3879'?>
<?rfc include='reference.RFC.4192' ?>
<?rfc include='reference.RFC.4193' ?>
<?rfc include='reference.RFC.4213' ?>
<?rfc include='reference.RFC.4862' ?>
<?rfc include='reference.RFC.4941' ?>
<?rfc include='reference.RFC.4864' ?>
<?rfc include='reference.RFC.3056' ?>
<?rfc include='reference.RFC.4380' ?>
<?rfc include='reference.RFC.5211' ?>
<?rfc include='reference.RFC.5214' ?>
<?rfc include='reference.RFC.4966' ?>
<?rfc include='reference.I-D.durand-softwire-dual-stack-lite' ?>
</references>
<section anchor="addresses" title="Address proposals">
<t>This appendix summarizes and analyzes the several proposals that have
been made for a mapped IPv4 address. These prefixes fall into two broad
categories: those that embed the IPv4 address into a well-known prefix,
and those that embed it into a prefix defined by the network operator.
<xref target="RFC4291"></xref> and <xref target="RFC2765"></xref> define
different well-known prefixes, and <xref
target="I-D.bagnulo-behave-nat64"></xref> and <xref
target="I-D.baker-behave-ivi"></xref> define different forms of
operator-defined prefixes.</t>
<section anchor="wellknown" title="Well-known address formats">
<t><xref target="RFC2765"></xref> and <xref target="RFC4291"></xref>
define two slightly different formats of address that map between IPv4
and IPv6. In both cases, there is a defined 96 bit prefix, and the
IPv4 address is inserted into bits 96..127 of the IPv6 address.</t>
<t><xref target="RFC2765"></xref>'s address formats are as follows:
<list style="hanging">
<t hangText="IPv4-mapped:">An address of the form 0::ffff:a.b.c.d
which refers to a node that is not IPv6-capable. In addition to
its use in the API this protocol uses IPv4-mapped addresses in
IPv6 packets to refer to an IPv4 node.</t>
<t hangText="IPv4-compatible:">An address of the form 0::0:a.b.c.d
which refers to an IPv6/IPv4 node that supports automatic
tunneling. Such addresses are not used in this protocol.</t>
<t hangText="IPv4-translated:">An address of the form
0::ffff:0:a.b.c.d which refers to an IPv6-enabled node. Note that
the prefix 0::ffff:0:0:0/96 is chosen to checksum to zero to avoid
any changes to the transport protocol's pseudo header
checksum.</t>
</list></t>
<figure anchor="address4291"
title="RFC 4291 Deprecated IPv4-mapped address formats">
<artwork align="center"><![CDATA[
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+
IPv4-Compatible IPv6 address
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
IPv4-mapped IPv6 address
]]></artwork>
</figure>
<section anchor="wellknownBenefit"
title="Benefits of a well-known address">
<t><list style="hanging">
<t hangText="Address Mapping:">The Well-Known Prefix allows
automatic IPv6 address mapping to IPv4. One Well-Known Prefix
can represent entire IPv4 network address.</t>
<t hangText="Address Selection:">It is straightforward to ensure
that an application prefers native addressing to mapped
addressing in selecting an address for its peer or server, as
the <xref target="RFC3484"></xref> tables can come configured
that way from the manufacturer. <vspace blankLines="1" /> It
will choose its source address by <xref target="RFC3484"></xref>
rules, which prefer the most similar prefix first. Hence, a
system with a mapped address communicating through a translator
will prefer its own mapped address as a source.</t>
<t hangText="Synthetic Address Detection:">If the application
wants to know whether the address has been synthesized, this is
straightforward.</t>
</list></t>
</section>
<section anchor="wellknownIssues"
title="Issues in using a well-known address">
<t><list style="hanging">
<t hangText="Routing">In interdomain routing, there can be
problems similar to those considered in <xref
target="RFC3879"></xref>. For example, consider two routing
administrations that interconnect using IPv6 and each offer
independent <xref target="RFC1918"></xref> IPv4 domains. If an
IPv4 client of one administration accesses an IPv6 server in the
other network, the replies will be routed to the other network's
<xref target="RFC1918"></xref> domain.</t>
<t hangText="Scability of discontiguous IPv4 domains:">Using a
standard prefix for all IPv4 space means that all IPv4 access is
through that system or through the topologically nearest
instance of them. If the IPv4 address space is fragmented, and
especially if it is duplicated as is done with <xref
target="RFC1918"></xref> space, it is impossible to distinguish
the access points in the IPv6 network.</t>
<t hangText="Control:">Even in intradomain routing, control
issues can arise in routing if there is more than one
translator.</t>
</list></t>
</section>
<section anchor="wellknownConfiguration"
title="Configuration of a well-known address">
<t><list style="hanging">
<t hangText="Host:">To use DNS re-writing function, the IPv6
node should be configured to send DNS query to appropriate DNS
server somehow. But it is same as ordinary DNS configuration.
Therefore, no special configuration is required for both IPv6
and IPv4 hosts.</t>
<t hangText="Router:">No special configuration is required of
routers.</t>
<t hangText="Gateway:">Each gateway needs to know the Well-Known
Prefix, whether that means configuration of the prefix or simply
configuration of the translation function. The Gateway must also
be configured to advertise the Well-Known Prefix in the IPv6
network and the relevant prefix(es) in the IPv4 network. This
must be performed once for each gateway. If the addresses are
mapped in statically, each mapping must be configured in the
appropriate gateway. This configuration must be performed
[number of mapped prefixes] * [number of sharing gateway]
times.</t>
<t hangText="DNS">The DNS re-writing function must be configured
with the Well-Known Prefix to synthesize AAAA records from A
records for IPv6 clients, but it may be configured by default.
This configuration must be performed [number of Local Prefix]
times.</t>
</list></t>
</section>
<section anchor="wellknownApplicability"
title="Applicability of a well-known address">
<t><list style="symbols">
<t>Small scale translation (Home Network).</t>
<t>Less redundant translation service (no load balancing).</t>
<t>Stub IPv6 network.</t>
</list></t>
<t>Sample configurations include:<list style="empty">
<t>To provide the access from IPv6 client in stub IPv6 network
to global IPv4 server, place the gateway at the edge of IPv6
stub site.</t>
</list></t>
<figure anchor="stub6_global4"
title="IPv6 to global IPv4 (Client Side Gateway)">
<artwork align="center"><![CDATA[
(IPv6 stub network) (IPv4 global network)
[IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server]
|
+------------[IPv4 Server]]]
]]></artwork>
</figure>
<t><list style="empty">
<t>To provide the access from IPv6 client in stub IPv6 network
to private/global IPv4 server (IPv6 stub network attached to a
private IPv4 network), place the gateway at the edge of IPv6
stub network.</t>
</list></t>
<figure anchor="stub6_private4"
title="IPv6 to global IPv4 (Client Side Gateway)">
<artwork align="center"><![CDATA[
(IPv6 stub network) (IPv4 private network)
[IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server]
|
[NAT]
|
+------------[IPv4 Server]
]]></artwork>
</figure>
</section>
</section>
<section anchor="operator" title="Network operator specified prefixes">
<t>Two forms of network operator specified addresses have been
proposed, one of them in several minor variations. In short, both have
the network operator specify a prefix into which an IPv4 address is
embedded, either in bits 96..127 or following a shorter prefix.</t>
<t>Since one is a special case of the other (the LIR prefix is 96 bits
as opposed to being variable), it would be tempting to comment on the
two together. The operational similarities will be great, and the
differences will revolve around the economics of the prefix that the
IPv4 address is embedded into But to make them clear, we will review
them separately.</t>
<section anchor="ivi" title="The IVI prefix">
<t>The <xref target="I-D.xli-behave-ivi">IVI Address</xref> <xref
target="I-D.baker-behave-ivi"></xref>, shown in <xref
target="iviAddress"></xref>, has a variable length prefix specified
by the operator followed by the IPv4 address, and the remainder
filled with zero. Observing <xref target="RFC4291"></xref>'s
requirement that an operator-specified prefix should have 64 bits of
subnet locator and 64 bits of host interface identifier, IVI
suggests that the operator divide the mapped IPv4 prefix into a
subnet part and a host part, and assign a prefix from its allocation
that with the subnet part fills 64 bits.</t>
<figure anchor="iviAddress" title="IVI Address Format">
<artwork align="center"><![CDATA[
0 8 16 24 32 40 48 56 64 127
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LIR Prefix | IPv4 addr | entirely 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|<-----prefix part ---->|<--- host part --->|
]]></artwork>
</figure>
<t>The impact of the variability of the LIR Prefix has to do with
service offerings. If a network operator wishes to offer customers a
general IPv6 prefix such as a /48 plus a smaller IPv4-mapped set of
addresses for IPv4-accessible servers, such as an IPv4 /24, he might
literally design a service in which each customer gets a general /48
prefix and an IPv4-mapped /64 prefix. To accomplish this, the
operator would allocate a /40 for the LIR prefix and embed the IPv4
address space into it. His Advertised IPv4 Prefix would aggregate
the Mapped IPv4 Prefixes that he in turn assigns to his customers.
If, however, he wanted to assign smaller units, such as /28s to each
customer, he would allocate a shorter prefix such as a /36 as the
LIR Prefix.</t>
<t>There are clear trade-offs here; the point is to enable the
network operator to optimize them for the service he wants to
offer.</t>
<section anchor="iviBenefit"
title="Benefits of an operator-specified /32../64 prefix">
<t><list style="hanging">
<t hangText="Address Mapping:">A Mapped IPv4 Address format
allows a stateless IPv6 address mapping between an IPv4
address and its mapped IPv6 counterpart. One such prefix can
represent the entire IPv4 address space, and if desired
multiple prefixes can represent multiple instances of it or
accesses to it.</t>
<t hangText="Address Selection:"><xref
target="RFC3484"></xref> selection rules select the source
address most similar to the destination address in question,
which is to say matching the longest prefix. In general, one
would expect a system with an address of this type to prefer
IPv6 source addresses derived from IPv4 addresses when they
are available.</t>
<t hangText="Synthetic Address Detection:">If the <xref
target="RFC3484"></xref> tables in a host are configured with
the administration's translation prefix, a policy can be made
to prefer native IPv4 to translation, or to prefer any other
IPv6 address to a translated address.</t>
<t hangText="Managing Multiple Gateways:">The administration
has the option of using the same prefix on multiple gateways,
or of using different prefixes. Differing administrations will
almost assuredly use different prefixes. This enables the
administration to distinguish between distinct address spaces
such as separate instances of the <xref
target="RFC1918"></xref> address space. It also enables
multiple gateways to be used to interconnect between public
IPv4 and IPv6 networks without having to manage the state
maintained by such translation gateways.</t>
<t hangText="Scalability:">Due to the ability to support
multiple gateways between the same two domains statelessly and
the ability to identify multiple instances of the same IPv4
address space when appropriate, a network operator specified
prefix is scalable through normal routing structures.</t>
<t hangText="Flexibility">Since the prefix choice is under the
network's control, routing is managed relatively easily.</t>
<t hangText="TCP/UDP Checksums:">These prefixes were chosen to
make it unnecessary to adjust TCP/UDP checksums.</t>
</list></t>
</section>
<section anchor="iviIssues"
title="Issues in using an operator-specified /32../64 prefix">
<t><list style="hanging">
<t hangText="Synthetic Address Detection:">By default, hosts
are unlikely to come configured with the administration's
translation prefix in their <xref target="RFC3484"></xref>
tables, and so are unlikely to be able to distinguish such
addresses from other IPv6 addresses.</t>
<t hangText="Private address spaces">Multiple small (and
perhaps overlapping) address spaces are readily supported in
what might be called a network model. However, these consume
much larger blocks of IPv6 address space than the appliance
model of a Local Prefix (<xref target="localPrefix"></xref>)
does.</t>
<t hangText="IPv4 Address Efficiency:">As noted above, IVI is
less efficient than the NAT64 model in enumerating small IPv4
islands, and having a prefix per network operator is less
efficient on a global basis than having a single well-known
prefix.</t>
<t hangText="Routing:">If one uses both stateless and stateful
translation in the same network, assigning a normal IPv6
prefix to all systems and additionally mapped addresses to
servers, then one needs two routes, one for each prefix.
Reducing this burden requires either the total use of stateful
translation, disabling IPv4 clients access to IPv6 servers, or
total use of stateless translation, meaning that one
effectively assigns an IPv4 address to every host.</t>
<t hangText="Service model:">One would generally expect an IVI
address to be used in an ISP service, as it requires a 40 bit
prefix assigned by the operator in most cases. It could be
used with a <xref target="RFC4193">ULA</xref> in an edge
network at the cost of losing global routability.</t>
<t hangText="TCP/UDP checksums">Using an operator-specified
prefix requires the translator to adjust TCP and UDP
checksums.</t>
</list></t>
</section>
<section anchor="iviConfiguration"
title="Configuration of an operator-specified /32../64 prefix">
<t><list style="hanging">
<t hangText="Host assignment:">In general, one would expect a
mapped IPv4 address to be assigned in the same way that IPv4
addresses are assigned; this would call for the use of DHCPv6
or manual configuration.</t>
<t hangText="Router:">If one or more hosts on a LAN are
assigned mapped IPv4 addresses, one or more routers on the LAN
needs configuration of the corresponding Mapped IPv4 Prefix,
and to have that advertised as a route in the IPv6 domain.</t>
<t hangText="Gateway:">The gateway needs to advertise three
prefixes: <list style="symbols">
<t>The Advertised IPv4 Prefix is advertised into the IPv4
domain to attract traffic that needs translation to
IPv6.</t>
<t>The Overlay IPv4 Prefix, if stateful translation is in
use, is advertised into the IPv4 domain to attract traffic
using that translation facility.</t>
<t>The LIR Prefix is advertised into the IPv6 domain to
attract traffic that needs translation to IPv4.</t>
</list></t>
<t hangText="DNS:">The DNS re-writing function must be
configured with the LIR Prefix to synthesize the AAAA records
for IPv6 nodes when appropriate. <vspace blankLines="1" /> The
DNS server needs to be configured with the information to
develop A records when appropriate. This may be accomplished
using Dynamic DNS or manual configuration. This may mean
configuration of IPv4 A records that get translated to AAAA
records, or configuration of IPv6 AAAA records that are
recognized by the DNS server.</t>
</list></t>
</section>
<section anchor="iviApplicability"
title="Applicability of an operator-specified /32../64 prefix">
<t><list style="symbols">
<t>The IVI address is appropriate to large scale, ISP grade,
translation, while the NAT64 address is more flexible.</t>
<t>Highly redundant translation service.</t>
<t>Places where IPv4 clients need to access IPv6 servers.</t>
<t>Places where IPv6 clients and peers need to access IPv4
servers and peers.</t>
</list></t>
</section>
</section>
<section anchor="localPrefix"
title="Network operator specified /96 prefixes">
<t><xref target="I-D.bagnulo-behave-nat64">NAT64</xref> and <xref
target="I-D.miyata-v6ops-snatpt">SNATPT</xref> each specify an
address that, like the well-known addresses of <xref
target="wellknown"></xref> and the "Dummy Address" of <xref
target="RFC2766"></xref> and <xref target="RFC3142"></xref>, has 96
bits of operator-specified prefix and the IPv4 address in bits
96..127. This is shown in <xref target="localAddress"></xref>. In
some proposals, the "IDENT" field is always zero, and in others it
enumerates different instances of the IPv4 address space.</t>
<figure anchor="localAddress" title="NAT64 Address Format">
<artwork align="center"><![CDATA[
1 1
1 2 6 7 9 2
0123456789012345678901234...01234567890...01234567890...012345678
+------------------------//-----+------//-------+----//---------+
| IPv6 Prefix | IDENT | IPv4 Address |
| 64 bit | 32 bit | 32 bit |
+------------------------//-----+------//-------+----//---------+
| | |
|<-----------PREFIX64---------->|<-identifier-->|
]]></artwork>
</figure>
<t>A similar address format, with an "IDENT" based on the IANA OUI,
is used by <xref target="RFC5214">ISATAP</xref>; if a
globally-unique "IDENT" field is selected, it needs to differ from
that value.</t>
<section anchor="localBenefit"
title="Benefits of an operator-specified /96 prefix">
<t><list style="hanging">
<t hangText="Address Mapping:">A Mapped IPv4 Address format
allows a stateless IPv6 address mapping between an IPv4
address and its mapped IPv6 counterpart. One such prefix can
represent the entire IPv4 address space, and if desired
multiple prefixes can represent multiple instances of it or
accesses to it.</t>
<t hangText="Address Selection:"><xref
target="RFC3484"></xref> selection rules select the source
address most similar to the destination address in question,
which is to say matching the longest prefix. In general, one
would expect a system with an address of this type to prefer
IPv6 source addresses derived from IPv4 addresses when they
are available.</t>
<t hangText="Synthetic Address Detection:">If the <xref
target="RFC3484"></xref> tables in a host are configured with
the administration's translation prefix, a policy can be made
to prefer native IPv4 to translation, or to prefer any other
IPv6 address to a translated address.</t>
<t hangText="Private address spaces">Multiple small (and
perhaps overlapping) address spaces are readily supported in
what might be called an appliance model; for example, if SOHOs
are using IPv4 internally, the IPv6 ISP can give a /64 to each
and manage them easily.</t>
<t hangText="Managing Multiple Gateways:">The administration
has the option of using the same prefix on multiple gateways,
or of using different prefixes. This approach enables multiple
gateways to be used to interconnect between IPv4 and IPv6
networks without having to manage the state maintained by such
translation gateways.</t>
<t hangText="Scalability:">Due to the ability to support
multiple gateways between the same two domains statelessly and
the ability to identify multiple instances of the same IPv4
address space when appropriate, a network operator specified
prefix is scalable through normal routing structures.</t>
<t hangText="Flexibility">Since the prefix choice is under the
network's control, routing is managed relatively easily.</t>
</list></t>
</section>
<section anchor="localIssues"
title="Issues in using an operator-specified /96 prefix">
<t><list style="hanging">
<t hangText="Synthetic Address Detection:">By default, hosts
are unlikely to come configured with the administration's
translation prefix in their <xref target="RFC3484"></xref>
tables, and so are unlikely to be able to distinguish such
addresses from other IPv6 addresses.</t>
<t hangText="Routing:">If one uses both stateless and stateful
translation in the same network, assigning a normal IPv6
prefix to all systems and additionally mapped addresses to
servers, then one needs two routes, one for each prefix.
Reducing this burden requires either the total use of stateful
translation, disabling IPv4 clients access to IPv6 servers, or
total use of stateless translation, meaning that one
effectively assigns an IPv4 address to every host.</t>
<t hangText="Service model:">One would generally expect an IVI
address to be used in an ISP service, as it requires a 40 bit
prefix assigned by the operator in most cases. It could be
used with a <xref target="RFC4193">ULA</xref> in an edge
network at the cost of losing global routability. The NAT64
address, on the other hand, has no such issue.</t>
<t hangText="Synthetic Address Detection:">It is difficult to
identify a mapped IPv4 address without knowledge that the
mapping algorithm is used with a specific prefix.</t>
<t hangText="Address Configuration:">Since IPv4 addresses are
allocated by DHCP servers or manually, it is inappropriate to
mix Local Prefix IPv4-mapped addresses with <xref
target="RFC4862">Address Autoconfiguration</xref> <xref
target="RFC4941"></xref> in the same prefix. This may not be
obvious to a provider that thinks of itself as simply
assigning a /64 IPv6 prefix to the SOHO (regarding which see
<xref target="I-D.ietf-v6ops-addcon"></xref>).</t>
<t hangText="Routing">Routing is readily handled in the IPv4
network. However, if routing of IPv4-mapped prefixes is
desired in the IPv6 network, we are forced to use prefixes in
the neighborhood of /96../128. Apart from routing host
addresses, <xref target="RFC4291"></xref> frowns on this,
preferring routing prefixes to be 64 bits or shorter and
leaving a 64 bit host ID.</t>
<t hangText="TCP/UDP Checksums:">Using an operator-specified
prefix requires the translator to adjust TCP and UDP
checksums.</t>
</list></t>
</section>
<section anchor="localConfiguration"
title="Configuration of an operator-specified /96 prefix">
<t><list style="hanging">
<t hangText="Host assignment:">In general, one would expect a
mapped IPv4 address to be assigned in the same way that IPv4
addresses are assigned; this would call for the use of DHCPv6
or manual configuration.</t>
<t hangText="Router:">If one or more hosts on a LAN are
assigned mapped IPv4 addresses, one or more routers on the LAN
needs configuration of the corresponding Mapped IPv4 Prefix,
and to have that advertised as a route in the IPv6 domain.</t>
<t hangText="Gateway:">The gateway needs to advertise two
prefixes: <list style="symbols">
<t>The Advertised IPv4 Prefix is advertised into the IPv4
domain to attract traffic that needs translation to
IPv6.</t>
<t>The LIR Prefix is advertised into the IPv6 domain to
attract traffic that needs translation to IPv4.</t>
</list></t>
<t hangText="DNS:">The DNS re-writing function must be
configured with the LIR Prefix to synthesize the AAAA records
for IPv6 nodes when appropriate. <vspace blankLines="1" /> The
DNS server needs to be configured with the information to
develop A records when appropriate. This may be accomplished
using Dynamic DNS or manual configuration. This may mean
configuration of IPv4 A records that get translated to AAAA
records, or configuration of IPv6 AAAA records that are
recognized by the DNS server.</t>
</list></t>
</section>
<section anchor="localApplicability"
title="Applicability of an operator-specified /96 prefix">
<t><list style="symbols">
<t>Local Prefixes are appropriate to small networks that have
little internal IPv6 structure, such as server pools or SOHO
clients. The structure in the IPv4 network is as with any IPv4
network, making this appropriate to medium sized IPv4
domains.</t>
<t>Highly redundant translation service.</t>
<t>Places where IPv4 clients need to access IPv6 servers.</t>
<t>Places where IPv6 clients and peers need to access IPv4
servers and peers.</t>
</list></t>
<t>Sample configurations include:</t>
<t><list style="empty">
<t>Place the gateway at the edge of IPv6 stub site.</t>
</list></t>
<figure anchor="client_side_gateway"
title="IPv6 to global IPv4 (Client Side Gateway)">
<artwork align="center"><![CDATA[
(IPv6 stub network) (IPv4 global network)
[IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server]
|
+------------[IPv4 Server]
]]></artwork>
</figure>
<t><list style="empty">
<t>Place the gateway in front of IPv4 server.</t>
</list></t>
<figure anchor="server_side_gateway"
title="IPv6 to global IPv4 (Server Side Gateway)">
<artwork align="center"><![CDATA[
(IPv6 global network) (IPv4 global network)
[IPv6 Client]---------+------>------[Gateway]---->---[IPv4 Server]
|
[IPv6 Client]---------+
]]></artwork>
</figure>
<t><list style="empty">
<t>to provide the access from IPv6 client to private IPv4
server, place the gateway in front of IPv4 private
network.</t>
</list></t>
<figure anchor="private_ipv4"
title="IPv6 to private IPv4 (Server Side Gateway)">
<artwork align="center"><![CDATA[
(IPv6 global network) (IPv4 private network)
[IPv6 Client]---------+------>------[Gateway]---->---[IPv4 Server]
|
[IPv6 Client]---------+
]]></artwork>
</figure>
<t><list style="empty">
<t>To provide the access from IPv4 client to IPv6 server by
static 1:1 mapping, place the gateway at the edge of IPv4 stub
site.</t>
</list></t>
<figure anchor="ipv4_to_ipv6"
title="Private IPv4 to IPv6 (Client Side Gateway)">
<artwork align="center"><![CDATA[
(IPv6 global network) (IPv4 private network)
[IPv6 Server]---------+------<------[Gateway]---<----[IPv4 Client]
|
[IPv6 Server]---------+
]]></artwork>
</figure>
</section>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:34:51 |