One document matched: draft-ietf-behave-v6v4-framework-10.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 toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="info" docName="draft-ietf-behave-v6v4-framework-10"
ipr='trust200811'>
<front>
<title>Framework for IPv4/IPv6 Translation</title>
<author fullname="Fred Baker" initials="F.J." role=""
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>
<author fullname="Xing Li" initials="X." role="" 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 10-62785983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<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="Kevin Yin" initials="K.Y." role="" surname="Yin">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>No. 2 Jianguomenwai Ave, Chaoyang District </street>
<city>Beijing</city>
<code>100022</code>
<region></region>
<country>China</country>
</postal>
<phone>+86-10-8515-5094</phone>
<email>kyin@cisco.com</email>
</address>
</author>
<date year="2010" />
<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>
</front>
<middle>
<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 (Network Address Translation - Protocol Translation)</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>NAT-PT was deprecated 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.
It wasn't intended to say that IPv4<->IPv6 translation was bad,
but the way that NAT-PT did it was bad, and in particular using
NAT-PT as a general-purpose solution was bad.
As with the deprecation of the RIP routing protocol
<xref target="RFC1923"></xref>
at the time the Internet was converting to CIDR, the point was to encourage
network operators to actually move away from technology with known issues.</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 businesses, 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 document 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
<xref target="6NET"></xref>
we did - build an overlay
network
that tunnels one protocol over the other.
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.ietf-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>
Users of the new architecture
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 without dual-stack hosts.</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 for example 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="An IPv4 network:">A specific network that has an IPv4-only deployment.
This could be an enterprise's IPv4-only network, an ISP's IPv4-only network or even an IPv4-only host.
The IPv4 Internet is the set of all interconnected IPv4 networks. </t>
<t hangText="An IPv6 network:"> A specific network that has an IPv6-only deployment.
This could be an enterprise's IPv6-only network, an ISP's IPv6-only network or even an IPv6-only host.
The IPv6 Internet is the set of all interconnected IPv6 networks.
</t>
<t hangText="DNS46:">A DNS translator that translates AAAA record to A record.
</t>
<t hangText="DNS64:">A DNS translator that translates A record to AAAA record.
</t>
<t hangText="Dual-Stack implementation:">A Dual-Stack
implementation, in this context, comprises an IPv4/IPv6 enabled end system
stack, applications 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-converted addresses:">
IPv6 addresses used to represent IPv4 nodes in an IPv6 network.
They have an explicit mapping relationship to IPv4 addresses.
Both stateless and stateful translators use IPv4-converted addresses
to represent IPv4 addresses.
</t>
<t hangText="IPv4-only:">An IPv4-only implementation, in this
context, comprises an IPv4-enabled end system stack, applications
directly or indirectly using that IPv4 stack, plus routing in the
network. It implies that two application instances are capable of
communicating using 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 with IPv6 hosts.</t>
<t hangText="IPv4-translatable addresses:">
IPv6 addresses to be assigned to IPv6 nodes for use with stateless translation.
They have an explicit mapping relationship to IPv4 addresses.
A stateless translator uses the corresponding IPv4 addresses to
represent the IPv6 addresses. A stateful translator does not use
this kind of addresses, since IPv6 hosts are represented by the
IPv4 address pool in the translator via dynamic state.
</t>
<t hangText="IPv6-only:">An IPv6-only implementation, in this
context, comprises an IPv6-enabled end system stack, applications
directly or indirectly using that IPv6 stack, plus routing in the
network. It implies that two application instances are capable of
communicating using 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 with IPv4 hosts.</t>
<t hangText="Network-Specific Prefix (NSP):">
From an IPv6 prefix assigned to a network
operator, the operator chooses a longer prefix for use by the
operator's translator(s). Hence a given IPv4 address would have
different IPv6 representations in different networks that use
different network-specific prefixes. A network-specific prefix is also known as a
Local Internet Registry (LIR) prefix.
</t>
<t hangText="State:">"State" refers to dynamic information that is
stored in a network element. For example, if two systems are
communicating using a TCP connection, each stores information about the
connection, which is called "connection state". In this context,
the term refers to dynamic correlations between IP addresses on
either side of a translator, or {IP address, transport protocol,
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="Stateful Translator:">
A translator that uses stateful translation
for either the source or destination
address. A stateful translator typically
also uses a stateless translation algorithm for the other type of
address.
</t>
<t hangText="Stateless Translation:">A translation algorithm that
is not "stateful" is "stateless". It derives its needed information
algorithmically from the messages it is translating, and pre-configured information.</t>
<t hangText="Stateless Translator:">
A translator that uses only stateless
translation for both destination address and source
address.
</t>
<t hangText="Well-Known Prefix (WKP):">
The IPv6 prefix defined in
<xref target="I-D.ietf-behave-address-format"></xref>
for use in an algorithmic mapping.
</t>
</list></t>
<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"></xref>.</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 for NAT-PT, and the things it
necessitated led to scaling and operational difficulties
<xref target="RFC4966"></xref>.
</t>
<t>So the question comes back to what different kinds of connectivity
can be easily supported and what kinds are harder, and what technologies are
needed to at least pick the low-hanging fruit. We observe that
applications today fall into two 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 resolution.</t>
<t hangText="Peer-to-Peer (P2P) Application:"> A P2P application is an
application that uses the same endpoint to initiate outgoing sessions to
peering hosts as well as accept incoming sessions from peering hosts.
These in turn fall broadly into two categories:<list style="hanging">
<t
hangText="Peer-to-peer infrastructure 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 peers that they find reliable and
available.</t>
</list></t>
</list></t>
<t>If the goal is 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.</t>
<t>In some situations, hosts are purely clients.
In those situations, we do not need an algorithm to enable connections to those hosts.</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. The objective of the translators is to avoid, as much as possible,
any software changes in hosts or applications necessary to support translation.
</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>
</section>
<section anchor="plan" title="Transition Plan">
<t>While the design of IPv4 made it impossible for IPv6 to be
compatible on the wire, 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
<xref target="RFC4213"></xref>, 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>Various timelines have been discussed, but most will agree
with the pattern of the above three transition phases, also known as
an "S" curve transition pattern.</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. This is known as the early stage of the "S" curve. </t>
<t hangText="Transition Phase:">
During the middle stage of "S" curve,
while IPv6 adoption can be
expected to accelerate, there will still be a significant portion
of the Internet operating 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:"> This is the last stage of "S" curve. 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 one is going somewhere, while "coexistence" seems more like one is
sitting somewhere. Historically with the 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 IPv6 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>
<section anchor="scenarios" title="Scenarios for IPv4/IPv6 Translation">
<t>
It is important to note that the choice of translation solution and the assumptions
about the network where they are used impact the consequences. A translator for the
general case has a number of issues that a translator for a more specific situation
may not have at all.
</t>
<t>
The intention of this document is to focus on
translation solutions
under all kinds of situations.
All IPv4/IPv6 translation cases can be easily described in terms of
"interoperation between a set of systems (applications) that only communicate using IPv4
and a set of systems that only communicate using IPv6", but the differences
at a detailed level make them interesting.
</t>
<t>
Based on the transition plan described in <xref target="plan"></xref>, there are
four types of IPv4/IPv6 translation scenarios:
</t>
<t>a. Interoperation between an IPv6 network and the IPv4 Internet </t>
<t>b. Interoperation between an IPv4 network and the IPv6 Internet </t>
<t>c. Interoperation between an IPv6 network and an IPv4 network </t>
<t>d. Interoperation between the IPv6 Internet and the IPv4 Internet </t>
<t>
Each one of the above can be divided into two scenarios, depending on whether the
IPv6 side or the IPv4 side initiates communication, so there are a total of
eight scenarios.
</t>
<t> Scenario 1: an IPv6 network to the IPv4 Internet </t>
<t> Scenario 2: the IPv4 Internet to an IPv6 network </t>
<t> Scenario 3: the IPv6 Internet to an IPv4 network </t>
<t> Scenario 4: an IPv4 network to the IPv6 Internet </t>
<t> Scenario 5: an IPv6 network to an IPv4 network </t>
<t> Scenario 6: an IPv4 network to an IPv6 network </t>
<t> Scenario 7: the IPv6 Internet to the IPv4 Internet</t>
<t> Scenario 8: the IPv4 Internet to the IPv6 Internet</t>
<t>
We will discuss each scenario in detail in the next section.
</t>
<section anchor="scenario1" title="Scenario 1: an IPv6 network to the IPv4 Internet">
<t>
Due to the lack of IPv4 addresses or under other technical or economical
constraints, the network is IPv6-only, but the hosts in the network require
communicating with the global IPv4 Internet.
</t>
<t>
This is the typical scenario for what we sometimes call "green-field" deployments.
One example is an enterprise network that wishes to operate only IPv6 for operational
simplicity, but still wishes to reach the content in the IPv4 Internet. The green-field
enterprise scenario is different from an ISP's network in the sense that there is only one place that the
enterprise can easily modify: the border between its network and the IPv4 Internet.
Obviously, the IPv4 Internet operates
the way it already does. But in addition, the hosts in the enterprise network are
commercially available devices, personal computers with existing operating systems.
This restriction drives us to a "one box" type of solution, where IPv6 can be
translated into IPv4 to reach the public Internet.
</t>
<t>
Other cases that have been mentioned include wireless ISP networks and sensor networks.
These bear a striking resemblance to this scenario as well, if one considers the
ISP network to simply be a very special kind of enterprise network.
</t>
<figure anchor="fig_scenario1_10"
title="Scenario 1">
<artwork align="center">
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
</artwork>
</figure>
<t>
Both stateless
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>
and stateful
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>
solutions can support Scenario 1.
</t>
</section>
<section anchor="scenario2" title="Scenario 2: the IPv4 Internet to an IPv6 network">
<t>
When the enterprise networks or ISP networks adopt Scenario 1,
the IPv6-only users will not only want to access servers on the IPv4 Internet
but also want to setup their own servers in the network which are accessible by the users on the IPv4 Internet,
since the majority of the
Internet users are still in the IPv4 Internet.
Thus, with a translation solution for this scenario, the benefits
would be clear. Not only could servers move directly to IPv6 without trudging
through a difficult transition period,
but they could do so without risk of losing connectivity with the IPv4-only Internet.
</t>
<figure anchor="fig_scenario2"
title="Scenario 2">
<artwork align="center">
--------
// \\ ----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \\ //
\\ // ----------
--------
====>
</artwork>
</figure>
<t>
In general, this scenario presents a hard case for translation.
Stateful translation such as NAT-PT <xref target="RFC2766"></xref> can be used
in this scenario, but it requires a tightly coupled DNS ALG in the translator and
this technique was deprecated by the IETF <xref target="RFC4966"></xref>.
</t>
<t>
The stateless translation solution
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>
in Scenario 1 can also work in Scenario 2, since it can support
IPv4-initiated communications with a subset of the IPv6 addresses (IPv4-translatable addresses) in an IPv6 network.
</t>
</section>
<section anchor="scenario3" title="Scenario 3: the IPv6 Internet to an IPv4 network">
<t>
There is a requirement for a legacy IPv4 network to provide services to IPv6
hosts.
</t>
<figure anchor="fig_scenario3"
title="Scenario 3">
<artwork align="center">
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
</artwork>
</figure>
<t>
Stateless translation
will not work for this scenario,
because an IPv4 network needs to communicate with all of the IPv6 Internet,
not just a small subset, and stateless can only support a subset of the IPv6 addresses.
However, IPv6-initiated communication can be achieved through stateful
translation
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>.
In this case, a Network Specific Prefix assigned to the translator will
give the hosts unique IPv4-converted IPv6 addresses, no matter the
legacy IPv4 network uses public IPv4 addresses or
<xref target="RFC1918"></xref>
addresses. Also there is no need to synthesizing AAAA from A records,
since static AAAA records can be put in the
regular DNS to represent these IPv4-only hosts as discussed
in Section 7.3 of
<xref target="I-D.ietf-behave-dns64"></xref>.
</t>
</section>
<section anchor="scenario4" title="Scenario 4: an IPv4 network to the IPv6 Internet">
<t>
Due to technical or economical constraints, the network is IPv4-only,
and IPv4-only hosts (applications) may require communicating with the global IPv6 Internet.
</t>
<figure anchor="fig_scenario_4"
title="Scenario 4">
<artwork align="center">
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 | XLAT: IPv4/IPv6
| Network +----+ Internet | Translator
| |DNS | | DNS: DNS46
\ +----+ /
\\ // \ /
--------- \\ //
----------
=====>
</artwork>
</figure>
<t>
In general, this scenario presents a hard case for translation.
Stateful translation such as NAT-PT <xref target="RFC2766"></xref> can be used
in this scenario, but it requires a tightly coupled DNS ALG in the translator and
this technique was deprecated by the IETF <xref target="RFC4966"></xref>.
</t>
<t>
From the transition phase discussion in <xref target="plan"></xref>,
this scenario will probably only occur when we are well past the early stage of the "S" curve and
the IPv4/IPv6 transition has already moved to the right direction. Therefore, in-network translation
is not considered viable for this scenario and other techniques should be considered.
</t>
</section>
<section anchor="scenario5" title="Scenario 5: an IPv6 network to an IPv4 network">
<t>
In this scenario, both an IPv4 network and an IPv6 network are within
the same organization.
</t>
<t>
The IPv4 addresses used are either public IPv4 addresses or <xref target="RFC1918"></xref>
addresses. The IPv6 addresses used are either public IPv6 addresses or
<xref target="RFC4193">ULAs (Unique Local Addresses)</xref>.
</t>
<figure anchor="fig_scenario5"
title="Scenario 5">
<artwork align="center">
--------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
</artwork>
</figure>
<t>
The translation requirement from this scenario has no
significant difference from scenario 1, so both the stateful and stateless
translation schemes discussed in <xref target="scenario1"></xref> apply here.
</t>
</section>
<section anchor="scenario6" title="Scenario 6: an IPv4 network to an IPv6 network">
<t>
This is another scenario when both an IPv4 network and an IPv6 network are within
the same organization.
</t>
<t>
The IPv4 addresses used are either public IPv4 addresses or <xref target="RFC1918"></xref>
addresses. The IPv6 addresses used are either public IPv6 addresses or
<xref target="RFC4193">ULAs (Unique Local Addresses)</xref>.
</t>
<figure anchor="fig_scenario6"
title="Scenario 6">
<artwork align="center">
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\\ // \\ //
-------- ---------
====>
</artwork>
</figure>
<t>
The translation requirement from this scenario has no
significant difference from scenario 2, so the translation scheme
discussed in <xref target="scenario2"></xref> applies here.
</t>
</section>
<section anchor="scenario7" title="Scenario 7: the IPv6 Internet to the IPv4 Internet">
<t>
This seems the ideal case for in-network translation technology, where any IPv6-only host or application on the global Internet
can initiate communication with any IPv4-only host or application on the global Internet.
</t>
<figure anchor="fig_scenario7"
title="Scenario 7">
<artwork align="center">
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \ /
\\ // \\ //
-------- ---------
<====
</artwork>
</figure>
<t>Due
to the huge difference in size between the address spaces of the IPv4 Internet and the IPv6
Internet, there is no viable translation technique to handle unlimited IPv6 address
translation.
</t>
<t>
If we ever run into this scenario, fortunately, the IPv4/IPv6 transition has already
passed the early stage of the "S" curve. Therefore, there is no obvious
business reason to demand a translation solution as the only transition strategy.
</t>
</section>
<section anchor="scenario8" title="Scenario 8: the IPv4 Internet to the IPv6 Internet">
<t>
This case is very similar to Scenario 7. The analysis and conclusions for Scenario 7 also applies for this scenario.
</t>
<figure anchor="fig_scenario8"
title="Scenario 8">
<artwork align="center">
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \ /
\\ // \\ //
-------- ---------
====>
</artwork>
</figure>
</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 (<xref
target="glossary"></xref>), considered the requirements (<xref
target="requirements"></xref>), considered the transition model (<xref
target="plan"></xref>), and considered the kinds of scenarios the
facility would support (<xref target="scenarios"></xref>), we now turn to a
framework for IPv4/IPv6 translation. The framework contains the following components:
<list style="symbols">
<t>Address translation</t>
<t>IP and ICMP translation</t>
<t>Maintaining translation state</t>
<t>DNS64 and DNS46</t>
<t>ALGs for other application-layer protocols (e.g., FTP)</t>
</list></t>
<section anchor="components2" title="Translation Components">
<section anchor="address2" title="Address Translation">
<t>
When IPv6/IPv4 translation is performed, we should specify how an
individual IPv6 address is translated to a corresponding IPv4
address, and vice versa, in cases where an algorithmic mapping is used.
This includes the choice of IPv6 prefix and the choice of method
by which the remainder of the IPv6 address is derived from an IPv4 address
<xref target="I-D.ietf-behave-address-format"></xref>. The usages of the
IPv6 addresses are shown in the following figures.
</t>
<figure anchor="address-stateless"
title="IPv6 address representation for stateless translation">
<artwork align="center">
------------
H4 - (IPv4 network) - IPv4 address corresponding to H6's IPv4-
(IPv4 ------------ translatable address
address) \
--------------
|Stateless XLAT|
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (IPv4-
----------- translatable address)
</artwork>
</figure>
<figure anchor="address-stateful"
title="IPv6 address representation for stateful translation">
<artwork align="center">
------------
H4 - (IPv4 network) - IPv4 address in the translator's IPv4 pool
(IPv4 ------------
address) \
--------------
|Stateful XLAT |
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (any IPv6 address)
-----------
</artwork>
</figure>
<t>
For both stateless and stateful translation, an algorithmic mapping table is used to
translate IPv6 destination addresses (IPv4-converted addresses) to IPv4 destination addresses
in IPv6 to IPv4 direction and translate IPv4 source addresses
to IPv6 source addresses (IPv4-converted addresses) in IPv4 to IPv6 direction.
Note that translating IPv6 source addresses to IPv4 source addresses in IPv6 to IPv4 direction and
translating IPv4 destination addresses to IPv6 destination addresses in IPv4 to IPv6 direction
will be different for
stateless translation and stateful translation.
</t>
<t>
<list style="symbols">
<t>
For stateless translation, the same algorithmic mapping table is used
to translate IPv6 source addresses (IPv4-translatable addresses) to IPv4 source
addresses in IPv6 to IPv4 direction and
translate IPv4 destination addresses
to IPv6 destination addresses (IPv4-translatable addresses) in IPv4 to IPv6 direction.
In this case, blocks of service provider's IPv4
addresses are mapped into IPv6 and used by physical IPv6 nodes.
The original IPv4 form of these blocks of service provider's IPv4
addresses are used to represent the physical IPv6 nodes in IPv4.
Note that stateless translation supports both IPv6 initiated as
well as IPv4 initiated communications.
</t>
<t>
For stateful translation, the algorithmic mapping table is not used to
translate source addresses in IPv6 to IPv4 direction and destination addresses in IPv4 to IPv6 direction. Instead,
a state table is used to
translate IPv6 source addresses to IPv4 source addresses in IPv6 to IPv4 direction and
translate IPv4 destination addresses to IPv6 destination addresses in IPv4 to IPv6 direction.
In this case,
blocks of the service provider's IPv4 addresses are maintained in
the translator as the IPv4 address pools and are dynamically bound
to specific IPv6 addresses. The original IPv4 form of these
blocks of service provider's IPv4 addresses is used to represent
the IPv6 address in IPv4. However, due to the dynamic binding,
stateful translation in general only supports IPv6-initiated
communication.
</t>
</list>
</t>
</section>
<section anchor="iit2" title="IP and ICMP Translation">
<t>
The IPv4/IPv6 translator is based on the update to the Stateless IP/ICMP
Translation Algorithm (SIIT) described in
<xref target="RFC2765"></xref>.
The algorithm
translates between IPv4 and IPv6 packet headers (including ICMP
headers).
</t>
<t>
The IP and ICMP translation document
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>
discusses header translation for both stateless and stateful modes,
but does not cover maintaining state in the stateful mode.
In the stateless mode, translation information is carried in the
address itself plus configuration in the translator,
permitting both IPv4->IPv6 and IPv6->IPv4 session
establishment. In the stateful mode, translation state is maintained
between IPv4 address/transport port tuples and IPv6 address/transport
port tuples, enabling IPv6 systems to open sessions with IPv4
systems. The choice of operational mode is made by the operator
deploying the network and is critical to the operation of the
applications using it.
</t>
</section>
<section anchor="napt64" title="Maintaining Translation State">
<t>
For the stateful translator, besides IP and ICMP translation, special
action must be taken to maintain the translation states.
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>
describes a mechanism for maintaining state.
</t>
</section>
<section anchor="DNS64" title="DNS64 and DNS46">
<t>
DNS64 <xref target="I-D.ietf-behave-dns64"></xref> and possible future DNS46 documents
describe the
mechanisms by which a DNS translator is intended to operate. It is
designed to operate on the basis of known address translation algorithms defined in
<xref target="I-D.ietf-behave-address-format"></xref>
</t>
<t>There are at least two possible implementations of a DNS64 and DNS46:
<list style="hanging">
<t hangText="Static records:">One could literally populate DNS
with corresponding A and AAAA records.
This mechanism works for scenarios 2, 3, 5 and 6.</t>
<t hangText="Dynamic Translation of static records:">In more
general operation, the preferred behavior is an A record to be
(retrieved and) translated to an AAAA record by the DNS64 if and only if
no reachable AAAA record exists, or for an AAAA record to be
(retrieved and) translated to an A record by the DNS46 if and only if
no reachable A record exists.
</t>
</list></t>
</section>
<section anchor="ALG" title="ALGs for Other Applications Layer Protocols">
<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
<xref target="RFC1928"></xref>
<xref target="RFC3089"></xref>.
Across NATs, it generally uses
passive mode. However, the designers of FTP 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. Other applications may be
similarly broken.</t>
<t>As a general rule, a simple operational recommendation will work
around many application issues, which is that there should be a
server in each domain or an instance of the server should have an
interface in each domain. For example, an SMTP MTA may be confused
by finding an IPv6 address in its HELO when it is connected to using
IPv4 (or vice versa), but would work perfectly well if it had an
interface in both the IPv4 and IPv6 domains and was used as an
application-layer bridge between them.</t>
</section>
</section>
<section anchor="scenario20" title="Operation Mode for Specific Scenarios">
<t>
Currently, the proposed solutions for IPv6/IPv4 translation
are classified into stateless translation and stateful translation.
</t>
<section anchor="stateless2" title="Stateless Translation">
<t>
For stateless translation, the translation information is carried in the address itself plus configuration in the translators,
permitting both IPv4->IPv6 and IPv6->IPv4 session initiation. Stateless translation
supports end-to-end address transparency and has better scalability compared with stateful translation.
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>.
</t>
<t>
The stateless translation mechanisms typically put constraints on
what IPv6 addresses can be assigned to IPv6 nodes that want to
communicate with IPv4 destinations using an algorithmic mapping.
For Scenario 1 ("an IPv6 network to the IPv4 Internet"),
it is not a serious drawback, since the address assignment policy
can be applied to satisfy this requirement for the IPv6 nodes that
need to communicate with the IPv4 Internet.
In addition, stateless translation supports Scenario 2
("the IPv4 Internet to an IPv6 network"),
which means that not only could servers move directly to IPv6
without trudging through a difficult transition period,
but they could do so without risk of losing connectivity
with the IPv4-only Internet.
</t>
<t>
Stateless translation can be used for Scenarios 1, 2, 5 and 6, i.e.,
it supports "an IPv6 network to the IPv4 Internet",
"the IPv4 Internet to an IPv6 network", "an IPv6 network to an IPv4 network"
and "an IPv4 network to an IPv6 network".
</t>
<figure anchor="IVIa"
title="Stateless translation for Scenarios 1 and 2">
<artwork align="center">
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\ / \\ //
\\ // ----------
--------
<====>
</artwork>
</figure>
<figure anchor="IVIb"
title="Stateless translation for Scenarios 5 and 6">
<artwork align="center">
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\\ // \\ //
-------- ---------
<====>
</artwork>
</figure>
<t>
The implementation of the stateless translator needs to refer to
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>,
and <xref target="I-D.ietf-behave-address-format"></xref>.
</t>
</section>
<section anchor="stateful2" title="Stateful Translation">
<t>
For stateful translation, the translation state is maintained between
IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6
systems to open sessions with IPv4 systems
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>.
</t>
<t>
Stateful translator can be used for Scenarios 1, 3 and 5, i.e.,
it supports "an IPv6 network to the IPv4 Internet",
"the IPv6 Internet to an IPv4 network" and "an IPv6 network to an IPv4 network".
</t>
<t>
For Scenario 1, any IPv6 addresses in an IPv6 network can use
stateful translation, however it typically only supports initiation
from the IPv6 side. In addition, it does not
result in stable addresses of IPv6 nodes that can be used in DNS,
which may cause problems for the protocols and applications that do not deal well with highly
dynamic addresses.
</t>
<figure anchor="NAT64a"
title="Stateful translation for Scenario 1">
<artwork align="center">
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
</artwork>
</figure>
<t>
Scenario 3 handles servers using IPv4 private addresses
<xref target="RFC1918"></xref>
and being reached from the IPv6 Internet. This includes cases
of servers that for some reason cannot be upgraded to IPv6 and
don't have public IPv4 addresses and yet need to be reached by
IPv6 nodes in the IPv6 Internet.
</t>
<figure anchor="NAT64b"
title="Stateful translation for Scenario 3">
<artwork align="center">
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
</artwork>
</figure>
<t>
Similarly, stateful translation can also be used for Scenario 5.
</t>
<figure anchor="NAT64c"
title="Stateful translation for Scenario 5">
<artwork align="center">
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
</artwork>
</figure>
<t>
The implementation of the stateful translator needs to refer to
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>,
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>,
and <xref target="I-D.ietf-behave-address-format"></xref>.
</t>
</section>
</section>
<section title="Layout of the Related Documents">
<t>
Based on the above analysis, the IPv4/IPv6 translation series consists of
the following documents.
</t>
<t>
<list style="symbols">
<t>
Framework for IPv4/IPv6 Translation (this document).
</t>
<t>
Address translation (the choice of IPv6 prefix and the choice of
method by which the remainder of the IPv6 address
is derived from an IPv4 address, part of the SIIT update)
<xref target="I-D.ietf-behave-address-format"></xref>.
</t>
<t>
IP and ICMP Translation (header translation and ICMP handling, part of the SIIT update)
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>.</t>
<t>
Xlate-stateful (stateful translation including session database and mapping table handling)
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>.
</t>
<t>
DNS64 (DNS64: A to AAAA mapping and DNSSec discussion)
<xref target="I-D.ietf-behave-dns64"></xref>.
</t>
<t>
FTP ALG <xref target="I-D.ietf-behave-ftp64"></xref>.
</t>
<t>
Others (DNS46, Multicast, etc).
</t>
</list>
</t>
<t>
The relationship among these documents is shown in the following figure.
</t>
<figure anchor="doc" title="Document Layout">
<artwork align="center"><![CDATA[
-----------------------------------------
| Framework for IPv4/IPv6 Translation |
-----------------------------------------
|| ||
-------------------------------------------------------------------
| || stateless and stateful || |
| -------------------- --------------------- |
| |Address Translation | <======== | IP/ICMP Translation | |
| -------------------- --------------------- |
| /\ /\ |
| || ------------------||------------ |
| || | stateful \/ |
| ----------------- | --------------------- |
| | DNS64/DNS46 | | | Table Maintenance | |
| ----------------- | --------------------- |
-------------------------------------------------------------------
/\ /\
|| ||
----------------- --------------------
| FTP ALG | | Others |
----------------- --------------------
]]></artwork>
</figure>
<t>
In the document layout, the IP/ICMP Translation and DNS64/DNS46 normatively refer to Address Translation.
The Table Maintenance and IP/ICMP Translation normatively refer to each other. </t>
<t>
The FTP ALG and other documents normatively refer to the Address Format, IP/ICMP Translation and Table Maintenance
documents.
</t>
</section>
</section>
<section anchor="ops22" title="Translation in Operation">
<t>Operationally, there are two ways that translation could be used -
as a permanent solution making transition "the other guy's problem",
and as a temporary solution for a new part of one's network while
bringing up IPv6 services in the remaining parts of one's network.
We obviously recommend the latter at the present stage.
For the IPv4
parts of the network,
<xref target="RFC4213"></xref>'s
recommendation holds. Bring IPv6
up in those domains, move production to it, and then take down
the now-unnecessary IPv4 service when economics warrant. This
approach to transition entails the least risk.
</t>
<figure anchor="operation" title="Translation Operational Model">
<artwork align="center"><![CDATA[
----------------------
////// \\\\\\
/// IPv4 or Dual Stack \\\
|| +----+ Routing +-----+ ||
| |IPv4| |IPv4+| |
| |Host| |IPv6 | |
|| +----+ |Host | ||
\\\ +-----+ ///
\\\\\----+----+-+-----+ +----+-/////
|XLAT|-|DNS64|-|FTP |
| |-|DNS46|-|ALG |
/////----+----+ +-----+ +----+-\\\\\
/// \\\
|| +-----+ +----+ ||
| |IPv4+| |IPv6| |
| |IPv6 | |Host| |
|| |Host | +----+ ||
\\\ +-----+ IPv6-only Routing ///
\\\\\\ //////
----------------------
]]></artwork>
</figure>
<t>
<xref target="operation"></xref>
shows that, during the coexistence phase, one expects a
combination of hosts, applications, and networks. Hosts might include
IPv6-only gaming devices and handsets, older
computer operating systems that are IPv4-only, and modern mainline
operating systems that support both.
Applications might include ones that are IPv4-only and modern
applications that support both IPv4 and IPv6.
Networks might include dual-stack devices operating in single-stack networks,
whether that stack is IPv4 or IPv6 and fully functional dual-stack networks.
</t>
</section>
<section title="Unsolved Problems">
<t>
The framework does not cover all possible scenarios,
and may be extended in the future to address them.
</t>
</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>
This document is the framework of IPv4/IPv6 translation. The security issues are addressed in individual IPv4/IPv6 translation documents, i.e.
<xref target="I-D.ietf-behave-address-format"></xref>,
<xref target="I-D.ietf-behave-v6v4-xlate"></xref>,
<xref target="I-D.ietf-behave-v6v4-xlate-stateful"></xref>,
<xref target="I-D.ietf-behave-dns64"></xref>,
<!-- <xref target="I-D.xli-behave-dns46-for-stateless"></xref> -->
and
<xref target="I-D.ietf-behave-ftp64"></xref>.
</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, Bo Zhou, Brian Carpenter, Dan Wing, Dave Thaler, David Harrington,
Ed Jankiewicz, Gang Chen, Hui Deng, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein,
Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo,
Phil Roberts, Philip Matthews, Remi Denis-Courmont and Remi Despres. </t>
<t>Ed Jankiewicz described the transition plan.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include="reference.I-D.ietf-behave-address-format"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful"?>
<?rfc include="reference.I-D.ietf-behave-dns64"?>
<?rfc include="reference.I-D.ietf-behave-ftp64"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.1918' ?>
<?rfc include='reference.RFC.1923' ?>
<?rfc include='reference.RFC.2765'?>
<?rfc include='reference.RFC.2766' ?>
<?rfc include='reference.RFC.4192' ?>
<?rfc include='reference.RFC.4193' ?>
<?rfc include='reference.RFC.4213' ?>
<?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.RFC.1928' ?>
<?rfc include='reference.RFC.3089' ?>
<?rfc include='reference.I-D.ietf-softwire-dual-stack-lite' ?>
<reference anchor="6NET">
<front>
<title>Website: http://www.6net.org/</title>
<author fullname="" initials="" surname="">
<organization></organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:10 |