Network Working Group Y. Cui
Internet-Draft M. Xu
Intended status: Standards Track S. Wang
Expires: April 4, 2010 X. Li
J. Wu
Tsinghua University
C. Metz
Cisco systems
Oct. 2009
PET for IPv6 to IPv4 communication
draft-cui-softwire-pet64-00.txt
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 February 28, 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.
Cui, et al. Expires April 4, 2010 [Page 1]
Internet-Draft pet64 Oct. 2009
Abstract
This draft offers a solution using PET for the scenario that an IPv6-
only client initiates a communication to an IPv4-only server through
IPv6 backbone. In this communication scenario,translation is needed.
However, translation work has requirements on the performance
(hardware or software) of PET and the size of network that the PET is
charge for. This draft introduces the concept of translation
preference to express the PET's willing of performing translation
according to some policies the network administrators constitute.
Through exchanging the Translation preference among PETs, PET
framework can decide which PET should act as a translator. In
addition, this draft also gives how the PET collaborates with DNS to
solve the IPv6-to-IPv4 communication problem.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. PET Framework in IPv6-toIPv4 communication scenario . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IPv6-to-IPv4 communication in PET framework . . . . . . . . . 7
4.1. IPv6-to-IPv4 communication scenario . . . . . . . . . . . 7
4.2. IPv6-to-IPv4 communication using PETs . . . . . . . . . . 8
4.3. PET and DNS collaboration for IPv6-to-IPv4
communication . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. PET1 Translation scenario . . . . . . . . . . . . . . 10
4.3.2. PET2 Translation scenario . . . . . . . . . . . . . . 11
4.4. Other considerations . . . . . . . . . . . . . . . . . . . 12
5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Cui, et al. Expires April 4, 2010 [Page 2]
Internet-Draft pet64 Oct. 2009
1. Introduction
IPv6 offers significant advantages over IPv4, however it will take a
long time to replace IPv4 with IPv6. Therefore, these two protocols
are expected to coexist during the transition period.
On one hand, because it is difficult to update IPv4 applications, a
lot of IPv6-only client will want to visit IPv4-only servers to enjoy
the IPv4 applications. On the other hand, to promote the transition
from IPv4 and to propel IPv6 development, some countries are
establishing large-scale pure IPv6 backbone networks. So it is a key
problem that an IPv6 client dwelled in an IPv6 network can
efficiently communicate with an IPv4 server dwelled in an IPv4
network through IPv6 backbone.
This draft proposes a solution that using PET framework
[I-D.draft-cui-softwire-PET-framework-00]to solve the problem that an
IPv6-only client initiates a communication to an IPv4-only server
through IPv6 backbone (we call this communication scenario is IPv6-
to-IPv4 in the following draft).
In IPv6-to-IPv4 communication scenario, translation is inevitably
adopted. Hence, which PET should act as a translator is a key
problem to be considered. The reason is described as follows:
Translation mechanism usually needs application level gateway (ALG),
which is an application specific agent that allows an IPv6 host to
communicate with an IPv4 host and vice versa. However, it is hard to
use hardware to do the work of ALG. Thus, translation has
requirements on the performance (including hardware performance and
software performance) of PET and the network size the PET charges
for. Usually, if a PET's performance is higher and the network's
size which the PET charges for is smaller, the PET is supposed to
perform translation, and vice versa.
In this draft, we firstly give the PET framework in IPv6-to-IPv4
communication scenario, based on which this draft discusses two
communication modes in 6to4 scenario(different PET perform
translation in different modes). This draft introduces the concept
of translation preference to express the PET's willing of performing
translation according to some policies the network administrators
constitute. Through exchanging the Translation preference among
PETs, PET framework can decide the communication mode. In addition,
this draft also gives how the PET collaborates with DNS to solve the
IPv6-to-IPv4 communication problem. At last, this draft describes
the filtering of PET.
Cui, et al. Expires April 4, 2010 [Page 3]
Internet-Draft pet64 Oct. 2009
2. PET Framework in IPv6-toIPv4 communication scenario
Figure 1 shows the PET framework in IPv6-to-IPv4 scenario, which uses
PET boxes between IPv6 backbone and its client networks. The client
networks include IPv4 network, IPv4 virtual private networks (VPNs),
IPv6 network and dual stack networks. In this draft, we only
consider the scenario that one PET is charge of one client network.
The scenario that Multiple PETs charge for one client network is out
of consideration.
+------------------+
| |
| IPv6 network |
| |
+------------------+
|
+-----------+
| PET |
| |
+-----------+
|
+-----------------------------+
| |
+--------+ +--------+ +--------+ +-------+
| IPv6 | | | IPv6 backbone | | | IPv4 |
|network |___| PET | | PET |__|network|
| | | | | | | |
| | +--------+ +--------+ | |
+--------+ | | +-------+
+-----------------------------+
|
+-----------+
| PET |
| |
+-----------+
|
+------------------+
| |
| IPv4 network |
| |
+------------------+
Figure 1: PET Framework in IPv6-to-IPv4 scenario
Cui, et al. Expires April 4, 2010 [Page 4]
Internet-Draft pet64 Oct. 2009
3. Terminology
This section provides the definitions for all the terms used in
draft.
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 RFC 2119 [RFC2119].
The following terms are used in this document:
PET: a smart transition toolbox supporting IPv4/IPv6 inter-working.
PET toolbox has the following functions:
P: representing prefixing. Prefixing includes all transition
operations of control plane involved with subnet prefix.
E: representing encapsulation. E includes all tunneling operations
of data plane, such as encapsulation, decapsulation and maximum
transmission unit (MTU) processing and so on.
T: representing translation. It includes all translation operations
of data plane, such as address mapping and protocol translation, MTU
processing.
A PET connects the IPv6 backbone to its client networks. It is a
dual stack gateway. PETs can exchange their prefixes and Translation
Preferences through softwire signaling [RFC 5565].When collaborating
with DNSs, a PET charging for an IPv4 network MUST keep one-to-one
mapping between the DNS's IPv4 address and its IPv6 mapping address.
Translation Preference (TP): is a value set in a PET to show the
preference degree that the PET would like to translate a packet. The
higher is the TP, the higher probability that the PET translates
packets.
PET prefix: a prefix of a network which a PET is charge for. Through
PET prefix, an IPv6 PET address is constructed. PET prefixes should
be announced by PETs through softwire signaling [RFC 5565], based on
that other PETs can differentiate an IPv6 PET address and a regular
IPv6 address and judge where a packet comes from or is destined to.
IPv6 PET address: an IPv6 address constructed by concatenating the
/96 prefix of the PET that is charging for the IPv4 network and the
IPv4 address assigned to the IPv4 server.
IPv6 mapping address: the IPv6 address representing the IPv4 target.
In IPv6-to-IPv4 scenario, an IPv4 target's IPv6 mapping address is
Cui, et al. Expires April 4, 2010 [Page 5]
Internet-Draft pet64 Oct. 2009
its IPv6 PET address.
IPv4 mapping address: the IPv4 address representing the IPv6 target.
DNS4: a DNS deployed in IPv4 network. It has an IPv6 mapping
address. DNS4 SHOULD support for DNSSEC and some forms of IPsec. A
DNS4 SHOULD keep the DNS6's IPv4 mapping addresses. This information
MAY be set by static configuration.
DNS6: a DNS deployed in an IPv6 network (including IPv6 backbone and
IPv6 client networks). DNS6 SHOULD support for DNSSEC and some forms
of IPsec.It has an IPv4 mapping address. A DNS4 SHOULD keep the
DNS6's IPv4 mapping addresses. This information MAY be set by static
configuration.
Cui, et al. Expires April 4, 2010 [Page 6]
Internet-Draft pet64 Oct. 2009
4. IPv6-to-IPv4 communication in PET framework
4.1. IPv6-to-IPv4 communication scenario
Figure 2 shows one kind of IPv6-to-IPv4 communication scenario. A
PET connects the IPv6 backbone to its client network, along with the
deployment of a DNS6 in the IPv6 client network and a DNS4 in the
IPv4 client network.
+---------------+ +---------------+ +---------------+
| IPv6 network | +-----+ | | +-----+ |IPv4 network |
| +------+ |_| PET1|_| IPv6 core |_| PET2|_| +------+ |
| | DNS6 | +-----+ | network | +-----+ | | DNS4 | |
| +------+ | | | | +------+ |
+---------------+ +---------------+ +---------------+
Figure 2: IPv6-to-IPv4 communication scenario (DNS6 deployed in
client network
Figure 3 shows the other kind of IPv6-to-IPv4 communication scenario.
A PET connects the IPv6 backbone to its client network, along with
the deployment of a DNS6 in the IPv6 backbones and a DNS4 in the IPv4
client network.
Of course, there can be multiple DNSs in the client networks though
we only discuss the scenario that one DNS deployed in one client
network.
+---------------+ +---------------+ +---------------+
| IPv6 network | | IPv6 core | | IPv4 network |
| | +-----+ | network | +------+ | |
| |_| PET1|_| +------+ |_| PET2 |_| +------+ |
| | +-----+ | | DNS6 | | +------+ | | DNS4 | |
| | | +------+ | | +------+ |
+---------------+ +---------------+ +---------------+
Figure 3: IPv6-to-IPv4 communication scenario (DNS6 deployed in core
network)
PET has two interfaces, an IPv4 (IPv6) interface connects to the IPv4
(IPv6) client network, and an IPv6 interface connects to the IPv6
backbone.
Cui, et al. Expires April 4, 2010 [Page 7]
Internet-Draft pet64 Oct. 2009
Each PET should know the existence each other, and they communicate
the following information through softwire signaling:
i) PET prefix. Through PET prefix announcement, PETs can
differentiate an IPv6 PET address and a regular IPv6 address, and
judge where the packet comes from or is destined to.
ii)TP. Through TP announcement, which PET performs translation is
decided.
When collaborating with DNS, a PET charging for an IPv4 network MUST
keep one-to-one mapping between the DNS's IPv4 address and its IPv6
mapping address.
4.2. IPv6-to-IPv4 communication using PETs
When an IPv6 initiator wants to communicate with an IPv4 host,
translation is inevitably adopted. Hence, which PET should act as a
translator is a key problem to be considered. The reason is
described as follows: Translation mechanism usually needs ALG, which
is an application specific agent that allows an IPv6 host to
communicate with an IPv4 host and vice versa. However, it is hard to
use hardware to do the work of ALG. Thus, translation has
requirements on the performance (including hardware performance and
software performance) of PET and the network size the PET charges
for. Usually, if a PET's performance is higher and the network's
size which the PET charges for is smaller, the PET is supposed to
perform translation, and vice versa.
According to the requirements that performing translation on
different PETs, there are two modes of IPv6-to-IPv4 communication
using PETs as shown in Figures 4 and 5 respectively. In the first
mode, when an IPv6 packet arrives at PET 1, it will be translated
into an IPv4 packet and then sent to PET2 using softwire mechanism
(i.e. 4 over 6 method) [RFC 5565] through IPv6 backbone. At last,
this IPv4 packet will be forwarded directly to the IPv4 host in IPv4
client network.
Cui, et al. Expires April 4, 2010 [Page 8]
Internet-Draft pet64 Oct. 2009
+-------------+ +-----+ +--------+ +-----+ +-------------+
|IPv6 client | | PET1| | IPv6 | |PET2 | |IPv4 client |
| network | | | |backbone| | | | network |
+-------------+ +-----+ +--------+ +-----+ +-------------+
| | | |
|-forwarding->| | |
| translation | |
| encap. | |
| |-----tunneling--->| |
| | | |
| | decap. |
| | |------forwarding->|
| | | |
Figure 4: PET1 translation in IPv6-to-IPv4 communication
In the second method, when an IPv6 packet arrives at PET 1, it will
be directly delivered through IPv6 backbone. Once this packet
arrives at PET2, it will be translated in to an IPv4 and then
destined to the target.
+-------------+ +-----+ +--------+ +-----+ +-------------+
|IPv6 client | | PET1| | IPv6 | |PET2 | |IPv4 client |
| network | | | |backbone| | | | network |
+-------------+ +-----+ +--------+ +-----+ +-------------+
| | | |
|-forwarding->| | |
| |----forwarding--->| |
| | translation |
| | |-----forwarding-->|
Figure 5: PET2 translation in IPv6-to-IPv4 communication
4.3. PET and DNS collaboration for IPv6-to-IPv4 communication
IF an IPv6 initiator does not know the IPv6 mapping address of the
IPv4 target, DNS may be need. In this case, PETs should collaborate
with DNSs for IPv6-to-IPv4 communication.
The following subsections introduce how PETs collaborate with DNSs in
each communication mode.
Cui, et al. Expires April 4, 2010 [Page 9]
Internet-Draft pet64 Oct. 2009
4.3.1. PET1 Translation scenario
+---------+ +------+ +-----+ +-----+ +------+ +----------+
|v6network| | DNS6 | | PET1| |PET2 | | DNS4 | |v4network |
| host A | | | | | | | | | | host B |
+---------+ +------+ +-----+ +-----+ +------+ +----------+
|dstv6 addr?>| | | | |
| |---dstv6 addr?---> | | |
| | | |dstv6,v4addr?>| |
| | | |<-IPv4 addr B-| |
| | | prefixPET2::v4B=C | |
| |<---IPv6 addr C----| | |
| save C | | | |
|<IPv6 addr C| | | | |
|-IPv6 pkt/srcport:y ->| | | |
| | translate | | |
| |src:PET1v4/srcport:x| | |
| | dst:B | | |
| | map:A,y,x | | |
| | encap. | | |
| | |tunneling | | |
| | | decap. | |
| | | |-----------IPv4 pkt------->|
Figure 6: PET operations ( translation+forwarding)
In this scenario, if an IPv6 host (i.e. host A) does not know the
IPv6 mapping address of IPv4 target, it will launch a name look up
request for host B, the lookup query is directed to the DNS server on
the V6 network.
In case of DNS6 having no information about the IPv6 mapping address
of IPv4 target, DNS6 forwards the name look up request to DNS4 (the
DNS6 has the IPv6 mapping address of DNS4 beforehand maybe through
static configuration). This name look up request will be intercepted
by PET2. Since host B may have IPv6 and/or IPv4 addresses, PET2
forwards the original AAAA/A6 query to DNS4 unchanged, as well as an
A query for the same host.
If an AAAA/A6 record exists for the destination, this will be
returned to PET2 which will forward it, also unchanged, to the
originating host. If there is an A record for host B, the reply also
returns to the PET 2, which translates the reply, adds the Prefix of
itself (PET prefix) to construct the IPv6 PET address (prefixPET2::
v4B=C) and finally forwards it (IPv6 addr C) to DNS6.
Now host A can use this address like any other IPv6 address and the
DNS6 server can even cache it as long as the PET Prefix does not
Cui, et al. Expires April 4, 2010 [Page 10]
Internet-Draft pet64 Oct. 2009
change.
After getting the IPv6 mapping address, the host A sends a packet to
host B with source port 'y'. When PET 1 receives this packet, it
performs translation and select an unused port 'x' to create the
mapping entry (IPv6 address of host A, source port y and source port
x). After that, PET 1 sends the packet to PET 2 through softwire
mechanism (4over6 tunneling). When PET 2 receive this packet, it
will directly deliver the packet to Host B.
In the opposite direction, when a packet sent by host B arrives at
PET 2, PET2 uses the softwire mechanism to send this packet to PET1.
Because having the mapping information, PET 1 performs translation
and then sends this packet to host A.
The TTL values on all DNS resource records (RRs) passing through PET
SHOULD be set to 0 so that DNS servers/clients do not cache
temporarily assigned RRs. Note, however, that due to some buggy DNS
client implementations a value of 1 might in some cases work better.
The TTL values should be left unchanged for statically mapped.
4.3.2. PET2 Translation scenario
+---------+ +------+ +-----+ +-----+ +------+ +---------+
|v6network| | DNS6 | | PET1| |PET2 | | DNS4 | |v4network|
| host A | | | | | | | | | | host B |
+---------+ +------+ +-----+ +-----+ +------+ +---------+
|dstv6 addr?->| | | | |
| |---dstv6 addr?--->| | |
| | | |dstv6,v4addr?>| |
| | | |<-IPv4 addr B-| |
| | | prefixPET2::v4B=C | |
| |<--IPv6 addr C----| | |
| save C | | | |
|<-IPv6 addr C| | | | |
|--IPv6 pkt/srcport:y ->| | | |
| | | IPv6pkt/srcport:y | |
| | | translate | |
| | | src:PET1v4/srcport:x | |
| | | dst:B | |
| | | map:A,y,x | |
| | | |-------------IPv4 pkt---->|
Figure 7:PET operations in IPv6-IPv6-IPv4 scenario(forwarding
+translation)
In this case, PET 2 performs translation, to that end, PET 2 selects
an unused port 'x' to create the mapping entry (IPv6 address of host
A, source port y and source port x). Such binding state is created
Cui, et al. Expires April 4, 2010 [Page 11]
Internet-Draft pet64 Oct. 2009
when the first packet flowing from the IPv6 network to the IPv4
network is translated. After the binding state has been created,
packets flowing in either direction on that particular flow are
translated.
The other progress is same as that in subsection 4.3.1.
4.4. Other considerations
Address mappings for incoming sessions, as described above, are
subject to denial of service attacks since one can make multiple
queries for nodes residing in the V6 network causing the PETs to map
and thus block legitimate incoming sessions. Thus, address mappings
for incoming sessions should time out to minimize the effect of
denial of service attacks.
In fact, an IPv6 host can learn the address of IPv4 target from the
DNS4 or from the DNS6. In this draft, we learn the idea from NAT64
[draft-ietf-behave-v6v4-xlate-stateful-01] that DNS6 servers maintain
a mapping of names to IPv6 addresses for internal nodes and possibly
cache mappings for some external nodes. In the case where the DNS6
contains the mapping for external IPv4 hosts, the DNS queries will
not cross the IPv6 domain and that would obviate the need for PET
intervention. Otherwise, the queries will cross the IPv6 domain and
are subject to PET intervention. We also learn the idea from NAT64
[draft-ietf-behave-v6v4-xlate-stateful-01] that DNS4 servers cache
name mapping for external nodes (i.e., V4 nodes) only.
For basic functionality, the approach only requires the deployment of
PETs connecting the IPv6 backbone to its client networks, along with
the deployment of a DNS6 in the IPv6 client network and a DNS4 in the
IPv4 client network. However, some advanced features such as support
for DNSSEC validating stub resolvers or support for some IPsec modes,
require software updates to the IPv6-only hosts.
We recommend the time to failure of DNS is no longer than that of
mapping in PETs to guarantee the available of IPv6 mapping address
(i.e. PET address) of IPv4 target.
It is important to note that the translation still works if the IPv6
initiator learns the IPv6 mapping address of IPv4 address (i.e.
Pref64::X) through some schemes other than a DNS look-up. This is
because the DNS processing does NOT result in any state installed in
the PET box and because the IPv6 mapping address is constructed by
concatenating the PET prefix to the original IPv4 address.
Cui, et al. Expires April 4, 2010 [Page 12]
Internet-Draft pet64 Oct. 2009
5. Filtering
Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a
PET box may do filtering, which means it only allows some kinds of
packets through the interface according to the appropriate policies.
Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a
PET may do no filtering, or it may filter on its IPv4 interface.
Filtering on the IPv6 interface is not supported because mappings are
only created by packets traveling in the IPv6 --> IPv4 direction.
Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01],PET
filtering is consistent with the recommendations of RFC 4787
[RFC4787], and the ones of RFC 5382 [RFC5382].
Cui, et al. Expires April 4, 2010 [Page 13]
Internet-Draft pet64 Oct. 2009
6. References
6.1. Normative References
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
6.2. Informative References
[I-D. draft-cui-softwire-PET-framework-00.txt]
Y.Cui,M.Xu,S.Wang, X.Li,J. Wu, C. Metz, "PET-based framework
for IPv4/IPv6 coexistence", July 2, 2009.
[I-D. draft-ietf-behave-v6v4-xlate-stateful-01.txt]
M.Bagnulo, P. Matthews,I. van Beijnum. "NAT64: Network Address
and Protocol Translation from IPv6 Clients to IPv4 Servers",
July 11, 2009.
Cui, et al. Expires April 4, 2010 [Page 14]
Internet-Draft pet64 Oct. 2009
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: cuiyong@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
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
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
Cui, et al. Expires April 4, 2010 [Page 15]
Internet-Draft pet64 Oct. 2009
Jianping Wu
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Chris Metz
Cisco systems
170 West Tasman Drive
San Jose 95134-1706
CA
Email: chmetz@cisco.com
Cui, et al. Expires April 4, 2010 [Page 16]