Network Working Group S. Daniel Park
Internet-Draft SAMSUNG Electronics
Expires: September 12, 2005 S. Sivakumar
Cisco
P. Srisuresh
Caymas Systems
March 13, 2005
Scalable NAT-PT Solution
draft-daniel-scalable-natpt-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 July 19, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document provides scalability extension to NAT-PT. The extension
is based on the use of DNS-ALG and exchange of load metrics amongst a
cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT.
mNAT-PT is valuable in connecting large V6 domains to legacy V4
domain.
1. Introduction
In order to widely deploy IPv6 network, V4/V6 transition mechanisms
are essential. NAT-PT and TRT transition solutions are proposed for
enable connectivity between IPv6-only and IPv4 networks. However,
both these solutions have limitations for large size V6 networks.
This draft focuses on scaling extensions for traditional NAT-PT.
Specifically, a method to permit outbound sessions for IPv6
hosts in a large IPv6-only domain to the legacy IPv4 domain using
multiple mNAT-PT translators.
2. Scaling Considerations
The NAT-PT solution defined in [NATPT] does not address scalability
issue. Although TRT [TRT] considered scaling, it mandates
reconfiguration of existing systems such as host and DNS-server by
the network administrator. This may not be feasible or desirable in
many circumstances, especially when the V6 domain is constituted
of mobile nodes. In this document, we propose mNAT-PT as an
efficient scalable solution to address such environments. Unlike
TRT, mNAT-PT will not mandate changes to existing end-nodes.
3. Terminology
The following terminology is used throughout the document.
o NAT-PT device A device that implements traditional
NAT-PT function as described in [NATPT].
o mNAT-PT function Stands for "Multiple NAT-PT". mNAT-PT
function makes use of NAT-PT, DNS-ALG
and real-time load monitoring functions
to scale NAT-PT function to multiple
NAT-PT devices.
o mNAT-PT device A device that implements mNAT-PT function.
o Address Pool IPv4 addresses to translate between IPv6
and IPv4 realms.
o Mapping Table Mapping between IPv4 and IPv6 addresses
in the NAT-PT (or) mNAT-PT device.
o Load threshold This is an upper ceiling of NAT BINDings
configured for a given mNAT-PT device.
When a mNAT-PT device reaches the
threshold, the mNAT-PT device attempts to
assign a different mNAT-PT device for new
sessions crossing the realms.
o ALG Application layer gateway.
o DNS-ALG DNS Application layer gateway, as
described in [NATPT].
4. V4/V6 topology with a single NAT-PT device
+--------------------------------+ +-----------------+
| | | |
| IPv6 domain | | |
| | | |
| [IPv6-only host]----------[NAT-PT]--------| IPv4 domain |
| . | | | |
| . | | | |
| | | | |
| [DNSv6 Server] | | |
| | | |
+--------------------------------+ +-----------------+
Figure 1 : single NAT-PT topology
As described in figure 1 above, IPv6-only hosts in the IPv6 domain
are translated into IPv4 address by the NAT-PT device. NAT-PT is
listed as the default router in IPv6 network. Also, there may be a
DNSv6 Server within the IPv6 domain. The above solution cannot
scale to support large no. of V6 hosts.
5. V4/v6 topology with multiple mNAT-PT devices
With growing deployment of IPv6-only networks, a single NAT-PT
will not be able to scale. Support for large number of mobile
users is a requirement in a 3GPP mobile network. We propose
deploying multiple mNAT-PT devices on the border of the IPv6
domain as described below in figure 2. Each mNAT-PT device
will perform NAT-PT function, host one or more unique IPv6
prefixes and advertise the prefixes within the IPv6 domain.
+------------------------------+ +----------------+
| | | |
| IPv6 domain | | |
| | | |
| [IPv6-only host]--------[mNAT-PT]--------| |
| . | | | |
| . | | | |
| | | | |
| [DNSv6 Server] | | |
| | | | IPv4 domain |
| [IPv6-only host]--------[mNAT-PT]--------| |
| . | | | |
| . | | | |
| [IPv6-only host]--------[mNAT-PT]--------| |
| . . | |
| . . | |
| . | | |
+------------------------------+ +----------------+
Figure 2 : mNAT-PT topology
6. Method of operation for mNAT-PT devices
The following layout describes how mNAT-PT function may be
accomplished with the aid of DNS-ALG and Cluster Load-Monitor
as an extension to NAT-PT function.
+----------------+
| DNS-ALG |
| |
+-----+--------+-------+-----+---------+
| | Traditional |Interface|
| Cluster-wide | NAT-PT | to | ______[IPv4 Domain]
| Load Monitor | function | IPv4 |___\
| | |network |
+----------------------------+--------+
| Interface to IPv6-network |
+----------------------------+
|
|/|
|
|
[IPv6 domain]
Figure 3 : mNAT-PT functional framework
A cluster of mNAT-PT devices may be configured to provide a scalable
mNAT-PT solution to large V6 networks. All member nodes within a
mNAT-PT cluster carry the same Cluster Identifier (ClusterId). The
Load-Monitor entity within each mNAT-PT is responsible for relaying
the real-time load on the hosting mNAT-PT periodically and in turn,
collecting the load from member nodes within the cluster. The
Load-monitor supplies real-time up-uo-date load data of member
nodes to the DNS-ALG.
The NAT-PT entity is required to invoke DNS-ALG for all DNS queries
and responses traversing the domains. While processing the DNS
response, the DNS-ALG will use load on member nodes as the basis to
assign a IPv6 prefix in the AAAA response to the V6-node that
originated the DNS query. The IPv6 prefix assignment will be based
on the load on the mNAT-PT node associated with the prefix.
6.1. Load-monitor and Communication amongst mNAT-PT cluster members
The following assumptions are made throughout the document. A few
of these assumptions may be changed to suit specific deployment
scenarios.
* Communication amongst the cluster members may take place
within the IPv6 domain.
* It is assumed that each of the mNAT-PT member nodes have
non-conflicting address maps and host a IP-v6 prefix that
is also non-conflicting.
* This document uses NAT-BINDing load on member nodes as the
criteria for determining which of the mNAT-PT devices is
assigned to carry out a NAT-PT translation. However, load
need not be the criteria or the only criteria to make the
device selection. There may be other criteria or policies
that decide the right mNAT-PT device.
* The document assumes that all mNAT-PT devices equal access
to all V4 routes in the V4 domain. This need not be the
case. In such a case, the mNAT-PT devices must either
setup V4-over-V6 VPNs between themselves so this is
ensured (or) exchange the V4 route reachability between
themselves so the right prefix is assigned based on route
reachability. The former is the preffered and recommended
choice.
* The document assumes that the Cluster-ID,
Cluster-controller and member nodes within a cluster are
preconfigured on the mNAT-PT device. Dynamic discovery of
Cluster members is out of the scope of this document.
Election of initial or subsequent cluster controller is
also outside the scope of this document. Cluster
controller is assumed to be the first node of the cluster
to come up. A cluster controller is required to be alive
throughout the duration of the cluster.
* The document assumes there exists a V6 path for any of
the V6-only hosts to reach any of the mNAT-PT devices.
* Lastly, [NIQ] does not seem like the right choice for
cluster communication. Cluster communication requires
reliable point-to-point data communication (say, TCP
based sessions to a well-knwon port) and reliable
point-to-multipoint communication. The document does
not address the transport or message formats used for
cluster communication at this time.
* The communication amongst mNAT-PT cluster memebers
devices should be properly authenticated to avoid any
malicious devices trying to add a IPv6 prefix in the
active list and thereby causing the traffic to be
directed to the malicious device.
An mNAT-PT node joins the cluster by sending a message with
the following mNAT-PT configuration data to Cluster controller.
The cluster controller, in turn, accepts the node into cluster
by sending the existing cluster membership info, Load-data
polling duration and mNAT-PT configuration for each of the
member nodes. The periodic load-data update will also be used
to validate the liveness of a memeber node. Alternately,
member nodes may terminate their memebership by explicitly
sendign a termination message to the cluster controller.
- The Cluster ID
- Hosted IP-V6 Prefix
- NAT-PT address map configuration
- BINDings threshold limit
Further to joining the cluster, the mNAT-PT nodes report their
load-data to the cluster controller periodically. The load-data is
essentially the count of active NAT-PT BINDings at the time of
reporting.
6.2. Redirection using DNS-ALG
Each mNAT-PT must be configured with a threshold of NAT BINDings
and one or more IP-v6 prefixes (as desccribed in the previous
section) in advance. The DNS-ALG is supplied with this information
from the Load-Monitor.
Typically, all the communications between a IPv4 device and IPv6
device starts with a DNS request. DNS-ALG receives the DNS request and
converts the A query to a AAAA query and vice versa. When the DNS-ALG
receives the reply then it will decide which IPv6 prefix to use to
translate the IPv4 address. If the load on the hosting mNAT-PT is
within threshold configured for the node, then the prefix assigned
to the host mNAT-PT is included in the DNS response. Otherwise,
DNS-ALG will select a member node with the least percentage of load
utilization vis-a-vis the threshold setting.
7. Security Considerations
Cluster communication between cooperatign mNAT-PT devices must be
authenticated so that sessions are not hijacked by a rogue node
that pretends to be a member mNAT-PT device.
Authors' Addresses
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics
416, Maetan-3dong, Yeongtong-gu
Suwon, KOREA
Email:soohong.park@samsung.com
Senthil Sivakumar
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA 95134, US
Email: ssenthil@cisco.com
Pyda Srisuresh
Caymas Systems, Inc
1179-A North McDowell Blvd.
petaluma, CA 94954
USA
Email: srisuresh@yahoo.com
References
[Trans] Gilligan, R. and E. Nordmark, "Transition Mechanisms
for IPv6 Hosts and Routers", RFC 1933, April 1996.
[NATPT] Tsirtsis G. and P. Srisuresh "Network Address
Translation-Protocol Translation(NAT-PT)", RFC 2766,
February 2000.
[DSTM] Bound, J, et al. "Dual Stack Transition Mechanism
(DSTM)" draft-ietf-ngtrans-dstm-08.txt.
[TRT] J.Hagino, K.Yamamoto, "An IPv6-to-IPv4 Transport Relay
Translator", RFC 3142, June 2001.
[DNSALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
Heffernan, "DNS extensions to Network Address
Translators(DNS_ALG)", RFC 2694, September 1999.
[NDP] Narten, T, Nordmark, E, Simpson, W "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ISSUE] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766"
Internet-Draft, January 2003, work in progress.
[NIQ] Crawford, M, "IPv6 Node Information Queries", Internet-
Draft, May 2002, work in progress.
[IPV6] Deering, S, Hinden, R, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December, 1998.
[LINK] Hinden, R, et. al. "An IPv6 Aggregatable Global Unicast
Address Format", RFC 2374, July 1998.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.