BEHAVE WG D. Liu D. Liu H. Deng
Internet-Draft H. Deng
Intended status: Standard Track China Mobile
Expires: September 8, 2010 March 7, 2010
NAT46 considerations
draft-liu-behave-nat46-02
Abstract
The period of IPv4/IPv6 transisation will last for a long time.
Different phases of IPv4/IPv6 transisation have different scenarioes
and requirements thus need different solutions. In the early stage
of IPv4/IPv6 transisation, sicne the majority of the Internet
resources locate in the IPv4 Internet, the main communication type of
the IPv4/IPv6 transition is v6 to v4 which is the IPv6 clients iniate
communication to the IPv4 servers. At the later stage of the IPv4/
IPv6 transisation, the servers may locate in the IPv6 network/
Internet, in this scenario, there is a need for the legacy IPv4
client to iniate communication to the IPv6 servers. This document
analyses the problems of v4 to v6 communication and discusses a
solution called PNAT-Lite.
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 September 8, 2010.
Copyright Notice
Liu Expires September 8, 2010 [Page 1]
Internet-Draft NAT46 consideration March 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. 4. DNS46 consideration . . . . . . . . . . . . . . . . . . . . 7
5. 5. NAT46 GW consideration . . . . . . . . . . . . . . . . . . 9
6. 6. ALG consideration . . . . . . . . . . . . . . . . . . . . . 10
7. 7. NAT46 solution . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Liu Expires September 8, 2010 [Page 2]
Internet-Draft NAT46 consideration March 2010
1. Introduction
+------------------------------------------------------+
| |
| |
| +----------------+ +---------------+ |
| | IPv4 Network | |IPv6 Internet | |
| | +-----------+ | +-----------+ | +-----------+ | |
| | | |--|--|Translation|--|-| | | |
| | |IPv4 Client| | | Box | | |IPv6 Server| | |
| | +-----------+ | +-----------+ | +-----------+ | |
| | | | | |
| +----------------+ +---------------+ |
| | | |
| DNS DNS |
| |
| |
+------------------------------------------------------+
Figure 1 NAT46: v4 to v6 communication scenario.
As figure 1 illustrated, in v4 to v6 communication scenario, the IPv4
client which locates in the IPv4 network initiates communication to
the IPv6 server which locates in the IPv6 Internet.
To enable the v4 to v6 communication, a v4 to v6 translation entity
need to be involved. As figure 1 illustrated, a translation box is
introduced between the IPv4/IPv6 network which performs IPv4/IPv6
packets translation. To enable the v4 to v6 communication, it is
also need to do v6 to v4 address mapping and handle the DNS query and
response. As will be discussed in section 4, there are several
different ways to implement it.
Although there are different ways for implementation, the basic
function module of v4 v6 translation should inlclude:
1) DNS handling:
Used to handle DNS query and response. The IPv4 application may send
type A DNS query to start the communication, but since the server is
IPv6 server and may have no type A DNS record, there will be no type
A DNS response returned. The DNS handling module is then used to
solve this problem. It may send both type A and AAAA DNS queries on
behalf of the IPv4 application and return the proper DNS response to
the application.
2) Address mapping
Liu Expires September 8, 2010 [Page 3]
Internet-Draft NAT46 consideration March 2010
Address mapping module is used to create and maintain the IPv4 and
IPv6 address mapping. Since the IPv4 application can only start
communication using IPv4 address as destination IP addrss, there is a
need to use an IPv4 address to represent the IPv6 server's address.
This mapping normally is created dynamically on demand. The
translation box need to use this mapping information for IPv4/IPv6
packet translation.
3) v4 v6 translation
The translation module performs the IPv4 IPv6 packets translation.
The translation module may need the mapping information to perform
the translation, so the mapping information and translation module
need to be synchronized. The translation may perform based on SIIT
[RFC2765].
Liu Expires September 8, 2010 [Page 4]
Internet-Draft NAT46 consideration March 2010
2. Conventions used in this document
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].
Liu Expires September 8, 2010 [Page 5]
Internet-Draft NAT46 consideration March 2010
3. Terminology
NAT46 GW: NAT46 gateway, refer to the entity that performs the IPv4/
IPv6 translation.
Mapped-IPv4 address: Refers to the dynamically created IPv4 address
that maps to the server's IPv6 address. This mapping information
need to be synchronized with the NAT46 GW.
Liu Expires September 8, 2010 [Page 6]
Internet-Draft NAT46 consideration March 2010
4. DNS46 consideration
The DNS handling and IPv4/IPv6 address mapping function together
could be recognised as DNS46 ALG.
There are different approaches to implement DNS46 ALG: in translation
box, in DNS system, and in host.
1) Translation box (NAT46 GW) performs DNS46 ALG.
In this approach, the IPv4 application's type A DNS query message
will arrive at the NAT46 GW, the NAT46 GW translates it into IPv6
packet and change type A to AAAA. If the DNS system returns AAAA
response, the NAT46 GW will translate the IPv6 DNS response packet
into IPv4 and create a mapping of the AAAA record and a mapped-IPv4
address of the server then return to the IPv4 host a A record which
contains the mapped-IPv4 address. The IPv4 client will use the
mapped-IPv4 address as the IPv6 server's IP address to start the
communication.
2) DNS46 performs DNS46 ALG.
In this approach, there will be a DNS46 server in the network and
performs the DNS46 ALG. The IPv4 client's type A DNS query will
arrive at the DNS46 server, the DNS46 server will perform type A
query, if there is no response, DNS46 will perform type AAAA query.
If there is a type AAAA DNS response, DNS46 will create a mapping
between the returned IPv6 address and a dynamically generated IPv4
address. Then DNS46 will return the mapped type A DNS response
message to the IPv4 client. The DNS46 needs to synchronize this
mapping information to the NAT46 GW. The IPv4 client will then use
this mapped-IPv4 address to initiate the communication.
3) Host performs DNS46 ALG.
In this approach, the DNS46 ALG function resides in the host. The
IPv4 application in the IPv4 client send type A DNS query. The DNS46
ALG function in the host sends both type A and AAAA DNS query, when a
type AAAA DNS response is received, the DNS46 ALG function in the
host create a mapping between the IPv6 address of the server and a
dynamically created mapped-IPv4 address. If the IPv4/IPv6
translation function resides in the host, the DNS46 function could
synchronize the mapping information using internal implementation
specific mechanism.Otherwise, an external synchronization mechanism
is needed.
The three different approaches have their own advantages and
disadvantages:
Liu Expires September 8, 2010 [Page 7]
Internet-Draft NAT46 consideration March 2010
For the approach that performs DNS46 ALG in NAT46 GW, the main
disadvantage is that it will add complexity to the NAT46 GW. The
advantage of this approach is that there is no synchronization
mechanism needed and no need to change the host and DNS system. The
DNS46 approach's main advantage is that it reduces the complexity of
the NAT46 GW and no change to the host. The disadvantage of this
approach is that it needs to introduce new DNS entity (DNS46) and
need to synchronize the IPv6-IPv4 mapping information between the
NAT46 GW and DNS46. The advantage of host based DNS46 ALG approach
is that it reduces the complexity of the NAT46 GW and no need to
change of DNS system. The main disadvantage of this approach is that
it requires changes to the host.
There already have some proposals that try to solve the v4 v6
communication problem: Virtual IPv6 connection[ID-Virual IP] and
soure IP NAT[ID-Source NAT]. Virtual IPv6 connection is based on the
DNS system to perform DNS46 function. Specifically, in virtual IPv6
connection, the recursive DNS server requests the translation box to
create the mapping information and then return the created A record
to the application. Source IP NAT is also a DNS based solution. It
uses flow information to identify the mapping record and thence allow
each IPv4 address be used in multiple distinct communications.
NAT-PT is a solution that using the translation box to performs DNS46
ALG function. But since NAT-PT's DNS46 ALG has many issues and
limitations as discussed in RFC4966[RFC4966], the NAT-PT
specification was abolished.
Liu Expires September 8, 2010 [Page 8]
Internet-Draft NAT46 consideration March 2010
5. NAT46 GW consideration
NAT46 GW performs the translation function between IPv4 and IPv6.
The NAT46 GW gets the mapping information of the server's IPv6
address and mapped-IPv4 address by DNS46 ALG function which either
resides in NAT46 GW, DNS46 or in the host. The IPv4 packets with the
mapped-IPv4 address as its destination address will be routed to the
NAT46 GW. The NAT46 GW will first query its mapping table to see
whether there is a mapping entry of this IPv4 address exist. When a
mapping entry is found, the NAT46 GW will translate the IPv4
destination address to its corresponding IPv6 destination address.
The IPv4 source address could be translated by adding a NAT46 GW
prefix.
Liu Expires September 8, 2010 [Page 9]
Internet-Draft NAT46 consideration March 2010
6. ALG consideration
When there is an IP address embedded in the payload, it will require
the NAT46 GW to perform translation of the embedded IP address.
NAT46 GW should support the most crucial legacy application's ALG.
It would not require the NAT46 GW to support all the ALGs due to the
scalability and complexity restriction.
Liu Expires September 8, 2010 [Page 10]
Internet-Draft NAT46 consideration March 2010
7. NAT46 solution
This section discusses a NAT46 solution which implement Extened Name
Resolver(ENR) and address mapping function in the translation box.
There is no external synchronization mechanism needed since the
address mapping and translation function resides in the same box.(as
illustrated by figure 2)
+----------------------------------------------------------------+
| |
| |
| +----------------+ +---------------+ |
| | IPv4 Network | Translation box |IPv6 Internet | |
| | +-----------+ | +--------------------+ |+------------+ | |
| | | |--|--|+---+ +------------+| || | | |
| | | | ||ENR| |Addr Mapping||--||IPv6 Server | | |
| | |IPv4 Client| | |+---+ +------------+| || | | |
| | +-----------+ | +--------------------+ |+------------+ | |
| | | | | |
| +----------------+ +---------------+ |
| | | |
| DNS DNS |
| |
| |
+----------------------------------------------------------------+
Figure 2 ENR based NAT46 solution
The ENR module works as follows:
1)The IPv4 application send type A DNS query. The IPv4 client may be
configured to use the Translation box as its DNS server.
2)The type A DNS query is routed to the ENR module of the translation
box, the ENR module will then send both type A and AAAA queries to
the DNS system using its IPv4 interface.
3)The DNS system may return an A or an AAAA or both A and AAAA record
according to the server's IP version.
4)The ENR module decide what DNS response message it will send to the
IPv4 client based on network connection type towards the IPv6
Internet and the returned DNS message. Table 1 illustrated the
detail operation of ENR:
Liu Expires September 8, 2010 [Page 11]
Internet-Draft NAT46 consideration March 2010
+---------+------+--------+-----------+---------+
| S. App. | Net. | Peer | ENR resp. | Fun. Map|
| Query | Type | Type | to App. | /Trans. |
+---------+------+--------+-----------+---------+
| A | * | A | A | no need |
| A | * | A/AAAA | A | no need |
| A | v6 | AAAA | Mapping A | v4-v6 |
| A | v4v6 | AAAA | Mapping A | v4-v6 |
+---------+------+--------+-----------+---------+
Table 1: ENR function based on network type
As table 1 illustrated, ENR function could perform intelligent DNS
handling based on the current connection type. Here Net.Type is the
translation box's network connection type towards the IPv6 Internet.
In the case that v6 to v4 mapping is needed, ENR module requests the
address mapping module to create a mapped-IPv4 address for the
server's IPv6 address. The ENR module will then return an A record
which contains the mapped-IPv4 address. The IPv4 client will use
this mapped-IPv4 address as the destination address of the server to
start communication.
Liu Expires September 8, 2010 [Page 12]
Internet-Draft NAT46 consideration March 2010
8. Security Considerations
TBD
Liu Expires September 8, 2010 [Page 13]
Internet-Draft NAT46 consideration March 2010
9. IANA Considerations
None
Liu Expires September 8, 2010 [Page 14]
Internet-Draft NAT46 consideration March 2010
10. Contributors
Zhen Cao
China Mobile
caozhen@chinamobile.com
Bo Zhou
China Mobile
zhouboyj@chinamobile.com
Liu Expires September 8, 2010 [Page 15]
Internet-Draft NAT46 consideration March 2010
11.References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ID-Virual IP] Christian Vogt,"Virtual IPv6 Connectivity for IPv4-Only
Networks", 2009
[ID-Source NAT] C. Perkins, "Translating IPv4 to IPv6 based on source
IPv4 address", 2009
[RFC2765] Nordmark,E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[RFC4966] C.Aoun, "Reasons to Move the Network Address Translator - Protocol
Translator(NAT-PT) to Historic Status", 2007
Liu Expires September 8, 2010 [Page 16]
Internet-Draft NAT46 consideration March 2010
Author's Address
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Hui Deng
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: denghui@chinamobile.com
Liu Expires September 8, 2010 [Page 17]