One document matched: draft-baker-behave-ivi-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29>printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-behave-ivi-00" ipr="full3978"
updates="2765, 2766">
<front>
<title>IVI Update to SIIT and NAT-PT</title>
<author fullname="Xing Li" initials="X." surname="Li">
<organization>CERNET Center/Tsinghua University</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<region></region>
<country>China</country>
</postal>
<phone>+86 62785983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<author fullname="Congxiao Bao" initials="C." surname="Bao">
<organization>CERNET Center/Tsinghua University</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<region></region>
<country>China</country>
</postal>
<phone>+86 62785983</phone>
<email>congxiao@cernet.edu.cn</email>
</address>
</author>
<author fullname="Fred Baker" initials="F.J." 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>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2008" />
<area>Transport Area</area>
<workgroup>Behave</workgroup>
<abstract>
<t>This note proposes an address and service architecture designed to
facilitate transition from an IPv4 Internet to an IPv6 Internet. This
service contains three parts: A DNS Application Layer Gateway, a
stateful Network Address Translator that enables IPv6 clients to
initiate connections to IPv4 servers and peers, and a stateless Network
Address Translator that enables IPv4 and IPv6 systems to interoperate
freely.</t>
<t>It is couched as an update to RFCs 2765 and 2766. This is because the
stateless service is essentially the SIIT with a different address
format, and because the DNS Application Layer Gateway and the stateful
translator have significant similarities to NAT-PT. There are, however,
important differences from NAT-PT, responsive to the issues raised in
RFC 4966.</t>
</abstract>
<!--
<note title='Foreword'>
</note>
-->
<!--
<note title='Requirements Language'>
<t>
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be
interpreted as described in
<xref target='RFC2119'>
RFC
2119
</xref>
.
</t>
</note>
-->
<!--
<?rfc needLines='10' ?>
<texttable anchor='table_example' title='A Very Simple
Table'>
<preamble>
Tables use ttcol to define column headers
and widths.
Every cell then has a "c" element for its
content.
</preamble>
<ttcol align='center'>
ttcol #1
</ttcol>
<ttcol align='center'>
ttcol #2
</ttcol>
<c>c #1 </c> <c> c #2 </c> <c> c #3 </c> <c> c #4 </c> <c> c #5 </c> <c> c #6 </c>
<postamble>
which is a very simple example.
</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>
There are multiple list styles: 'symbols', 'letters',
'numbers',
'hanging', 'format', etc.
</t>
<t>
<list style='symbols'>
<t>
First bullet
</t>
<t>
Second bullet
</t>
</list>
</t>
-->
<!--
<figure anchor='xml_happy' title='Figure N'>
<artwork align='center'>
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>This note documents the prototype being used for translation between
the IPv4 CERNET and the IPv6 CNGI-CERNET2 networks. This uses the
algorithms of <xref target="RFC2765">SIIT</xref> with a modified address
format, and a modified version of <xref target="RFC2766">NAT-PT</xref>.
In general, we recommend the use of native communication and dual stack
deployment. However, in several scenarios, the temporary use of
translation can simplify service deployment. Hence, we describe a
translation function.</t>
<t>It should be understood that protocol translation in any form is not
a viable long term solution for IPv6 deployment; it has value during a
certain part of the adoption curve, but will become unnecessary and
unhelpful at later points in the adoption curve. The objective of any
transition strategy, of which IVI is an example, is to facilitate
transition, not to enter a phase of heightened operational and capital
expenditure running two networks in parallel only to stay there. When
IPv6 is widely deployed and economic conditions support the move, we
expect service providers to withdraw IPv4 service.</t>
<t>The objectives of the translation function are to enable systems that
are unable to communicate with each other due to routing,
implementation, or parameter differences to communicate. Almost any
translation function will connect IPv6 systems with IPv4 systems or
systems in an IPv4 network. The difficulty is that this gives no
incentive to administrations to move their servers and peers from the
IPv4 domain to the IPv6 domain. Noting that dual stack implementations
such as recommended in <xref target="RFC4213"></xref> are not being
widely deployed by operators, the IVI model is designed to facilitate
placing servers and peers in the IPv6 domain, achieving native IPv6
connectivity without giving up IPv4 accessibility.</t>
<t>More specifically, the objectives are several: <list style="symbols">
<t>As with any network, IPv4 systems connected by an IPv4 network
can talk among themselves and IPv6 systems connected by an IPv6
network can talk among themselves. The first objective is to
preserve this and its scaling characteristics.</t>
<t>If one or both domains are IPv4+IPv6 but there exist systems with
only one architecture, we presume that IPv4 and IPv6 routing crosses
the gateway or a parallel router, and the systems are able to
communicate directly.</t>
<t>We want to enable systems that have no IPv6 address to access
servers and peers with IPv4-derived IPv6 addresses (IVI addresses)
in the IPv6 domain. This requires translation similar to that
described in <xref target="RFC2765">SIIT</xref>. This operation is
stateless.</t>
<t>We want to enable systems that have no IPv4 address to access
servers and peers in the IPv4 domain. For systems with IPv4-derived
IPv6 addresses (IVI addresses), this is solved by the SIIT extension
described in this document, given the appropriate AAAA record by IVI
DNS ALG. This operation is also stateless. Other systems with
non-IVI IPv6 addresses require some form of stateful translation.
This has similarities to the mechanisms described in <xref
target="RFC2766">NAT-PT</xref>. We wish to do this with a minimum of
maintained state.</t>
</list></t>
<t>Some have questioned the need for IPv4 access to IPv6-only servers
and peers, noting that in the Internet of 2008 there is no market
requirement for such access and any server or peer will require
accessibility from an IPv4 network. The issue is that this presumes a
certain point in the adoption curve; at another point in the adoption
curve, one hopes that there will be few takers for IPv4-only service. In
between, before IPv6 service for a server or peer becomes a requirement,
IPv6-only service for a server or peer must be feasible (it must be
conceivable that a server or peer with an IPv6 address will be useful).
We argue that it is easier for IPv6 service for a server or peer to
become feasible if it is possible to configure it with an IPv4-derived
IPv6 address than if it must also have IPv4 service. In the long term,
we believe that translation is not a service that service providers will
normally use, but is a helpful and perhaps necessary step in
transitioning to an IPv6 world.</t>
</section>
<section anchor="ivi-service" title="The IVI model">
<t>The Name "IVI" contracts "IV<->VI"; we are describing a
translation connection between systems using IPv4 or IPv6 that cannot
communicate using either IPv4 or IPv6. In any normal case where native
communication is possible between two systems, we argue that it is
preferable.</t>
<section title="IVI Network Model and communication objectives">
<t>An IVI Network, as shown in <xref target="ivi_network"></xref>,
consists of two or more network domains connected by one or more IVI
gateways. One of those networks either routes IPv4 but not IPv6, or
contains some hosts that only implement IPv4. The other network either
routes IPv6 but not IPv4, or contains some hosts that only implement
IPv6. Both networks contain clients, servers, and peers. It would be
advisable and perferable to implement a dual stack architecture in
both domains, but either due to address scarcity or the process
involved in IPv6 turn-up, that is not practical at the moment.</t>
<figure anchor="ivi_network" title="IVI Network Model">
<artwork align="center"><![CDATA[ ----------- -----------
/// IPv4 \\\ /// IPv6 \\\
// Network \\ // Network \\
/ \ / +-----+\
| | | |IPv6 | |
| +---------+ +-----+ |
| | IVI | |
| | Gateway | +-----+ |
| +-----+ +---------+ |IPv6/| |
| |IPv4 | | | | IVI | |
\ +-----+ / \ +-----+/
\\ // \\ //
\\\ /// \\\ ///
----------- -----------
]]></artwork>
</figure>
<t>Clearly, there are issues in IP addressing, and routing, DNS, and
the specifics of translation.</t>
</section>
<section anchor="ivi_address_format" title="IVI Address Format">
<t>The IVI Address is an IPv4 address embedded in an IPv6 address and
predictable by the gateway and systems on either side. The selection
of the LIR prefix, including its length and absolute value, is at the
option of the network administration; it is not fixed. <xref
target="ivi_address"></xref> shows one possible model. It enables the
IPv6 domain to assign the equivalent of IPv4 /24 prefixes to IPv6 LANs
(/64).</t>
<figure anchor="ivi_address" title="Example IVI Address Format">
<artwork align="center"><![CDATA[
IPv4 /24 routes in IPv6 domain
0 8 16 24 32 40 48 56 64 127
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LIR Prefix | IPv4 addr | entirely 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|<-----prefix part ---->|<--- host part --->|
]]></artwork>
</figure>
<t>In the IPv4 domain, this represents a prefix no longer than /24. In
the IPv6 domain, the "default route" advertising the entire IPv4
address space is the LIR /40 prefix. More specific prefixes up to /64
may be advertised as needed, or host (/128) routes.</t>
<t>The objective here is to enable the network administration to be in
control of the impact of the tradeoff on its routing.</t>
<t>The need to change the address format used by SIIT bears
repitition, although it has come up in other discussions. <xref
target="RFC4291"></xref> deprecated in the address format with the
brusque comment that "current IPv6 transition mechanisms no longer use
these addresses." The reason that they were not widely deployed was
that they gave network operators little control in routing, or ways to
ensure that route redistribution worked correctly. A prefix that lets
the LIR specify the upper bits gives the operator the flexibility to
identify the IVI gateway advertising the prefix and better control the
distribution of routes.</t>
</section>
<section anchor="routing" title="Routing in IVI networks">
<t>The IVI Gateway may be a general purpose router; in that mode, it
operates like any other router. However, it also advertises one or
more prefixes into both the IPv4 and the IPv6 domain, and when a
datagram is directed to an address within the translation prefix(es),
it translates the datagram.</t>
<t>As a Network Address Translator, the IVI Gateway offers one or both
of two services: stateless translation of addresses conforming to
<xref target="ivi_address"></xref> to and from IPv4 addresses, and
stateful translation between IPv6 addressing and a combination of an
IPv4 address and transport source port as is done in normal NATs.</t>
<t>In IPv4, the IVI gateway advertises the IPv4 prefix being used for
stateless IVI address translation; for example, if an IPv4 /20 is
being used as a set of /24 prefixes in the IPv6 domain, it would
advertise a /20 into the IPv4 domain. If the IVI gateway is offering
stateful translation, it may also advertise the addresses or prefix
being used for that service unless another router handles this.</t>
<t>In IPv6, the IVI gateway advertises a “default route for
global IPv4” - in the example given in <xref
target="ivi_address"></xref>, it would normally advertise the /40 LIR
prefix. If that is inappropriate - there are multiple non-overlapping
IPv4 domains or other concerns apply - it would advertise
"more-specific" prefixes as appropriate.</t>
<t>In the IPv6 domain, the routers or hosts that have been assigned
IVI prefixes or addresses subsidiary to the IVI prefix for a service
advertise the IVI /64s corresponding to those IPv4 /24s.</t>
<t>Clearly, there may be multiple non-overlapping IPv4 domains,
multiple non-overlapping IPv6 domains, and there may be multiple IVI
gateways. These are handled in a manner consistent with normal routing
practice in the Internet.</t>
<t>As shown in <xref target="ivi-reachability"></xref>, routing is
slightly more complex in an IVI service, but follows simple routing
concepts. In this example, <list style="symbols">
<t>IPv4 interfaces can open a session to any IVI address (e.g.
4Host1 -> IVI1),</t>
<t>IPv4 interfaces cannot open sessions to non-IVI IPv6 addresses
(e.g. 4Host1 X-> 6Host1),</t>
<t>IPv6 IVI interfaces can open a session to any IPv4 interface,
statelessly (e.g. IVI1 -> 4Host1),</t>
<t>Non-IVI IPv6 hosts can open sessions to IPv4 interfaces,
statefully (e.g. 6Host1 -> 4Host1),</t>
<t>Any two IPv4 hosts can open a session to either each other
using native routing (e.g. 4Host1 -> 4Host2, 4Host2 ->
4Host1),</t>
<t>Any two IPv6 hosts can open a session to either each other
using native routing, even using the IVI addresses (e.g. 6Host1
-> IVI1, IVI1 -> 6Host1, 6Host1 -> 6Host2, IVI1 ->
IVI2).</t>
</list></t>
<figure anchor="ivi-reachability" title="IVI Reachability example">
<artwork align="center"><![CDATA[ ------------- ------------
/ IPv4 Domain \ / IPv6 Domain \
/ \ / \
/ | \ / | +----+ \
/+------+ | \ / |-|IVI1| \
/ |4Host1|-| +--+ | \ / | +--+ | +----+ \
/ +------+ |-|R1|-| V |-|R3|-| +------+ \
| | +--+ | | | +--+ |-|6Host1| |
| | +-----+ | | +------+ |
| |-|XLATE|-| |
| | +-----+ | |
| | +--+ | | | +--+ | +------+ |
| +------+ |-|R2|-| | |-|R4|-|-|6Host2| |
\ |4Host2|-| +--+ | A | +--+ | +------+ /
\ +------+ | / \ | +----+ /
\ | / \ |-|IVI2| /
\ / \ | +----+ /
\ / \ /
--------------- ---------------
Route Advertisements:
R1: its IPv4 LAN R3: its IPv6 LAN
R2: its IPv4 LAN R3: its IVI /64
XLATE: IPv4 IVI prefix R4: its IPv6 LAN
possible IPv4 overlay R4: its IVI /64
prefix XLATE: IVI /40
]]></artwork>
</figure>
</section>
<section anchor="dns_service" title="DNS service in IVI networks">
<t>Rather than using the DNS Application Layer Gateway described in
<xref target="RFC2766"></xref> as specified, the IVI DNS ALG is a
one-way translation of A and MX records to AAA records with a
predictable address. The DNS server may be in the gateway or in a
separate system related to it.</t>
<t>As illustrated in <xref target="dns"></xref>, in the IPv4 domain,
the DNS server holds and advertises A records for systems with IPv4
addresses and for systems (servers or peers) that have IVI addresses.
These are generally pre-populated, if only via Dynamic DNS. The IPv4
network cannot distinguish them from other A records or from other
IPv4 addresses, so this works without host changes.</t>
<figure anchor="dns" title="Normal DNS Service">
<artwork align="center"><![CDATA[ IPv4 Domain IPv6 Domain
| |
A/MX Request\ | | / AAAA Request
\ | DNS ALG | /
\| as |/
/| Standard |\
/ | DNS | \
A/MX Response/ | Service | \ AAAA Response
| |
| |
]]></artwork>
</figure>
<t>Also as illustrated in <xref target="dns"></xref>, in the IPv6
domain, the DNS server holds and advertises AAAA records in the usual
fashion for systems with general IPv6 addresses.</t>
<t>As illustrated in <xref target="dns_alg"></xref>, in the IPv6
domain, when the DNS ALG receives a request for a AAAA record for
which it has nothing to reply, or for which normal DNS processing
receives a failure, it obtains an A or MX record from its own database
or another server, manufactures a corresponding AAAA record using an
IVI address, and returns that. The IPv6 network cannot distinguish
between these and other AAAA records, or between these and any other
address. Routing takes traffic through the gateway without host
changes.</t>
<figure anchor="dns_alg" title="DNS Record Translation Service">
<artwork align="center"><![CDATA[ IPv4 Domain IPv6 Domain
| |
| | AAAA Request
| |<---------
| |
A/MX Request | |
<-------------| DNS ALG |
| as IPv4 |
| to IPv6 |
------------->| translator |
A/MX Response | |
| |
| |--------->
| | AAAA Response
| |
| |
]]></artwork>
</figure>
<t>To avoid conflicts, the DNS server should have access to all AAAA
records advertised in the IPv6 domain. Otherwise, it may not know when
to create AAAA records from A or MX records.</t>
</section>
<section anchor="host" title="Host operation in IVI networks">
<t>Host behavior is unchanged by this specification. However, the
local administration might want to configure host <xref
target="RFC3484"></xref> address selection tables to optimize session
behavior.</t>
<section anchor="addr_selection"
title="Interaction of IVI Addresses with RFC3484 Address Selection">
<t><xref target="RFC3484"></xref> could be summarized as saying that
IPv6 systems should select source and destination addresses that are
as similar as possible. "Similarity" is defined in terms of prefix
length. Each remote address is compared to each local address, and
the remote address is considered to be most similar to the local
address with the longest string of equivalent prefix bits. The
specification recommends that sessions between the two systems
should prefer the address pair with the longest "similar"
prefix.</t>
<t>For example, if Alice has the addresses <list style="symbols">
<t>2001:db8:1234:1::A and</t>
<t>2001:db8:5678::A,</t>
</list></t>
<t>and Bob has the following addresses <list style="symbols">
<t>2001:db8:1234:2::B and</t>
<t>2001:db8:5ABC:B,</t>
</list></t>
<t>2001:db8:1234:1::A is more similar to 2001:db8:1234:2::B (the
first 48 bits are the same as opposed to only the first 33) and
2001:db8:5678::A is more similar to 2001:db8:5ABC:B (the first 36
bits are the same as opposed to the first 33). When Alice and Bob
communicate, the default address policy selects the address pair in
2001:db8:1234::/48 over 2001:db8:5000::/36 because it has a longer
"similar" prefix.</t>
<t>IPv4-only systems connect to IPv6 systems having IVI addresses
through the gateway, and lack a means to initiate a connection to
other IPv6 systems. Since IPv4 addresses appear in the IPv6 domain
as IVI addresses, <xref target="RFC3484"></xref> will guide
IPv6-only systems with IVI addresses to connect from their IVI
address when communicating with IPv4-only systems, as they are the
"most similar" addresses to those of their IPv4 counterparts. This
is important, because it promotes stateless translation
operation.</t>
<t>IVI systems may also find the IVI address pair "most similar"
when communicating with other systems with IVI addresses. This is
acceptable, as to the IPv6 domain they are simply IPv6 addresses and
will communicate directly.</t>
<t>In general, a system with both an IPv4 address and an IPv6
address can connect to a similar system using either technology.
There need be no preference order, and if one is chosen that is a
local matter.</t>
</section>
<section anchor="ivi-IPv4"
title="Interaction of IPv4 and IVI addresses on the same host">
<t>Systems that have both native IPv4 and translated IVI addresses
require attention to the configuration of the address choice
mechanism described in <xref target="RFC3484"></xref>. In such a
case, the redundancy suggests different uses for those addresses and
the possibility that IPv4 reachability has been fragmented.</t>
<t>For example, consider a host with a private IPv4 address and an
IVI address attempting to open a session with an IPv4 system with a
public address. Apart from actually successfully opening a session,
the addresses give no clue to actual reachability; the remote host
might be reachable via IPv4, or that might be a private network
disconnected from the Internet. If the remote host is reachable,
there is likely to be a NAT between the host and that system, making
the point moot. Similarly, the remote host might be reachable via
IVI, but it might not. It might be reachable via both
simultaneously, and it might not be reachable at all.</t>
<t>In general, native operation should be preferred to translated
operation, but the specifics of the environment may guide this
choice otherwise. As such, if an application is unable to open a
session using one address, it should try another, and the local
administration may consider configuring the <xref
target="RFC3484"></xref> tables to manage the case.</t>
</section>
</section>
<section anchor="ops" title="Operation of the IVI Gateway">
<t>The IVI Gateway has two modes, depending on the address of the IPv6
system using its services. These are the Stateless Mode, used to
connect between IPv6-only systems with IVI addresses and IPv4 systems,
and the Stateful Mode, used to connect other (non-IVI) IPv6-only
systems with IPv4 systems. IPv6 routing should not take traffic
between IPv6 systems in the same IPv6 domain through the gateway, as
it will follow more specific routes.</t>
<t>In either mode, the gateway is subject to the usual ills of Network
Address Translation. Protocols that exchange IP addresses should in
general not be exchanged across an IVI gateway, as the addresses are
not necessarily translatable or meaningful after translation. Also,
IPsec AH is compromised, so end-to-end privacy and authentication
issues should be dealt with in another way such as IPsec ESP.</t>
<t>In general, native (IPv6<->IPv6 or IPv4<->IPv4)
communications are preferable to any form of translation, and
stateless translation is preferable to stateful translation. In the
first case, this derives from the End-to-End principle discussed in
<xref target="Saltzer"></xref> - the utility of the network to the
applications that use it is generally maximized by staying out of
their way. In the latter case, this is due to the Simplicity Principle
discussed in <xref target="RFC3439"></xref>; given an easy and a hard
way to do something, and given equivalence of outcome, the easy way is
generally better for all concerned. Stateful and Stateless operation
both enable communication at the cost of a header exchange. Stateful
operation requires supporting dynamically-created per-flow tables in
the gateway while stateless operation requires no such thing.</t>
<section anchor="stateless" title="Stateless (1:1) Operation">
<t>In the stateless mode, the IVI gateway translates datagrams
exchanged between IPv4 systems and IPv6 systems that have an IVI
address. The translation is as described in <xref target="RFC2765">
SIIT </xref>, with the exception that the address format is as
described in <xref target="ivi_address_format"></xref> rather than
the IPv4 Compatible Address described in section 2.1 of that
document and deprecated in <xref target="RFC4291"></xref>. This
includes the necessary correction of transport layer checksums.</t>
<t>This is referred to as 'stateless', because the transformation
between IPv4 and IPv6 communication is entirely algorithmic and
requires no long-term state in either the hosts or the gateway.</t>
</section>
<section anchor="stateful" title="Stateful (1:n) Operation">
<t>In the stateful mode, the IVI gateway operates as a standard
Network Address Translator, but between IPv4 and IPv6 domains. This
is similar in many respects to the translation carried out in <xref
target="RFC2766">NAT-PT</xref>. This includes the necessary
correction of transport layer checksums.</t>
<t>IPv4 addresses and port numbers are mapped to IPv6 addresses in a
stateful manner, much as is done in IPv4-IPv4 network address
translation. The difference is that it is unidirectional; while the
source port in an IPv6-> IPv4 translation may have to be changed
to provide adequate flow identification, there is no necessity to
change the source port in the IPv4->IPv6 direction.</t>
</section>
</section>
</section>
<section anchor="phases" title="Transition plan">
<t>Merriam-Webster defines a "transition" as "passage from one state,
stage, subject, or place to another". Any transition plan that it
doesn't describe how one can expect to transition from an IPv4 to an
IPv6 network using it is incomplete. Coexistence is a necessary part,
and is likely to last for a period of time measured in the durations of
contracts. But if the increased operations and capital expenditures
implied in a state of IPv4+IPv6 coexistence doesn't ultimately lead to
the reduced expenditure state of a single network, it has not solved the
problem it was intended to address.</t>
<t>In the IVI model, the network is presumed to traverse four relatively
stable states. These are: <list style="symbols">
<t>IPv4-only Network</t>
<t>IPv4+IPv6 Dual Stack Network</t>
<t>IPv6+IPv4-accessible Network</t>
<t>IPv6 Network</t>
</list></t>
<section anchor="phase1" title="IPv4-only Network">
<t>The Internet, by and large, runs on IPv4 today. There are
experimental uses of IPv6 and infrastructure uses of supporting
internetwork protocols like MPLS and ATM, but end-to-end the protocol
is IPv4.</t>
</section>
<section anchor="phase2" title="IPv4+IPv6 Dual Stack Network">
<t><xref target="RFC4213"></xref> recommends the deployment of a dual
stack architecture. The reason is straightforward: if while we can map
IPv4 and IPv6 addresses 1:1 we aggressively deploy IPv6, we have two
opportunities. First, should there be a problem (and there are always
problems), user connectivity can be supported using IPv4 while the
IPv6 issues are sorted out. Second, at the point where the
availability of IPv4 addresses becomes a serious issue, IPv6
connectivity will be widespread, meaning that one can progress to the
next phase rather than scrambling for business continuity.</t>
<t>We presume that service providers and enterprise networks can
deploy IPv6 in parallel with IPv4, enabling current hosts (which are
mostly if not all IPv4+IPv6 capable) to communicate with either
architecture.</t>
</section>
<section anchor="phase3" title="IPv6+IPv4-accessible Network">
<t>The problem with <xref target="phase2"></xref> is that, although
people have had warning, they have chosen to not make use of it.
Hence, we are likely to see an interval in the near future during
which large numbers of IPv4 addresses are not available to extend
services and IPv6 is not readily available as a deployed and
purchasable service.</t>
<t>In such a case, a service provider has two main choices: obtain
what IPv4 addresses can be obtained at whatever cost they may be
available and extend his IPv4 service lifetime for a limited time
period, or obtain those addresses and use them in a strategic manner
to encourage movement to IPv6.</t>
<t>The IVI model suggests that remaining available IPv4 addresses
could be mapped to IPv6 addresses in such a manner than both IPv4 and
IPv6 systems can access servers and peers using them. A subscriber
might be given an IPv6 /56 or /48 prefix for native use and a smaller
IPv4 /30 or /24 prefix for translated use for servers and peers,
giving him an IPv6-only network whose servers and peers are available
using IPv4 via translation. Since the vast majority of systems operate
as clients or as peer-to-peer application peers, this would in fact
work.</t>
</section>
<section anchor="phase4" title="IPv6 Network">
<t>At some point, enough systems have IPv6 addresses that it no longer
makes economic sense to support the two networks in parallel. At this
point, one can expect customers to no longer purchase IPv4 or IVI
connectivity, IPv4 and IVI services to become economically
uninteresting, and a global IPv6-only network to emerge.</t>
</section>
</section>
<section anchor="future" title="Future extensions of the IVI Model">
<t>If the IPv6 hosts can be modified, the IVI model can have a stateless
(1:n)operation, which can support both IPv6 initiated communication as
well as IPv4 initiated communication.</t>
<t>For the operation and management concerns, the IVI model has ICMP
extension, which can be used in the traceroute or similar cases.</t>
<t>The IVI model can also support the use of multicast between IPv4 and
IPv6.</t>
<t>These extensions will be addressed in other documents.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo adds no new IANA considerations.</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>Three error cases are apparent: DNS errors, IPsec issues, and
application address errors.</t>
<t>As noted in <xref target="dns"></xref>, the errors that happen in
NAT-PT implementations can happen in an IVI network as well. These
mostly relate to the propagation of DNS records outside their domain of
applicability.</t>
<t>As noted in <xref target="ops"></xref>, the side-effects of Network
Address Translation between IPv4 and IPv4 apply when translating between
IPv4 and IPv6. IPsec AH, whose checksum covers the IP header, fails when
the header is changed. IPsec ESP, either directly on IP or over UDP are
usable across NATs and presumably across translators.</t>
<t>Protocols that exchange IP addresses should not normally be used
across a translator, as the addresses are generally not applicable on
the far side. Such protocols should be filtered, or permitted but used
with care.</t>
<t><xref target="APNAT"></xref> raises a variety of issues with Carrier
Grade Network Address Translators; those issues apply to IVI, and in
fact to any NAT. IVI helps with some, but does not mitigate others. If
anything, this is the reason that we recommend dual stack deployment of
IPv4 and IPv6 where possiblein the near term, and target general IPv6
deployment in the medium term, as opposed to remaining in a dual address
space environment forever.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Kevin Yin and Dan Wing helped with the review of the document.</t>
</section>
</middle>
<back>
<!-- references split to informative
and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2765' ?>
<?rfc include='reference.RFC.2766' ?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3439' ?>
<?rfc include='reference.RFC.3484'?>
<?rfc include='reference.RFC.4213' ?>
<?rfc include='reference.RFC.4291' ?>
<reference anchor="APNAT">
<front>
<title>A Better Approach than Carrier-Grade-NAT</title>
<author initials="O" surname="Maennel">
<organization>T-Labs</organization>
</author>
<author initials="R" surname="Bush">
<organization>IIJ</organization>
</author>
<author initials="L" surname="Cittadini">
<organization>Universita Roma Tre</organization>
</author>
<author initials="S" surname="Bellovin">
<organization>Columbia University</organization>
</author>
<date month="Aug" year="2008" />
</front>
<format target="http://rip.psg.com/~randy/080820.alt-to-cgn.pdf"
type="PDF" />
</reference>
<reference anchor="Saltzer">
<front>
<title>End-to-end arguments in system design</title>
<author initials="JH" surname="Saltzer">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<author initials="DP" surname="Reed">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<author initials="DD" surname="Clark">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<date month="Nov" year="1984" />
</front>
<seriesInfo name="ACM Transactions on Computer Systems (TOCS)"
value="v.2 n.4, p277-288" />
<format target="http://mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf"
type="PDF" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:43:08 |