Network Working Group Y. Cui
Internet-Draft M. Xu
Intended status: Standards Track P. Wu
Expires: September 10, 2010 S. Wang
J. Wu
X. Li
Tsinghua University
C. Metz
Cisco Systems, Inc.
March 9, 2010
IPv4/IPv6 Coexistence Framework (PET)
draft-cui-softwire-pet-02
Abstract
IPv4 and IPv6 are expected to coexist for a long period. Currently,
there are many IPv4/IPv6 transition/coexistence techniques, which can
be roughly divided into two categories: tunneling and translation.
Both tunneling and translation have restricted application scopes,
and translation has some technical limitations. To maximize the
benifits and reduce the costs, we may need to use both tunneling and
translation in some scenarios. Besides, there may be multiple
network devices capable of performing translation/tunneling along the
end-to-end path. It's important to choose the appropriate
device(devices) to execute translation/tunneling.
This draft brings up the method of choosing the appropriate
translation spot to avoid the limitations of translation.
Furthermore, this draft presents an IPv4-IPv6 transition/coexistence
framework named PET (short for Prefixing, Encapsulation and
Translation). PET integrates tunneling and translation to support
both traversing and IPv4-IPv6 interconnection, and uses tunneling and
translation properly to constitute communication modes in different
scenarios. When executing translation, PET achieves translation spot
negotiation through signaling process between PET devices. PET
framework covers most network transition scenarios. It is a generic
solution framework for IPv4-IPv6 coexistence.
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-
Cui, et al. Expires September 10, 2010 [Page 1]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
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 September 10, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Cui, et al. Expires September 10, 2010 [Page 2]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Fundamental elements for IPv4-IPv6 coexistence . . . . . . . . 7
4. PET Framework . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. PET operations on E-IP->I-IP->E-IP . . . . . . . . . . . . 9
4.2. PET operations on E-IP->I-IP->I-IP . . . . . . . . . . . . 10
4.3. PET operations on E-IP->E-IP->I-IP . . . . . . . . . . . . 11
5. PET signaling . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. signaling content . . . . . . . . . . . . . . . . . . . . 13
5.2. PET signaling extension in MP-BGP . . . . . . . . . . . . 14
5.3. BGP protocol behavior with PET signaling . . . . . . . . . 15
6. Implementation issues . . . . . . . . . . . . . . . . . . . . 16
6.1. DNS consideration . . . . . . . . . . . . . . . . . . . . 16
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Cui, et al. Expires September 10, 2010 [Page 3]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
1. Introduction
Recently more and more IPv6 networks have been deployed, especially
IPv6 backbone networks. Howerver the existing IPv4 networks still
carry the major network traffic and hold the major network services
and applications. It has been widely believed that IPv4 and IPv6
networks will coexist for a long term. This leads to the demand for
IPv4-IPv6 coexistence technology.
Till now there are two types of IPv4-IPv6 coexistence techniques:
tunneling and translation. Tunneling can achieve traversing across
incompatible network, by means of encapsulation and decapsulation.
In the scope of IPv4-IPv6 coexistence, tunneling can deal with the
scenario where two IPv4 (IPv6) nodes/networks communicate with each
other across IPv6 (IPv4) network. Examples of tunneling methods
include IP-in-IP tunnel [RFC2893][RFC4213], GRE tunnel [RFC1702],
6to4 tunnel [RFC3056], 6over4 tunnel [RFC2529], softwire transition
technique [RFC5565] and so on. Tunneling can not achieve IPv4-IPv6
interworking. However, tunneling has several advantages: it's highly
transparent and lightweighted, it can be implemented fully by
hardware, and it can keep IPv4 routing and IPv6 routing separated.
On the other hand, translation is used to achieve direct inter-
communication between IPv4 and IPv6 networks, by means of converting
the semantic between IPv4 and IPv6. Examples of translation methods
include SIIT [RFC2765], NAT-PT [RFC2766], BIS [RFC2767], SOCKS64
[RFC3089], BIA [RFC3338], IVI [I-D.xli-behave-ivi] and so on.
Translation can achieve IPv4-IPv6 interworking, but it has
limitations in operation complexity and scalability. To accomplish
correct translation, the following operations are required: address
or (address,port) tuple substitution, MTU discovery, fragmentation
when necessary, IP and ICMP fields translation, ICMP address
substitution in payload, IP/TCP/UDP checksum recomputing and
application layer translation when necessary. It's rather complex
for a per-packet process, especially when per-application application
layer translation is included. When applying stateful translation,
the dynamic mapping of (address, port) tuple should be maintained on
the translation device. The total number of mapping entries is up to
the order of flow number. As to stateless translation, it has to
consume IPv4 addresses to satisfy IPv6 hosts. This is also not
scalable since IPv6 address space is much larger than IPv4 address.
Basic opeartions of stateless translation can be implemented by
hardware, but ALG has to be implemented by software due to the
variety of application protocols. Stateful translation can not be
implemented by hardware.
As described above, translation and tunneling have their respective
limitations and/or application scopes. To maximize the benifits and
Cui, et al. Expires September 10, 2010 [Page 4]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
reduce the costs, we may need to use both tunneling and translation
in some scenarios. Besides, there may be multiple network devices
capable of performing translation/tunneling along the end-to-end
path. It's important to choose the appropriate device(devices) to
execute translation/tunneling, and thus decide the proper methods to
solve transition problems for various transition scenarios. This
draft presents PET framework for IPv4-IPv6 transition and
coexistence. PET includes fundamental elements needed in various
transition scenarios to support both traversing and IPv4-IPv6
interconnection, and uses them properly to constitue communication
modes in different scenarios. PET uses a signaling process to
negotiate the appropriate translation spot in order to avoid the
limitations of translation, and to distribute necessary information
to execute transition mechanisms.
Cui, et al. Expires September 10, 2010 [Page 5]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
2. Terminology
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 [RFC2119].
Cui, et al. Expires September 10, 2010 [Page 6]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
3. Fundamental elements for IPv4-IPv6 coexistence
There are mainly two basic IPv4-IPv6 transition scenarios. One is to
connect several edge networks of the same address family across a
transit network of the other address family, while the other scenario
is to enable host/network of one address family to communicate
directly with host/network of the other address family. We call the
first scenario heterogeneous crossing and the second one
heterogeneous direct-connection. Most IPv4-IPv6 transition scenarios
can be viewed as combination of heterogeneous crossing and direct-
connection. Generally, heterogeneous crossing can be achieved by
tunneling or two-time translation, while heterogeneous direct-
connection can be achieved by translation. Besides, to support
either tunneling or translation, control plane operations like prefix
mapping or prefix announcement are always required. So there are
three fundamental elements needed in IPv4-IPv6 coexistence:
prefixing, encapsulation and translation.
P: prefixing, which includes all the transition operations on control
plane related to subnet prefix.
For tunneling technology, prefixing includes prefix announcement,
tunnel endpoint discovery, tunnel signaling and configuration, et al.
For example, in softwire technology, MP-BGP (Multi-protocol BGP) is
extended to advertise the routing information of E-IP prefix with
I-IP next-hop, and the parameters of tunnel endpoint before data
plane forwarding. Based on prefixing operations, softwire tunnels
can be established. For translation technology, prefixing includes
IPv4-IPv6 address mapping method, prefix configuration and
announcement.
E: encapsulation, which includes all the tunneling operations on data
plane, such as encapsulation, decapsulation, maximum transmission
unit (MTU) processing and so on. Based on these operations, packets
from E-IP network are encapsulated and forwarded across I-IP transit
network to another E-IP network. To support correct forwarding,
prefix advertisement on control plane is required.
T: translation, which includes all the translation operations on data
plane, such as address translation, protocol translation, MTU
processing, et al. Based on address translation, addresses in IP
packets can be translated from IPv4 to IPv6, or vice versa. Protocol
translation is necessary since IPv4 and IPv6 are not directly
compatible. Here, protocol translation includes IP layer translation
and application layer translation. Devices executing translation may
need to collaborate with the domain name system (DNS), since
applications in end hosts use domain name rather than IP address to
visit other hosts a lot.
Cui, et al. Expires September 10, 2010 [Page 7]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
4. PET Framework
PET is a generic solution for IPv4/IPv6 coexistence based on the
three fundamental elements above, supporting both heterogeneous
crossing and direct-connection. Figure 1 shows the topology of PET
framwork. We use E-IP and I-IP instead of the exact IPv4 and IPv6.
Here I-IP can be either IPv4 or IPv6, while E-IP is the other address
family. In this framework, the I-IP transit network in the center is
connected with various types of customer networks including E-IP
transit/client networks, I-IP transit/client networks and dual-stack
networks.
+------------------+
| E-IP (transit) |
| Network |
+------------------+
| |
| |
+-----+ +-----+
+---| PET |-----| PET |---+
| +-----+ +-----+ |
+-------+ | | +---------+
| | +-----+ I-IP transit +-----+ | I-IP |
| E-IP |---| PET | Network | PET |---|(transit)|
|network| +-----+ +-----+ | network |
+-------+ | | +---------+
| +-----+ +-----+ |
+---| PET |-----| PET |---+
+-----+ +-----+
| \ / |
| X |
| / \ |
+-------+ +-------+
| | | Dual- |
| I-IP | | stack |
|Network| |Network|
+-------+ +-------+
Figure 1 PET Framework
The basic idea of PET framework is to deploy PET boxes between the
central I-IP transit network and customer networks (E-IP or I-IP).
PET boxes should support the basic functions for IPv4/IPv6
coexistence, i.e., prefixing, encapsulation and translation. PET
signaling is also an essential part of the framework for multiple PET
boxes to cooperate with each other. Through signaling, PET boxes can
negotiate the particular functions executed on different boxes and
distibute necessary information to support these functions. PET
Cui, et al. Expires September 10, 2010 [Page 8]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
signaling will be analyzed in the next section.
We can extract three typical scenarios from Figure 1:
"E-IP->I-IP->E-IP", "E-IP->I-IP->I-IP" and "E-IP->E-IP->I-IP"(without
the loss in genarality, we assume that host in the first network
initiate the connection). These three cases cover most network
transition scenarios. PET can provide different functions for
different scenarios to ensure network communcation. We will analyze
how PET works in the three typical scenarios in the following
subsections.
4.1. PET operations on E-IP->I-IP->E-IP
This is the scenario where a E-IP network wants to communicate with
another E-IP network across the I-IP transit. There are two methods
PET can adopt to handle this scenario. One is two-time translation
and the other is tunneling. If PET uses two-time translation, a E-IP
packet need to be translated into an I-IP packet by the first
PET(i.e., the I-IP ingress), get delivered through the I-IP transit,
and be translated back into a E-IP packet at the second PET(i.e., the
I-IP egress).
The other method for E-IP->I-IP->E-IP scenario is tunneling. This
requires the I-IP ingress PET to encapsulate the packets and send
them to the I-IP egress PET across I-IP transit. When these packets
arrive at the second PET, they are decapsulated and sent to E-IP
customer network.
Because translation has limitations and brings heavier load, PET
prefers to use tunneling to handle E-IP->I-IP->E-IP scenario. The
operations are shown in Figure 2.
+-------------+ +-------------+ +-------------+ +-------------+
|E-IP customer| | PET | | PET | |E-IP customer|
| network | | | | | | network |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
|---forwarding--->| | |
| encapsulation | |
| | | |
| |-------tunneling--->| |
| | | |
| | decapsulation |
| | |------forwarding->|
| | | |
Figure 2 PET operations in E-IP->I-IP->E-IP scenario
Cui, et al. Expires September 10, 2010 [Page 9]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
4.2. PET operations on E-IP->I-IP->I-IP
This is the scenario where a E-IP customer network wants to
communicate with an I-IP customer network across the I-IP transit.
There are two methods to deal with this scenario. One is translation
plus forwarding (Figure 3). The other is tunneling plus translation
(Figure 4).
In the first method, when a E-IP packet arrives at the first PET(edge
of E-IP and I-IP), it will be translated into an I-IP packet and then
sent through the I-IP transit to the I-IP client network. In the
second method, when a E-IP packet arrives at the first PET, it will
be encapsulated as an I-IP packet, so as to get delivered through the
I-IP transit. Once this packet arrives at the second PET(the other
tunnel endpoint), it will be decapsulated to the original E-IP
packet, then get translated into an I-IP packet and delivered to the
I-IP customer network.
In theory both methods work, and the second method seems more
complicated. However we should notice that translation brings heavy
load and has scalability issue, while tunneling is lightweighted. So
an extra tunnel is actually acceptable. Hence the two related PET
box need a singaling process to negotiate which method to use, in
order to avoid the limitations of translation and maximize the
benefits. In principle, it's better that translation is done by the
PET box whose performance is better, and the network size behind
which is smaller. We'll discuss PET signaling in the next section.
+-------------+ +-------------+ +-------------+ +-------------+
|E-IP customer| | PET | | PET | |I-IP customer|
| network | | | | | | network |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
|---forwarding--->| | |
| translation | |
| | | |
| |-----forwarding---->| |
| | | |
| | | |
| | | |
| | |----forwarding--->|
| | | |
Figure 3 PET operations (A) in E-IP->I-IP->I-IP scenario (Translation
+ Forwarding)
Cui, et al. Expires September 10, 2010 [Page 10]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
+-------------+ +-------------+ +-------------+ +-------------+
|E-IP customer| | PET | | PET | |I-IP customer|
| network | | | | | | network |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
|---forwarding--->| | |
| | | |
| encapsulation | |
| |------tunneling---->| |
| | | |
| | decapsulation |
| | translation |
| | |----forwarding--->|
| | | |
Figure 4 PET operations (B) in E-IP->I-IP->I-IP scenario (Tunneling +
Translation)
4.3. PET operations on E-IP->E-IP->I-IP
This is the scenario where a E-IP customer network wants to
communicate with an I-IP customer network across the E-IP transit.
There are two methods to deal with this scenario. One is forwarding
plus translation. The other is translation plus tunneling.
In the first method, when a E-IP packet arrives at the first PET, it
will be directly delivered to E-IP transit. At the second PET(edge
of E-IP and I-IP), the packet will be translated into an I-IP packet
and forwarded to the I-IP customer network. In the second meothod,
when a E-IP packet arrives at the first PET, it will be translated
into an I-IP packet. Then PET encapsulates it and sends it to the
second PET. When the E-IP packet with the translated I-IP packet as
its payload arrives at the second PET, the I-IP packet will get
decapsulated and sent to the I-IP customer network.
Here both methods works,too. We also require PET signaling to
negotiate which method to adopt.
Cui, et al. Expires September 10, 2010 [Page 11]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
+-------------+ +-------------+ +-------------+ +-------------+
|E-IP customer| | PET | | PET | |I-IP customer|
| network | | | | | | network |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
|---forwarding--->| | |
| | | |
| | | |
| |------forwarding--->| |
| | | |
| | translation |
| | | |
| | |--forwarding----->|
| | | |
Figure 5 PET operations (A) in E-IP->E-IP->I-IP scenario (Forwarding
+ Translation)
+-------------+ +-------------+ +-------------+ +-------------+
|E-IP customer| | PET | | PET | |I-IP customer|
| network | | | | | | network |
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
|---forwarding--->| | |
| translation | |
| encapsulation | |
| |------tunneling---->| |
| | | |
| | | |
| | decapsulation |
| | |--forwarding----->|
| | | |
Figure 6 PET operations (B) in E-IP->E-IP->I-IP scenario (Translation
+ Tunneling)
Cui, et al. Expires September 10, 2010 [Page 12]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
5. PET signaling
5.1. signaling content
We can see from section 4 that we have to adopt translation in some
scenarios while it's clear that translation has performance and
scalability issues. So it's important to ensure that when we have to
perform translation, perform it on an approperate PET box. The
criterion here is, the PET box whose performance is better, and the
PET box the size of network behind which is smaller, is preferred to
do translation. For example, PET box in edge network is preferred to
perform translation than PET box in backbone.
Here we propose a new concept called Translation Preference (TP) to
express the appropriateness of a PET box to perform translation. By
exchanging the Translation preference among PETs, PET framework can
choose the appropriate PET box to perform translation and decide the
appropriate communication modes for corresponding scenarios. TP can
be decided by the performance of PET box, the size of networks behind
PET box, and the administrators' policy. Factors like bandwidth and
traffic volume of the PET box can infer the network size behind it,
and factors like traffic load and the hardware configuration can tell
the performance of the PET box. We require separated TPs for
stateless and stateful translation because they have different
foundations(stateless translation requires IPv6 host to posess IPv4
address). In a mixed scenario, some PET box can't perform stateless
translation like others because IPv6 hosts in its network doesn't
have IPv4 addresses. So we separate the TP signaling of stateless
and stateful translation.
Besides TP, there is another type of information that PETs wants to
exchange. It's the necessary knowledge to execute translation. For
stateless translation it's the mapping prefix, and for stateful
translation it's the address pool PET can use for address mapping.
For example, in an IPv6->PET1->IPv6->PET2->IPv4 scenario, if we use
stateless translation, then PET2 need to tell PET1 the prefix for
IPv4-IPv6 address mapping when PET1 performs the translation; if we
use stateful translation, then PET2 need to tell PET1 the IPv4
addresses PET1 can use for address mapping when PET1 performs the
translation.
There may be some more information PETs need to exchange which we've
not considered yet, we can use the signaling process to achieve it as
long as it's necessary. The signaling process can be done through
MP-BGP with some extensions.
Cui, et al. Expires September 10, 2010 [Page 13]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
5.2. PET signaling extension in MP-BGP
TP exchange can be achieved by BGP capability advertisement in BGP
OPEN stage. We define a new capability called PET Capability to
carry TP value. The Capability Code field is TBD(which indicates PET
signaling capabilities). The Capability Length field is set to 2.
The Capability Value field is defined as:
0 7 15
+------------+------------+
|Stateless TP|Stateful TP |
+------------+------------+
The use and meaning of this field is as follow:
Stateless TP - Translation Preference value for stateless translation
negotiation. The higher the TP value is, the higher probability this
PET performs translation.
Stateful TP - Translation Preference value for stateful translation
negotiation. The higher the TP value is, the higher probability this
PET performs translation.
There are two ways to carry the mapping prefix and the address pool
information in BGP UPDATE message. The first one is using NLRI and
two new SAFIs, and the second one is using a new BGP attribute. In
the first way, we define two new SAFIs, "Stateless Translation SAFI"
and "Stateful Translation SAFI" to represent the situation of
stateless translation and stateful translation in PET. The
MP_REACH_NLRI Attribute with these SAFIs carries the PET information
instead of routing prefixes. With Stateless Translation SAFI, the
NLRI should be an IPv6 prefix used for IPv4-IPv6 tranlation mapping;
with Stateful Translation SAFI, the NLRI should be an IPv4 address
pool for the receiving PET to use. Both the prefix and the address
pool should following the NLRI Encoding format in [RFC4760]. The
value of Stateless Translation SAFI and Stateful Translation SAFI is
TBD by IANA.
In the second way, we define a new BGP Attribute, "Translation
Information Attribute" to carry the mapping prefix and the address
pool. It's an optional transitive attribute and the attribute type
code is TBD by IANA. The value field of this attribute is composed
of a set of Type-Length-Value (TLV) encodings.The TLV is structured
as follows:
Cui, et al. Expires September 10, 2010 [Page 14]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We define two TLVs here, one is SLT_TLV(type code 1) and the other is
SFT_TLV(type code 2). The Length field stands for the total number
of octets in the Value field. The content of the Value field is the
IPv6 mapping prefix for SLT_TLV, and IPv4 address pool for SFT_TLV,
both in NLRI Encoding format. The Translation Information Attribute
should carry at least one TLV in its value field. We may define more
TLVs in the future, if it's necessary.
5.3. BGP protocol behavior with PET signaling
The extensions for PET signaling above is based on BGP, so we require
the PET boxes to run BGP process. In BGP Open stage, they advertise
their TPs in PET Capability to one another. Having received TP from
its peers, every PET box independently decides which one to perform
translation based on these TP values.
If the chosen translation PET box is on IPv4-IPv6 edge, then it'll
perform translation like normal translation mechnisms. Else the
chosen translation PET box isn't on IPv4-IPv6 edge, so the one on
IPv4-IPv6 edge should advertise either the IPv6 mapping prefix or the
IPv4 address pool to the one performing translation, using one of the
two methods above. Besides, a tunnel will be introduced in this
case. If this tunnel is using mechinisms like softwire mesh, then
the corresponding BGP routing process should be triggered. The edge
PET box will advertise the E-IP prefixes to the translation PET box,
and the translation PET box will advertise the mapping address
pool(stateful translation case)/E-IP address prefix of the network
behind it(stateless translation case) to the edge PET box.
Cui, et al. Expires September 10, 2010 [Page 15]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
6. Implementation issues
In this draft, we recommend how to use tunneling and translation
method in each scenario using PET. However, we do not restrict the
specific tunneling and translation technology that PET adopts. It
can be any network transition technology, such as SIIT [RFC2765],
NAT-PT [RFC2766], IVI [I-D.xli-behave-ivi], IP-in-IP tunnel
[RFC2893][RFC4213], GRE tunnel [RFC1702], 6to4 tunnel [RFC3056],
softwire transition technique [RFC5565] and so on. Softwire is
recommended as tunnel technique since it's automatic, network side
and scalable.
6.1. DNS consideration
It's a concern how to make PET collaborate with DNS system. In the
translation schemes already proposed, DNS is usually considered.
Generally speaking the DNS query strategy of these schemes can be
divided into two types. The first method is to build a DNS ALG on
the translation device and make all the DNS queries and replies go
through the device; the second method is to use DNS64 as an extended
DNS server which collaborates with the translation device to do the
DNS translation. The principle of DNS translation in PET is that,
the DNS translation process is binded to the PET box performing the
translation rather than other PET boxes along the path. The DNS
server should cooperate with the PET box and learn information like
mapping perfix from it sometimes.
Cui, et al. Expires September 10, 2010 [Page 16]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
7. IANA considerations
IANA is requested to assign a value from the "BGP Capability Code"
Registry, to be called "PET Capability", with this document as the
reference.
IANA is requested to assign two values from the "Subsequent Address
Family" Registry, in the "Standards Action" range, to be called
"Stateless Translation SAFI" and "Stateful Translation SAFI", with
this document as the reference.
IANA is requested to assign a value from the "BGP Path Attributes"
Registry, to be called "Translation Information Attribute", with this
document as the reference.
Here the assignment of the two new SAFI value and the new BGP
Attribute code can be an either-or choice.
Cui, et al. Expires September 10, 2010 [Page 17]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
8. Acknowledgements
The authors would like to thank Lixia Zhang, Eric Nordmark, Jari
Arkko, Alain Durand and David Ward for their valuable comments on
this draft.
Cui, et al. Expires September 10, 2010 [Page 18]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
9. References
9.1. Normative References
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[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.
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 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.
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
RFC 3338, October 2002.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
Cui, et al. Expires September 10, 2010 [Page 19]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
9.2. Informative References
[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-07
(work in progress), January 2010.
Cui, et al. Expires September 10, 2010 [Page 20]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: cy@csnet1.cs.tsinghua.edu.cn
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: xmw@csnet1.cs.tsinghua.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: weapon@csnet1.cs.tsinghua.edu.cn
Shengling Wang
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: slwang@csnet1.cs.tsinghua.edu.cn
Cui, et al. Expires September 10, 2010 [Page 21]
Internet-Draft PET for IPv4/IPv6 Coexistence March 2010
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: xing@cernet.edu.cn
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: chmetz@cisco.com
Cui, et al. Expires September 10, 2010 [Page 22]