behave F. Baker
Internet-Draft Cisco Systems
Intended status: Informational X. Li
Expires: April 27, 2010 C. Bao
CERNET Center/Tsinghua University
K. Yin
Cisco Systems
October 24, 2009
Framework for IPv4/IPv6 Translation
draft-ietf-behave-v6v4-framework-03
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Baker, et al. Expires April 27, 2010 [Page 1]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
Abstract
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7
1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 8
2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 10
2.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . . . 11
2.2. Scenario 2: the IPv4 Internet to an IPv6 network . . . . . 13
2.3. Scenario 3: the IPv6 Internet to an IPv4 network . . . . . 13
2.4. Scenario 4: an IPv4 network to the IPv6 Internet . . . . . 14
2.5. Scenario 5: an IPv6 network to an IPv4 network . . . . . . 15
2.6. Scenario 6: an IPv4 network to an IPv6 network . . . . . . 15
2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet . . . . 16
2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet . . . . 17
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Translation Components . . . . . . . . . . . . . . . . . . 18
3.1.1. Address Translation . . . . . . . . . . . . . . . . . 18
3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 19
3.1.3. Maintaining Translation State . . . . . . . . . . . . 19
3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 19
3.1.5. ALGs for Other Applications Layer Protocols . . . . . 20
3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 20
3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 20
3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 22
3.3. Layout of the Related Documents . . . . . . . . . . . . . 23
4. Translation in Operation . . . . . . . . . . . . . . . . . . . 25
5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Baker, et al. Expires April 27, 2010 [Page 2]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
1. Introduction
This note describes a framework for IPv4/IPv6 translation. This is
in the context of replacing NAT-PT [RFC2766], which was deprecated by
[RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a
somewhat rational manner while transitioning to an IPv6-only network.
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 [RFC1923] 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.
[RFC4213] 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 [RFC4192], 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.
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 affect 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?
This document describes translation as one of the tools networks
might use to facilitate coexistence and ultimate transition.
Baker, et al. Expires April 27, 2010 [Page 3]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
1.1. Why Translation?
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 6to4 [RFC3056], Teredo [RFC4380], ISATAP
[RFC5214], and DS-Lite [I-D.durand-softwire-dual-stack-lite]. 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:
o Operators of old protocol 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
o It doesn't enable new protocol users to communicate with old
protocol users without dual-stack hosts.
As noted, in this work, we look at Internet Protocol translation as a
transition strategy. [RFC4864] 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.
1.2. Terminology
The following terminology is used in this document and other
documents related to it.
An IPv4 network: A specific network that has an IPv4-only
deployment. This could be an enterprise's IPv4-only network or an
ISP's IPv4-only network. The IPv4 Internet is the set of all
interconnected IPv4 networks.
Baker, et al. Expires April 27, 2010 [Page 4]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
An IPv6 network: A specific network that has an IPv6-only
deployment. This could be an enterprise's IPv6-only network or an
ISP's IPv6-only network. The IPv6 Internet is the set of all
interconnected IPv6 networks.
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.
IPv4-converted addresses: They are the IPv6 addresses used to
represent IPv4 hosts. They have an explicit mapping relationship
to IPv4 addresses. This relationship is self described by mapping
IPv4 address in the IPv6 address. Both stateless and stateful
translators are using IPv4-converted IPv6 addresses to represent
IPv4 hosts.
IPv4-only: An IPv4-only implementation, in this context, comprises
an IPv4-enabled end system stack, applications 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.
IPv4-translatable addresses: They are the IPv6 addresses to be
assigned to IPv6 hosts for the stateless translator. They have an
explicit mapping relationship to IPv4 addresses. This
relationship is self described by mapping IPv4 address in the IPv6
address. The stateless translator is using the corresponding IPv4
addresses to represent the IPv6 hosts. The stateful translator
does not use this kind of addresses, since the IPv6 hosts are
represnted by the IPv4 address pool in the translator via dynamic
states.
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.
Baker, et al. Expires April 27, 2010 [Page 5]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
Network-Specific Prefix (NSP): IPv6 prefixes are assigned to a
network operator by its regional internet registrar (RIR). From
an IPv6 prefix assigned to the operator, the operator chooses a
longer prefix for use by the operator's translator(s). Hence a
given IPv4 address would have different IPv6 representations in
different networks that use different prefixes. A network-
specific prefix is also known as a Local Internet Registry (LIR)
prefix.
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 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:
Hidden state: the existence of this state is unknown outside the
network element that contains it.
Known state: the existence of this state is known by other
network elements.
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.
Stateful Translator: A translator that uses stateful translation for
either the source or destination address. A stateful translator
also uses a stateless translation algorithm for the other type of
address.
Stateless Translation: A translation algorithm that is not
"stateful" is "stateless". It derives its needed information
algorithmically from the messages it is translating.
Stateless Translator: A translator that uses only stateless
translation for both destination address and source address.
Well-Known Prefix (WKP): A prefix assigned by IANA. In this case,
there would be a single representation of a public IPv4 address in
the IPv6 address space.
Baker, et al. Expires April 27, 2010 [Page 6]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
1.3. Translation Objectives
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
[RFC4966] .
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 three main categories:
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.
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:
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.
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
Baker, et al. Expires April 27, 2010 [Page 7]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
content from servers that they find reliable and available.
If the question is the ability to open connections between systems,
then one must ask who opens connections.
o 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.
o 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.
o In many situations, hosts are purely clients. In those
situations, we do not need an algorithm to enable connections to
those hosts
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 reduce, as
much as possible, the software changes in the hosts necessary to
support translation.
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.
1.4. Transition Plan
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
Baker, et al. Expires April 27, 2010 [Page 8]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
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.
Curran's "A Transition Plan for IPv6" [RFC5211] proposes a three-
phase progression:
Preparation Phase (current): characterized by pilot use of IPv6,
primarily through transition mechanisms defined in [RFC4213], and
planning activities.
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.
Post-Transition Phase (2012 and beyond): characterized by a
preponderance of IPv6-based services and diminishing support for
IPv4-based services.
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.
In each of these phases, the coexistence problem and solution space
has a different focus:
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.
Transition Phase: This is the last stage of "S" curve. 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 in IPv4-only or preferring IPv4. During this
Baker, et al. Expires April 27, 2010 [Page 9]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
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.
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.
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 [RFC4213][RFC5211], 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.
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.
2. Scenarios for IPv4/IPv6 Translation
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
Baker, et al. Expires April 27, 2010 [Page 10]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
issues that a translator for a more specific situation may not have
at all.
The intention of this document is to focus on network-based
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.
Based on the transition plan described in Section 1.4, there are four
types of IPv4/IPv6 translation scenarios:
a. Interoperation between an IPv6 network and the IPv4 Internet
b. Interoperation between an IPv4 network and the IPv6 Internet
c. Interoperation between an IPv6 network and an IPv4 network
d. Interoperation between the IPv6 Internet and the IPv4 Internet
Each one in 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.
Scenario 1: an IPv6 network to the IPv4 Internet
Scenario 2: the IPv4 Internet to an IPv6 network
Scenario 3: the IPv6 Internet to an IPv4 network
Scenario 4: an IPv4 network to the IPv6 Internet
Scenario 5: an IPv6 network to an IPv4 network
Scenario 6: an IPv4 network to an IPv6 network
Scenario 7: the IPv6 Internet to the IPv4 Internet
Scenario 8: the IPv4 Internet to the IPv6 Internet
We will discuss each scenario in detail in the next section.
2.1. Scenario 1: an IPv6 network to the IPv4 Internet
Due to the lack of the publicly routable 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
Baker, et al. Expires April 27, 2010 [Page 11]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
IPv4 Internet.
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 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.
Other cases that have been mentioned include wireless ISP networks
and sensor networks. This bears a striking resemblance to this
scenario as well, if one considers the ISP network to simply be a
very special kind of enterprise network.
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 1: Scenario 1
Currently, there are two proposed solutions for this scenario: NAT64
[I-D.bagnulo-behave-nat64] as the stateful translation and IVI
[I-D.xli-behave-ivi] as the stateless translation schemes,
respectively. The NAT64 can support any IPv6 addresses in an IPv6
network communicating with the IPv4 Internet, while IVI can support a
subset of the IPv6 addresses in an IPv6 network communicating with
the IPv4 Internet.
Baker, et al. Expires April 27, 2010 [Page 12]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
2.2. Scenario 2: the IPv4 Internet to an IPv6 network
This scenario is predicted to become increasingly important as the
network administrators are under pressure to put IPv6-only servers in
its network, while the majority of the Internet users are still in
the IPv4 Internet. For example, for an IPv6 operator, it may be a
difficult proposition to leave all IPv4-only devices without
reachability. 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.
--------
// \\ ----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \\ //
\\ // ----------
--------
====>
Figure 2: Scenario 2
In general, this scenario presents a hard case for translation.
Stateful translation such as NAT-PT [RFC2766] can be used in this
scenario, but it requires tightly coupled DNS ALG in the translator
and this technique was deprecated by the IETF [RFC4966].
The stateless translation solution IVI [I-D.xli-behave-ivi] in
Scenario 1 can also work in Scenario 2, since it can support IPv4-
initiated communications with a subset of the IPv6 addresses in an
IPv6 network.
2.3. Scenario 3: the IPv6 Internet to an IPv4 network
There is a requirement for a legacy IPv4 network to provide services
to IPv6 hosts.
Baker, et al. Expires April 27, 2010 [Page 13]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 3: Scenario 3
The 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 small subset.
However, IPv6-initiated communication can be achieved through
stateful translation. For example, NAT64 [I-D.bagnulo-behave-nat64]
can support this scenario.
2.4. Scenario 4: an IPv4 network to the IPv6 Internet
Due to technical or economical constraints, the network is IPv4-only,
and IPv4-only hosts (applications) may require communicating with the
global IPv6 Internet.
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 | XLAT: v4/v6
| Network +----+ Internet | Translator
| |DNS | | DNS: DNS46
\ +----+ /
\\ // \ /
--------- \\ //
----------
=====>
Figure 4: Scenario 4
In general, this scenario presents a hard case for translation.
Stateful translation such as NAT-PT [RFC2766] can be used in this
Baker, et al. Expires April 27, 2010 [Page 14]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
scenario, but it requires a tightly coupled DNS ALG in the translator
and this technique was deprecated by the IETF [RFC4966].
From the transition phase discussion in Section 1.4, this scenario
will probably only occur when we are well past the early stage of the
"S" curve and the v4/v6 transition has already moved to the right
direction. Therefore, in-network translation is not viable for this
scenario and other techniques should be considered.
2.5. Scenario 5: an IPv6 network to an IPv4 network
This is one of the scenarios where both an IPv4 network and an IPv6
network are within the same organization.
The IPv4 addresses used are either public IPv4 addresses or [RFC1918]
addresses. The IPv6 addresses used are either public IPv6 addresses
or ULAs (Unique Local Addresses) [RFC4193].
--------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 5: Scenario 5
The translation requirement from this scenario has no significant
difference from scenario 1, so both the stateful and stateless
translation schemes discussed in Section 2.1 apply here.
2.6. Scenario 6: an IPv4 network to an IPv6 network
This is another scenario when both an IPv4 network and an IPv6
network are within the same organization.
The IPv4 addresses used are either public IPv4 addresses or [RFC1918]
addresses. The IPv6 addresses used are either public IPv6 addresses
or ULAs (Unique Local Addresses) [RFC4193].
Baker, et al. Expires April 27, 2010 [Page 15]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\\ // \\ //
-------- ---------
====>
Figure 6: Scenario 6
The translation requirement from this scenario has no significant
difference from scenario 2, so the translation scheme discussed in
Section 2.2 applies here.
2.7. Scenario 7: the IPv6 Internet to the IPv4 Internet
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.
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \ /
\\ // \\ //
-------- ---------
<====
Figure 7: Scenario 7
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.
Baker, et al. Expires April 27, 2010 [Page 16]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
If we ever run into this scenario, fortunately, the IPv4-IPv6
transition has already past the early stage of the "S" curve,
therefore, there is no obvious business reason to demand a
translation solution as the only transition strategy.
2.8. Scenario 8: the IPv4 Internet to the IPv6 Internet
This seems the ideal case for in-network translation technology,
where any IPv4-only host or application on the global Internet can
open connection to any IPv6-only host or application on the global
Internet.
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \ /
\\ // \\ //
-------- ---------
====>
Figure 8: Scenario 8
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.
If we ever run into this scenario, fortunately, the IPv4-IPv6
transition has already past the early stage of the "S" curve,
therefore, there is no obvious business reason to demand a
translation solution as the only transition strategy.
3. Framework
Having laid out the preferred transition model and the options for
implementing it (Section 1.1), defined terms (Section 1.2),
considered the requirements (Section 1.3), considered the transition
model (Section 1.4), and considered the kinds of scenarios the
facility would support (Section 2), we now turn to a framework for
IPv4/IPv6 translation. The framework contains the following
Baker, et al. Expires April 27, 2010 [Page 17]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
components:
o Address translation
o IP and ICMP translation
o Maintaining translation state
o DNS64 and DNS46
o ALGs for other application-layer protocols (e.g., FTP)
3.1. Translation Components
3.1.1. Address Translation
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 [I-D.ietf-behave-address-format].
Note that translating IPv4 address to IPv6 address and translating
IPv6 address to IPv4 address are different for stateless translation
and stateful translation. [I-D.ietf-behave-address-format].
o For stateless translation, the algorithmic mapping algorithm is
used both to translate IPv4 addresses to IPv6 addresses and to
translate IPv6 addresses to IPv4 addresses. In this case, blocks
of service provider's IPv4 addresses are mapped into IPv6 and used
by physical IPv6 hosts. The original IPv4 form of these blocks of
service provider's IPv4 addresses are used to represent the
physical IPv6 hosts in IPv4. Note that the stateless translation
supports both IPv6 initiated as well as IPv4 initiated
communications.
o For stateful translation, the algorithmic mapping algorithm is
used to translate IPv4 addresses to IPv6 addresses, while a
session initiated state table is used to translate IPv6 addresses
to IPv4 addresses. In this case, blocks of service provider's
IPv4 addresses are maintained in the translator as the IPv4
address pools and dynamically bind to the specific IPv6 addresses.
The original IPv4 form of these blocks of service provider's IPv4
addresses are used to represent the physical IPv6 host in IPv4.
However, due to the dynamic binding, stateful translation in
general only supports IPv6-initiated communication.
Baker, et al. Expires April 27, 2010 [Page 18]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
3.1.2. IP and ICMP Translation
The IPv4/IPv6 translator is based on the update to the Stateless IP/
ICMP Translation Algorithm (SIIT) described in [RFC2765]. The
algorithm translates between IPv4 and IPv6 packet headers (including
ICMP headers) [I-D.ietf-behave-v6v4-xlate].
The IP and ICMP translation document [I-D.ietf-behave-v6v4-xlate]
addresses both stateless and stateful modes. In the stateless mode,
translation information is carried in the address itself, permitting
both IPv4->IPv6 and IPv6->IPv4 session establishment with neither
state nor configuration in the IP/ICMP translator. 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.
3.1.3. Maintaining Translation State
For the stateful translator, besides IP and ICMP translation, special
action must be taken to maintain the translation states. NAT64
[I-D.ietf-behave-v6v4-xlate-stateful] describes a mechanism for
maintaining state.
3.1.4. DNS64 and DNS46
[I-D.ietf-behave-dns64] and possible future documents 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, are known to
network elements outside of the data plane translator, but the
process of serving them to applications does not interact with the
data plane translator in any way.
There are at least two possible implementations of a DNS64 and DNS46:
Static records: One could literally populate DNS with corresponding
A and AAAA records. This is most appropriate for stub services
such as access to a legacy printer pool.
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 DNS64 if and only if no reachable AAAA record exists, or
for an AAAA record to be (retrieved and) translated by the DNS46
if and only if no reachable A record exists.
Baker, et al. Expires April 27, 2010 [Page 19]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
3.1.5. ALGs for Other Applications Layer Protocols
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 [RFC1928] [RFC3089]. 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.
Other applications may be similarly broken.
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.
3.2. Operation Mode for Specific Scenarios
Currently, the proposed solutions for IPv6/IPv4 translation are
classified into stateless translation and stateful translation.
3.2.1. Stateless Translation
For stateless translation, the translation information is carried in
the address itself, permitting both IPv4->IPv6 and IPv6->IPv4
sessions establishment. The stateless translation supports end-to-
end address transparency and has better scalability compared with the
stateful translation. [I-D.ietf-behave-v6v4-xlate]
[I-D.xli-behave-ivi].
Although the stateless translation mechanisms typically put
constraints on what IPv6 addresses can be assigned to IPv6 hosts that
want to communicate with IPv4 destinations using an algorithmic
mapping. 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 hosts which need the
communication ability to the IPv4 Internet. In addition, the
stateless translator 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.
Stateless translation can be used for Scenarios 1, 2, 5 and 6, i.e.
Baker, et al. Expires April 27, 2010 [Page 20]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
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".
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateless v4/v6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\ / \\ //
\\ // ----------
--------
<====>
Figure 9: Stateless translation for Scenarios 1 and 2
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64/DNS46
\\ // \\ //
-------- ---------
<====>
Figure 10: Stateless translator for Scenarios 5 and 6
The implementation of the stateless translator needs to refer to
[I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-address-format], and
[I-D.ietf-behave-dns64].
Baker, et al. Expires April 27, 2010 [Page 21]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
3.2.2. Stateful Translation
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
[I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful].
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".
For Scenario 1, any IPv6 addresses in an IPv6 network can use
stateful translation, however it typically only supports initiation
from the IPv6 side (NAT64 doesn't support IPv4-initiation), and does
not result in stable addresses that can be used in DNS, other
protocols and applications that do not deal well with highly dynamic
addresses.
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateful v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 11: Stateful translator for Scenario 1
For scenario 3, the servers using IPv4 private addresses [RFC1918]
and being reached from the IPv6 Internet basically includes the cases
that for whatever reason the servers cannot be upgraded to IPv6 and
they don't have public IPv4 addresses and it would be useful to allow
IPv6 nodes in the IPv6 Internet to reach those servers.
Baker, et al. Expires April 27, 2010 [Page 22]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 12: Stateful translator for Scenario 3
Similarly, the stateful translator can also be used for Scenario 5.
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: v4/v6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 13: Stateful translator for Scenario 5
The implementation of the stateful translator needs to refer to
[I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful],
[I-D.ietf-behave-address-format], and [I-D.ietf-behave-dns64].
3.3. Layout of the Related Documents
Based on the above analysis, the IPv4/IPv6 translation series
consists of the following documents.
o Framework for IPv4/IPv6 Translation (this document).
o Address translation (The choice of IPv6 prefix and the choice of
method by which the remainder of the IPv6 address is derived from
Baker, et al. Expires April 27, 2010 [Page 23]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
an IPv4 address, part of the SIIT update)
[I-D.ietf-behave-address-format],
o IP and ICMP Translation (Header translation and ICMP handling,
part of the SIIT update.) [I-D.ietf-behave-v6v4-xlate].
o Xlate-stateful (Stateful translation including session database
and mapping table handing) [I-D.ietf-behave-v6v4-xlate-stateful].
o DNS64/DNS46 (DNS64: A to AAAA mapping and DNSSec discussion)
[I-D.ietf-behave-dns64].
o FTP ALG.
o Others (Multicast, etc).
The relationship among these documents is shown in the following
figure.
-----------------------------------------
| Framework for IPv4/IPv6 Translation |
-----------------------------------------
|| ||
-------------------------------------------------------------------
| || stateless and stateful || |
| -------------------- --------------------- |
| |Address Translation | <======== | IP/ICMP Translation | |
| -------------------- --------------------- |
| /\ /\ |
| || ------------------||------------ |
| || | stateful \/ |
| ----------------- | --------------------- |
| | DNS64/DNS46 | | | Table Maintenance | |
| ----------------- | --------------------- |
-------------------------------------------------------------------
/\ /\
|| ||
----------------- --------------------
| FTP ALG | | Others |
----------------- --------------------
Figure 14: Document Layout
In the document layout, the IP/ICMP Translation and DNS64/DNS46 refer
Baker, et al. Expires April 27, 2010 [Page 24]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
to Address Translation. The Table Maintenance and IP/ICMP
Translation refer to each other.
The FTP ALG and other documents refer to the Address Format, IP/ICMP
Translation and Table Maintenance documents.
4. Translation in Operation
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. For the IPv4 parts of the
network, [RFC4213]'s recommendation holds: bringing IPv6 up in those
domains, moving production to it, and then taking down the now-
unnecessary IPv4 service when economics warrant remains the least
risk approach to transition.
----------------------
////// \\\\\\
/// IPv4 or Dual Stack \\\
|| +----+ Routing +-----+ ||
| |IPv4| |IPv4+| |
| |Host| |IPv6 | |
|| +----+ |Host | ||
\\\ +-----+ ///
\\\\\+----+ +---+ +----+ +----+/////
|XLAT|-|DNS|-|SMTP|-|XLAT|
| |-|64 |-|MTA |-| |
/////+----+ +---+ +----+ +----+\\\\\
/// \\\
|| +-----+ +----+ ||
| |IPv4+| |IPv6| |
| |IPv6 | |Host| |
|| |Host | +----+ ||
\\\ +-----+ IPv6-only Routing ///
\\\\\\ //////
----------------------
Figure 15: Translation Operational Model
During the coexistence phase, as shown in Figure 15, one expects a
combination of hosts - IPv6-only gaming devices and handsets, older
computer operating systems that are IPv4-only, and modern mainline
operating systems that support both. One also expects a combination
Baker, et al. Expires April 27, 2010 [Page 25]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
of networks - dual-stack devices operating in single-stack networks
are effectively single-stack, whether that stack is IPv4 or IPv6, as
the other isn't providing communications services.
5. Unsolved Problems
This framework could support multicast; some discussions are in
[I-D.venaas-behave-mcast46] and [I-D.xli-behave-ivi].
This framework could support stateless translation with IPv4 address
and transport port number multiplexing, some discussions are in
[I-D.xli-behave-ivi].
6. IANA Considerations
This memo requires no parameter assignment by the IANA.
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.
7. Security Considerations
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.
8. Acknowledgements
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, Congxiao Bao, Dan Wing,
Dave Thaler, Ed Jankiewicz, Fred Baker, Gang Chen, Hui Deng, 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.
Ed Jankiewicz described the transition plan.
Baker, et al. Expires April 27, 2010 [Page 26]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
9. References
9.1. Normative References
[I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-00 (work in progress),
August 2009.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-01 (work in progress),
October 2009.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-02 (work in
progress), October 2009.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work
in progress), October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
9.2. Informative References
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-bagnulo-behave-nat64-03 (work in
progress), March 2009.
[I-D.durand-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
Baker, et al. Expires April 27, 2010 [Page 27]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
exhaustion", draft-durand-softwire-dual-stack-lite-01
(work in progress), November 2008.
[I-D.venaas-behave-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator",
draft-venaas-behave-mcast46-01 (work in progress),
July 2009.
[I-D.xli-behave-ivi]
Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
IPv6 Coexistence and Transition", draft-xli-behave-ivi-02
(work in progress), June 2009.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement
for Historic Status", RFC 1923, March 1996.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
for IPv6 and NATs", RFC 2428, September 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
RFC 3089, April 2001.
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
Relay Translator", RFC 3142, June 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
Baker, et al. Expires April 27, 2010 [Page 28]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211,
July 2008.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
Baker, et al. Expires April 27, 2010 [Page 29]
Internet-Draft Framework for IPv4/IPv6 Translation October 2009
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
Email: fred@cisco.com
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
Email: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn
Kevin Yin
Cisco Systems
No. 2 Jianguomenwai Ave, Chaoyang District
Beijing, 100022
China
Phone: +86-10-8515-5094
Email: kyin@cisco.com
Baker, et al. Expires April 27, 2010 [Page 30]
