INTERNET-DRAFT S. Daniel Park Expires:October 2003 SAMSUNG Electronics Filename:draft-park-v6ops-multi-natpt-00.txt Senthil Sivakumar Cisco Systems, Inc. April 2003 Scalable mNAT-PT solution Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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. Abstract In order to widely deploy IPv6 only networks a transition mechanism is needed. There are several transition mechanisms defined and many of them have issues with scalability. This draft provides a solution to have a scalable NAT-PT, which is a transition mechanism defined in [NATPT] Park & Sivakumar Expires October 2003 [page 1] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 Table of contents 1. Introduction .............................................. 2 2. Scalability Considerations ................................ 2 3. Terminology ............................................... 3 4. Topology .................................................. 3 5. mNAT-PT ................................................... 4 6. Methods for load balancing on mNAT-PT ..................... 5 6.1 Redirection ............................................... 5 6.2 Redirection Consideration ................................. 8 6.3 Redirection using DNS-ALG ................................. 8 7. mNAT-PT Information Messages .............................. 9 7.1 mNAT-PT Informations ...................................... 10 8. Security Considerations ................................... 10 9. Intellectual Property ..................................... 10 10. Copyright ................................................. 11 11. Acknowledgements .......................................... 11 12. Author's Address .......................................... 12 13. References ................................................ 12 1. Introduction In order to widely deploy IPv6 network, transition mechanisms are essential elements for coexistent network. This draft focuses on the scalability issues for NAT-PT. There are several solutions for communicating between IPv4-only and IPv6-only networks as NAT-PT, TRT and so on, but have some limitations for deployment because of scalability. The translator typically sits in the border between the two different networks and becomes a scalability and performance bottle neck. This draft discusses a method to separate IPv6-only networks using multiple translators called mNAT-PT and load-balancing functions. 2. Scalability Considerations Most of the transition mechanisms defined do not scale to several thousand nodes. This would be a critical requirement for a successful migration of IPv4 to IPv6. NAT-PT solution defined in [NATPT] does not address the scalability issues. Although TRT [TRT] considered about it, existing systems as host and DNS must be reconfigured by administrator. These requirements involves the user to be involved in changing the configuration, which is not feasible in many circumstan- ces. In the near future, various IPv6-only devices or networks will be deployed mainly in Homes and Mobile networks. These devices and networks will require to connect to legacy IPv4-only networks. In this environment, mNAT-PT is an efficient solution to deploy widely which will scale very well. This draft don't change existing system. Park & Sivakumar Expires October 2003 [page 2] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 3. Terminology In order to use Transition Box, some functions must be included. Note that below terminology is considered to mention Transition and TRT. If another mechanism is needed, it'll be added. o NAT-PT - has function as [NATPT]. o mNAT-PT - is multiple NAT-PT which has NAT-PT function and load-balancing functions. o Address Pool - IPv4 addresses to translate between IPv4 and IPv6 o Mapping Table - mapping IPv4 and IPv6 address into Transition Box. 0 Threshold - This value shows Transition capability. It should be defined by administrator. 0 ALG - Application layer gateway. 4. Topology +--------------------------------+ | | | IPv6 network | | | | [IPv6-only host]----------[NAT-PT]----------[IPv4 network] | . | | | . | | | | | | [DNSv6 Server] | | | +--------------------------------+ < Figure 1 : single NAT-PT topology > As above picture, all IPv6-only hosts in IPv6 network must be translated into IPv4 address by NAT-PT because NAT-PT is a default gateway (or router) in IPv6 network. Also DNSv6 Server may stay in Park & Sivakumar Expires October 2003 [page 3] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 IPv6 network for using of Domain Name instead of IPv6 address.The above solution works fine as far the NAT-PT does not have to translate thousands of hosts. However, this would be a requirement in a 3GPP network where thousands of mobile users will need to be supported. 5. mNAT-PT (Multiple NAT-PT) Instead of a single NAT-PT device translating all the traffic there will be multiple NAT-PT devices on the border of the IPv4 and IPv6 networks. (Figure 2). Each NAT-PT device can independently operate as a translator device. Each NAT-PT device will have one or more unique IPv6 prefix that it will advertise the same to the IPv6 network. Generally, IPv6 network in front of NAT-PT is a single subnet. But if depolyment of IPv6-only is growing, the usage of NAT-PT will be increased, because almost all the IPv6-only hosts want to connect IPv4 Internet. In this scenario, a single NAT-PT cannot provide a reliable and scalable solution for transition. Therefore, a more scalable translation solution is needed. The number of participating mNAT-PT devices can be determined by the network administrator and adding a mNAT-PT device to the cluster will be fairly easy. +------------------------------+ | | | IPv6 network | | | | [IPv6-only host]--------[mNAT-PT]--------------[IPv4 network] | . | | | | . | | | | | | | | [DNSv6 Server] | | | | | | | [IPv6-only host]--------[mNAT-PT]---------------------+ | . | | | | . | | | | [IPv6-only host]--------[mNAT-PT]---------------------+ | . . | . . | . . +------------------------------+ < Figure 2 : mNAT-PT topology > Park & Sivakumar Expires October 2003 [page 4] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 6. Methods for load balancing on mNAT-PT Note that for load balancing, mNAT-PT must have its own threshold because of redirection without overloading on mNAT-PT. Accordingly, this value should be defined by administrator in advance. Also mNAT-PT must verify own status by itself and send Redirect Message to IPv6-only hosts if processing is reached threshold. 6.1 Redirection mNAT-PT must be able to determine the link-local address for each of its neighboring mNAT-PT in order to ensure that the target address in a Redirect message identifies the neighbor mNAT-PT by its link- local address. As Neighbor Discovery Protocol is defined, there are two method for sharing next-hop address, for static routing and dynamic routing. See section 7. Note that this draft recommends static routing. For this configuration the next-hop mNAT-PT's address should be specified using the link- local address of the mNAT-PT. There are some methods to check currently status. If new method is considered, it will be discussed and added. o Checking the usage of pool mNAT-PT must have global IPv4 addresses or ports pool for transala- tion. If IPv6-only host tries to access IPv4 network, IPv6 address must be translated IPv4 address in pool and vice versa. Therefore, mNAT-PT can check amount of usage in pool. o Checking the usage of mapping table mNAT-PT must have mapping table between IPv4 and IPv6 address. When each node is translated, these informations are registrated in mapping table, then incoming and outgoing packets are translated by using of mapping table. Therefore, mNAT-PT can check amount of usage in mapping table. Park & Sivakumar Expires October 2003 [page 5] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 o Usage of Redirect Message As it is described in [NDP], NDP can provide redirection function. Generally, routers send Redirect message to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a bette first-hop router. Likewise mNAT-PT can send Redirect message to IPv6-only hosts which are initiated node and want to connect IPv4 network. In order to use this method, mNAT-PT must verify its own capability, in order word, mNAT-PT must recognize its own threshold value because of best performance. e.g. when a mNAT-PT has 80%(this value will be configured by administrator) threshold value, if a threshold is reached up to 80%, this mNAT-PT must send Redirect message to initiated host. Target address in Redirect message will be Neighbor mNAT-PT's address. Note that a host receiving a redirect message sends a subsequent traffic to the specified target NAT-PT. It means the first packet sent from host was reached to original NAT-PT which made mapping information. This section suggests some methods as follows: o Host receiving a Redirect message don't care about previous mapping information in original NAT-PT since original NAT-PT will remove this information because of time-out. o NAT-PT sends a Redirect message with specified flag which indicates that host receiving this Redirect message must initiate to target NAT-PT again. The advantage of having NAT-PT is not to have to change the host. If processing the Redirect message with new flag just like second method, some functions must be implemented host. As consequence, this draft recommend the first method. Park & Sivakumar Expires October 2003 [page 6] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | (redirected NAT-PT address) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | (original NAT-PT address) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- ICMP Fields: Type 137 Code 0 Checksum The ICMP checksum. See [ICMPv6]. M 1-bit mNAT-PT flag. When set, indicates that this flag can be used for re-initiating to host. When a host received this Redirect message is set, host must initiate to target again. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Target Address An IP address that is a better Transition to use for the ICMP Destination Address. Destination Address The IP address of the destination which is redirected to the target. Park & Sivakumar Expires October 2003 [page 7 INTERNET-DRAFT Scalable mNAT-PT solution April 2003 6.2 Redirection Consideration When administraror has more than 2 NAT-PT in IPv6 network, the end- node will have to put up with a lot of thrashing before the node is assigned a NAT-PT, if at all. Ex: Say, a node requests NAT-PT1; then, redirected to NAT-PT2, then redirected to NAT-PT3 etc.. until the node finds one, if at all. There is a problem with the redirection. If administrator has more than 2 NAT-PTs, a NAT-PT cannot know if the V6 request was previously punted several other nodes. It will have to use its state alone to determine who to redirect the packet to next. This solution is to be replaced by DNS-ALG based solution or complemented by DNS ALG solution. The other alternative is to have the NAT-PTs talk to each other and all of them keep track of who is relatively free. In order to exchange state information, new message is discussed in section 7. 6.3 Redirection using DNS-ALG 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. DNS-ALG can make this decision by having a simple round-robin load balancing algorithm or it may have a complex weight based load balancing algorithm that will take into consideration the processing power of the box its current load and others. The administrator can configure the DNS-ALG with all the prefixes of the mNAT-PTs that are in the domain which is called static configuration. The drawback in static configuration is that if one of the mNAT-PT device is not in operating condition DNS-ALG won't be aware of it and hence it might continue to translate the packets using the prefix of that mNAT-PT. This will result in the failure of communication between the clients. o Communication between DNS-ALG and mNAT-PT The preferred approach to the above issue is to have dynamic configurations populated on the DNS-ALG device whenever a mNAT-PT becomes active. mNAT-PT devices will inform the DNS-ALG the configured IPv6 prefix(es) when it comes up and whenever the configuration changes. DNS-ALG will send a periodic heart beat to make sure that the mNAT-PT is active. If DNS-ALG does not receive the heart beat reply back then the DNS-ALG assumes that the particular mNAT-PT is not active anymore and removes it from the active list. Park & Sivakumar Expires October 2003 [page 8] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 The communication between the DNS-ALG and mNAT-PT devices should be properly authenticated to avoid any malicious device to add a IPv6 prefix in the DNS ALG active list and thereby causing the traffic to be directed to the malicious device. Specific methods will be suggested in the next version. 7. mNAT-PT Information Messages This section describes new messages for asking a mNAT-PT to supply certain network information, such as its threshold value, state or prefix informations. This protocol is described in [NIQ]. As described in [NIQ], mNAT-PT Information Messages is same as [NIQ]. In order to provide mNAT-PT Information Messages, a few values are defined as follows; new defined value in Fields: Code For mNI Request: (TBD) Indicates that the Data field contains its own informations such as prefix information, threshold value and Link-local address Qtype Five values of Qtype are specified in [NIQ].In addition, (TBD) mNAT-PT Informations. See section 7.1 Data In a Request, the Subject Prefix information, Threshold value and Link-local address. In a Reply, Qtype-specific data present only when the ICMPv6 Code field is "3". The length of the Data may be inferred from the IPv6 header's Payload Length field [IPV6], the length of the fixed portion of the NI packet and the lengths of the ICMPv6 header and intervening extension headers. Park & Sivakumar Expires October 2003 [page 9] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 7.1 mNAT-PT Informations The Reply Data has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype=TBD | unused |L|T|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P If set to 1, Prefix Information [NDP] is requested. T If set to 1, Threshold value is requested. L If set to 1, Link-local addresses [LINK] are requested. 8. Security Considerations If someone wants to hijack original session, they could send a redirect message to the host and host would start the new session through the other mNAT-PT, which is a security hole. As Redirect message is described in [NDP], a host can check validity of message. If Redirect message includes an IP Authentication Header, the message authenticates correctly. In addtion, this solution is going to be considered in SEND working group. 9. Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. Park & Sivakumar Expires October 2003 [page 10] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 11. Acknowledgements The authors would like to thank Pyda Srisuresh for his careful reviews of this draft. Park & Sivakumar Expires October 2003 [page 11] INTERNET-DRAFT Scalable mNAT-PT solution April 2003 12. Authors' Address Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics, KOREA Phone: +82-31-200-3728 Email:soohong.park@samsung.com Senthil Sivakumar Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA 95134, US Email: ssenthil@cisco.com 13. 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. Park & Sivakumar Expires October 2003 [page 12]