Network Working Group S. Daniel Park Internet-Draft SAMSUNG Electronics Expires: April 22, 2006 S. Sivakumar Obsoletes: RFC2766 Cisco Systems, Inc. P. Srisuresh Caymas Systems T. Hain Cisco Systems, Inc. October 22, 2005 Network Address Translation - Protocol Translation (NAT-PT) draft-daniel-natpt-bis-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document specifies an IPv4-to-IPv6 transition mechanism. This solution attempts to provide transparent routing to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of Network Address Park, et al. Expires April 22, 2006 [Page 1] Internet-Draft NATPT-bis October 2005 Translation and Protocol Translation. The scheme described does not mandate dual stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation scheme and V6/V4 protocol translation scheme. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 NAT-PT scope and applicability statement . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 V4 address realm and V6 address realm . . . . . . . . . . 5 2.2 Network Address Translation (NAT) . . . . . . . . . . . . 5 2.3 NAT-PT flavors . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Traditional NAT-PT . . . . . . . . . . . . . . . . . . 6 2.3.2 Bi-directional NAT-PT . . . . . . . . . . . . . . . . 6 2.3.3 Protocol Translation (PT) . . . . . . . . . . . . . . 7 2.3.4 Pool of V4 addresses . . . . . . . . . . . . . . . . . 7 3. Traditional NAT-PT operation overview . . . . . . . . . . . . 7 3.1 Basic NAT-PT Session processing (V6 to v4) . . . . . . . . 7 3.2 NAPT-PT Outgoing Session processing (V6 to V4) . . . . . . 8 4. Bi-directional NAT-PT operation overview . . . . . . . . . . . 10 4.1 Static address mapping within NAT-PT . . . . . . . . . . . 10 5. Translation phases within NAT-PT . . . . . . . . . . . . . . . 11 5.1 Address (and port) binding . . . . . . . . . . . . . . . . 11 5.2 NAT-PT session flows . . . . . . . . . . . . . . . . . . . 12 5.3 IP and TCP/UDP/ICMP header translations . . . . . . . . . 12 5.3.1 IPv4 Headers to IPv6 Headers . . . . . . . . . . . . . 12 5.3.2 Translating IPv6 Headers to IPv4 Headers . . . . . . . 13 5.4 TCP/UDP/ICMP Checksum update . . . . . . . . . . . . . . . 13 5.4.1 TCP/UDP/ICMP Checksum update from IPv4 to IPv6 . . . . 13 5.4.2 TCP/UDP/ICMP Checksum update from IPv6 to IPv4 . . . . 14 5.5 Address (and Port) unbinding . . . . . . . . . . . . . . . 14 6. Use case scenarios . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Scenario 1 - Small devices that runs single stack . . . . 15 6.2 Scenario 2 - IPv4 Server running a legacy application . . 15 6.3 Scenario 3 - IPv6 only networks . . . . . . . . . . . . . 15 6.4 Scenario 4 - IPv6 3GPP networks . . . . . . . . . . . . . 16 7. Support for application level transparency . . . . . . . . . . 16 8. Known limitations . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Topology limitations . . . . . . . . . . . . . . . . . . . 16 8.2 Protocol translation limitations . . . . . . . . . . . . . 17 8.3 Impact of address translation . . . . . . . . . . . . . . 17 8.4 Lack of end-to-end security . . . . . . . . . . . . . . . 17 8.5 DNS translation and DNSSEC . . . . . . . . . . . . . . . . 18 9. Security considerations . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 18 Park, et al. Expires April 22, 2006 [Page 2] Internet-Draft NATPT-bis October 2005 11.1 Since RFC 2766 . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 12.2 Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 21 Park, et al. Expires April 22, 2006 [Page 3] Internet-Draft NATPT-bis October 2005 1. Introduction IPv6 is a new version of the IP protocol designed to modernize IPv4 which was designed in the 1970s. IPv6 has a number of advantages over IPv4 that will allow for future Internet growth and will simplify IP configuration and administration. IPv6 has a larger address space than IPv4, an addressing model that promotes aggressive route aggregation and a powerful autoconfiguration mechanism. In time, it is expected that Internet growth and a need for a plug-and-play solution will result in widespread adoption of IPv6. There is expected to be a long transition period during which it will be necessary for IPv4 and IPv6 nodes to coexist and communicate. A strong, flexible set of IPv4-to-IPv6 transition and coexistence mechanisms will be required during this transition period. The SIIT proposal [RFC2765] describes a protocol translation mechanism that allows communication between IPv6-only and IPv4-only nodes via protocol independent translation of IPv4 and IPv6 datagrams, requiring no state information for the session. The SIIT proposal assumes that V6 nodes are assigned a V4 address for communicating with V4 nodes, and does not specify a mechanism for the assignment of these addresses. NAT-PT uses a pool of V4 addresses for translation purposes, as sessions are initiated across V6-V4 address realms. NAT-PT binds addresses in V6 network with addresses in V4 network and vice versa to provide transparent routing [RFC2663] for the datagrams traversing between address realms. This requires no changes to end nodes and IP packet routing is completely transparent [RFC2663] to end nodes. It does, however, require NAT-PT to track the sessions it supports and mandates that inbound and outbound datagrams pertaining to a session traverse the same NAT-PT router. You will note that the topology restrictions on NAT-PT are the same with those described for V4 NATs in [RFC2663]. Protocol translation details specified in [RFC2765] would be used to extend address translation with protocol syntax/ semantics translation. Given the limitations of address translation between V4 and V6 realm, it is recommended to use NAT-PT only in the cases where the two end-nodes do not have a common IP stack (i.e., IPv4 or IPv6). [RFC4213] specifies other translation mechanisms available when both end-nodes have a common IP stack. 1.1 NAT-PT scope and applicability statement NAT-PT can be a valuable transition tool at the border of a stub network that has been deployed as an IPv6 only network when it is Park, et al. Expires April 22, 2006 [Page 4] Internet-Draft NATPT-bis October 2005 connected to an Internet that is either V4-only or a combination of V4 and V6. if a node has both V4 and V6 stack as dual stack architecture, NAT-PT may not be required for this case. Traditional NAT-PT is the simplest form to provide one way connectivity from an IPv6 stub domain to the IPv4 world meaning that only sessions initialised by IPv6 nodes internal to the IPv6 stub domain can be translated, while sessions initiated by IPv4 nodes are dropped. This makes NAT-PT a useful tool to IPv6 only stub networks that need to be able to maintain connectivity with the IPv4 world without the need to deploy servers visible to the IPv4 world. Bi-directional NAT-PT allows sessions to be initiated from either domain - V6 domain or V4 domain. Only static address mapping in the context of bi-directional NAT-PT is discussed. Dynamic address mappings are outside of the scope of this document as that would require a DNS-ALG to be present, either as an extension to NAT-PT on the same device (or) as an external entity interfacing with the NAT-PT device. 2. Terminology The majority of terms used in this document are borrowed almost as is from [RFC2663]. The following lists terms specific to this document. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 2.1 V4 address realm and V6 address realm As described in [RFC2663], an address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. In this document, V4(V6) address realm means IPv4(IPv6) addresses are uniquely assigned to entities within the network domain along with NAT-PT. 2.2 Network Address Translation (NAT) The term NAT in this document is very similar to the IPv4 NAT described in [RFC2663], but is not identical. IPv4 NAT translates one IPv4 address into another IPv4 address. In this document, NAT refers to translation of an IPv4 address into an IPv6 address and vice versa. While the V4 NAT [RFC2663] provides transparent routing between private V4 and external V4 address realms, NAT in this document provides routing between a V6 address realm and an external V4 Park, et al. Expires April 22, 2006 [Page 5] Internet-Draft NATPT-bis October 2005 address realm. As with V4 NAT, Application Level Gateways (ALGs) are external to NAT-PT and are not an inherent part of NAT-PT. NAT-PT does not require any ALGs for its operation. 2.3 NAT-PT flavors Just as there are various flavors identified with V4 NAT in [RFC2663], the following NAT-PT variations are identified in this document. 2.3.1 Traditional NAT-PT Traditional NAT-PT allows hosts within a V6 network to access hosts in the V4 network. In traditional NAT-PT, sessions are uni-directional, outbound from the V6 network. This is in contrast with Bi-directional NAT-PT, which permits sessions initiated in either direction. Just as with V4 traditional-NAT, there are two variations to traditional NAT-PT, namely Basic NAT-PT and NAPT-PT. With Basic NAT-PT, a block of V4 addresses are set aside for translating addresses of V6 hosts as they originate sessions to the V4 hosts in external domain. For packets outbound from the V6 domain, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. Likewise, for inbound packets, the destination IP address and and related fields such as IP, TCP, UDP and ICMP header checksums are translated. NAPT-PT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of V6 hosts to be multiplexed into the transport identifiers of a single assigned V4 address. NAPT-PT allows a set of V6 hosts to share a single V4 address. Note that NAPT-PT can be combined with Basic NAT-PT so that a pool of external addresses are used in conjunction with port translation. For packets outbound from the V6 network, NAPT-PT would translate the source IP address, source transport identifier and related fields such as IP, TCP, UDP and ICMP header checksums. Transport identifier can be one of TCP/UDP port or ICMP query ID. For inbound packets, the destination IP address, destination transport identifier and the IP and transport header checksums are translated. 2.3.2 Bi-directional NAT-PT With Bi-directional NAT-PT, sessions can be initiated from hosts in Park, et al. Expires April 22, 2006 [Page 6] Internet-Draft NATPT-bis October 2005 V4 network as well as the V6 network. V6 network addresses are bound to V4 addresses, statically or dynamically as connections are established in either direction. 2.3.3 Protocol Translation (PT) PT in this document refers to the translation of an IPv4 packet into a semantically equivalent IPv6 packet and vice versa. Protocol translation details are described in [RFC2765]. 2.3.4 Pool of V4 addresses A list of IPv4 addresses that are used to alias IPv6 addresses when sessions are initiated across V4 and V6 address realms. All the IPv4 addresses must be unique and globally routable to the IPv4 address realm on which NAT-PT resides. 3. Traditional NAT-PT operation overview NAT-PT offers a straight forward solution based on transparent routing [RFC2663] and address/protocol translation, allowing a large number of applications in V6 and V4 realms to inter-operate without requiring any changes to these applications. In this section, we describe the operation of NAT-PT and the way that connections can be initiated from a host in IPv6 domain to a host in IPv4 domain through a NAT-PT. 3.1 Basic NAT-PT Session processing (V6 to v4) [IPv6-B]-+ | +==============+ [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C] | +==============+ | (pool of v4 addresses)
Node [IPv6-A] has an IPv6 address -> FEDC:BA98::7654:3210 Node [IPv6-B] has an IPv6 address -> FEDC:BA98::7654:3211 Node [IPv4-C] has an IPv4 address -> 132.146.243.30 NAT-PT is configured with a pool of V4 addresses (say, 120.130.26/24) Park, et al. Expires April 22, 2006 [Page 7] Internet-Draft NATPT-bis October 2005 to map V6 nodes in the domain and a PREFIX to represent the V4 external nodes as V6 entities within the V6 domain. Say the Node [IPv6-A] wants to communicate with the Node [IPv4-C]. [IPv6-A] creates a packet with: Source Address, SA = FEDC:BA98::7654:3210 and Destination Address, DA = PREFIX::132.146.243.30 NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the NAT-PT, and packets addressed to this PREFIX will be routed to the NAT-PT. The pre-configured PREFIX only needs to be routable within the IPv6 stub domain and as such it can be any routable prefix that the network administrator chooses. The packet is routed via the NAT-PT gateway, where it is translated to IPv4. If the outgoing packet is not a session initialisation packet, the NAT-PT SHOULD already have stored some state about the related session, including assigned IPv4 address and other parameters for the translation. if this state does not exist, the packet SHOULD be silently discarded. If the packet is a session initialisation packet, the NAT-PT locally allocates an address (e.g: 120.130.26.10) from its pool of addresses and the packet is translated to IPv4. The translation parameters are cached for the duration of the session and the IPv6 to IPv4 mapping is retained by NAT-PT. The resulting IPv4 packet has SA=120.130.26.10 and DA=132.146.243.30. Any returning traffic will be recognised as belonging to the same session by NAT-PT. NAT-PT will use the state information to translate the packet, and the resulting addresses will be SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that this packet can now be routed inside the IPv6-only stub network as normal. 3.2 NAPT-PT Outgoing Session processing (V6 to V4) NAPT-PT, which stands for "Network Address Port Translation + Protocol Translation", would allow V6 nodes to communicate with the V4 nodes transparently using a single V4 address. The TCP/UDP ports of the V6 nodes are translated into TCP/UDP ports of the registered V4 address. While NAT-PT support is limited to TCP, UDP and other port multiplexing type of applications, NAPT-PT solves a problem that is inherent with NAT-PT. That is, NAT-PT would fail when the pool of V4 Park, et al. Expires April 22, 2006 [Page 8] Internet-Draft NATPT-bis October 2005 addresses assigned for translation purposes is exhausted. Once the address pool is exhausted, newer V6 nodes cannot establish sessions with the outside world anymore. NAPT-PT, on the other hand, will allow for a maximum of 63K TCP and 63K UDP sessions per IPv4 address before having no TCP and UDP ports left to assign. To modify the example sited in figure 1, we could have NAPT-PT on the border router (instead of NAT-PT) and all V6 addresses could be mapped to a single v4 address 120.130.26.10. Node [IPv6-A] would establish a TCP session with the Node [IPv4-C] as follows: [IPv6-A] creates a packet with: Source Address, SA = FEDC:BA98::7654:3210 , source TCP port = 3017 and Destination Address, DA = PREFIX::132.146.243.30, destination TCP port = 23. When the packet reaches the NAPT-PT box, NAPT-PT would assign one of the TCP ports from the assigned V4 address to translate the tuple of (Source Address, Source TCP port) as follows: SA = 120.130.26.10, source TCP port = 1025 and DA = 132.146.243.30, destination TCP port = 23. The returning traffic from 132.146.243.30, TCP port 23 will be recognised as belonging to the same session and will be translated back to V6 as follows: SA = PREFIX::132.146.243.30, source TCP port = 23; DA = FEDC:BA98::7654:3210 , destination TCP port = 3017 Inbound NAPT-PT sessions are restricted to one server per service, assigned via static TCP/UDP port mapping. For example, the Node [IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V6 domain. Node [IPv4-C] sends a packet: SA = 132.146.243.30, source TCP port = 1025 and DA = 120.130.26.10, destination TCP port = 80 NAPT-PT will translate this packet to: SA = PREFIX::132.146.243.30, source TCP port = 1025 DA = FEDC:BA98::7654:3210, destination TCP port = 80 In the above example, note that all sessions which reach NAPT-PT with Park, et al. Expires April 22, 2006 [Page 9] Internet-Draft NATPT-bis October 2005 a destination port of 80 will be redirected to the same Node [IPv6-A]. 4. Bi-directional NAT-PT operation overview With Bi-directional NAT-PT, sessions can be initiated from hosts in V4 network as well as V6 network. V6 network addresses are bound to V4 addresses, statically or dynamically as connections are established in either direction. In this section, we describe the operation of NAT-PT and the way that connections can be initiated from a host in IPv4 domain to a host in IPv6 domain through a NAT-PT. 4.1 Static address mapping within NAT-PT An IPv6 node in the NAT-PT domain can be traversed to a IPv4 node along with traditional NAT-PT operation as described in Section 3. However, an IPv4 node initiating its session to a V6 stub domain through NAT-PT can not communicate with a IPv6 node in the NAT-PT domain using traditional NAT-PT. For the address translation of incoming sessions (V4 to V6), NAT-PT must have had the mapping of the target IPv6 address to a IPv4 address statically preconfigured. Dynamic address mapping is outside the scops of this document. Say the Node [IPv4-C] wants to communicate with the Node [IPv6-A]. [IPv4-C] creates a packet with: Source Address, SA = 132.146.243.30 and Destination Address, DA = 120.130.26.100 In figure 2 below, if Node [IPv4-C]'s name resolver sends a name look up request for Node [IPv6-A], the DNS server on the V4 network directly replies the IPv4 address of [IPv6-A] (120.130.26.100) instead of the IPv6 address of [IPv6-A] (FEDC:BA98::7654:3210). [DNS]--+ | [DNS]------[DNS]-------[DNS] [IPv6-B]-+ | | | +==============+ | [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C] | +==============+ (pool of v4 addresses) Park, et al. Expires April 22, 2006 [Page 10] Internet-Draft NATPT-bis October 2005
NAT-PT has a mapping information: FEDC:BA98::7654:3210 : 120.130.26.100 (a) NAT-PT will check to see if the destination IPv4 address of incoming packet has a matching address binding. With the static address mapping configured as above, it would find the matching address binding for the target IP address of 120.130.26.100. When a matching address binding is not found and dynamic address binding on the inbound sessions is not supported, NAT-PT will simply drop such a packet. (b) Replacing the destination IPv4 address (120.130.26.100) with the IPv6 address (FEDC:BA98::7654:3210) as well as the source IPv4 address (132.146.243.30) with the IPv6 address (PREFIX::132.146.243.30). (c) Forwarding the IPv6 packet to the final destination in the NAT-PT domain. 5. Translation phases within NAT-PT The following translation phases of NAT-PT are described below. 5.1 Address (and port) binding A IPv6 packet that matches the NAT-PT prefix will be processed by NAT-PT.A IPv4 address will be allocated to the IPv6 source address from the configured IPv4 pool. An association between the IPv6 source address and the IPv4 address that NAT-PT allocated will be maintained by the NAT-PT. All subsequent packets from the same IPv6 host will use the same IPv6 - IPv4 address binding to communicate with the IPv4 realm. If the same IPv6 host communicates with other IPv4 hosts through the same NAT-PT, the address binding should be re-used. In case of NAPT-PT, the transport identifier in the IPv6 packet is retrieved by NAPT-PT and a single IPv4 address is used but a port is allocated to this session. NAPT-PT will maintain a port binding between the IPv6 address, port and the IPv4 address, Port. All subsequent packets from the same IPv6 address, port will use this binding. Typically the first packet in the flow will create the address and/or port binding. Park, et al. Expires April 22, 2006 [Page 11] Internet-Draft NATPT-bis October 2005 5.2 NAT-PT session flows When the first packet of a TCP/UDP session reaches NAT-PT interface, the packet is subject to NAT-PT session lookup. If the packet fails to match any of the known NAT-PT sessions, the packet's source/ destination endpoint is compared for a match against the address/port bindings and address map entries in that order. If a matching address/port binding is found, that is an indication that a binding already exists and that the binding can be reused. Otherwise, if a matching address map entry is found, a new address/port binding is created from the address map. A new NAT-PT session is created to describe the session in each of the realms and the transaltion associated between the two. Specifically, a NAT-PT session will refer the address/port binding it uses. NAT-PT session for a TCP based flow may have additional information than a UDP based flow. Note, some variations of NAPT-PT (called, symmetric NAT-PT) do not use port binding. Instead, they use NAT-PT sessions directly without the port binding. All subsequent packets (other than the first packet of a session) traversing the NAT device are subject to NAT-PT-session lookup for translation purposes. Packets matching a NAT-PT-session undergo translation in either direction. Individual packet translation issues are covered in detail in the following sub-sections. 5.3 IP and TCP/UDP/ICMP header translations The IPv4 and ICMPv4 headers are similar to their V6 counterparts but a number of fields are either missing, have different meaning or different length. NAT-PT SHOULD translate all IP/ICMP headers from v4 to v6 and vice versa in order to make end-to-end IPv6 to IPv4 communication possible. Due to the address translation function and possible port multiplexing, NAT-PT SHOULD also make appropriate adjustments to the upper layer protocol (TCP/UDP) headers. Protocol Translation details are described in [RFC2765], but there are some modifications required to SIIT because of the fact that NAT-PT also performs Network Address Translation. 5.3.1 IPv4 Headers to IPv6 Headers This is done exactly the same as in SIIT apart from the following fields: Source Address: The low-order 32 bits is the IPv4 source address. The high-order 96 bits is the designated PREFIX for all v4 communications. Addresses using this PREFIX will be routed to the NAT-PT gateway Park, et al. Expires April 22, 2006 [Page 12] Internet-Draft NATPT-bis October 2005 (PREFIX::/96) Destination Address: NAT-PT retains a mapping between the IPv4 destination address and the IPv6 address of the destination node. The IPv4 destination address is replaced by the IPv6 address retained in that mapping. 5.3.2 Translating IPv6 Headers to IPv4 Headers This is done exactly the same as in SIIT apart from the Source Address which should be determined as follows: Source Address: The NAT-PT retains a mapping between the IPv6 source address and an IPv4 address from the pool of IPv4 addresses available. The IPv6 source address is replaced by the IPv4 address retained in that mapping. Destination Address: IPv6 packets that are translated have a destination address of the form PREFIX::IPv4/96. Thus the low-order 32 bits of the IPv6 destination address is copied to the IPv4 destination address. 5.4 TCP/UDP/ICMP Checksum update NAT-PT retains mapping between IPv6 address and an IPv4 address from the pool of IPv4 addresses available. This mapping is used in the translation of packets that go through NAT-PT. The following sub-sections describe TCP/UDP/ICMP checksum update procedure in NAT-PT, as packets are translated from V4 to V6 and vice versa. 5.4.1 TCP/UDP/ICMP Checksum update from IPv4 to IPv6 UDP checksums, when set to a non-zero value, and TCP checksum SHOULD be recalculated to reflect the address change from v4 to v6. The incremental checksum adjustment algorithm may be borrowed from [RFC3022]. In the case of NAPT-PT, TCP/UDP checksum should be adjusted to account for the address and TCP/UDP port changes, going from V4 to V6 address. When the checksum of a V4 UDP packet is set to zero, NAT-PT MUST evaluate the checksum in its entirety for the V6-translated UDP packet. If a V4 UDP packet with a checksum of zero arrives in fragments, NAT-PT MUST await all the fragments until they can be assembled into a single non-fragmented packet and evaluate the checksum prior to forwarding the translated V6 UDP packet. Park, et al. Expires April 22, 2006 [Page 13] Internet-Draft NATPT-bis October 2005 ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and TCP during checksum computation. As a result, when the ICMPv6 header checksum is computed [RFC2765], the checksum needs to be adjusted to account for the additional pseudo-header. Note, there may also be adjustments required to the checksum due to changes in the source and destination addresses (and changes in TCP/UDP/ICMP identifiers in the case of NAPT-PT) of the payload carried within ICMP. 5.4.2 TCP/UDP/ICMP Checksum update from IPv6 to IPv4 TCP and UDP checksums SHOULD be recalculated to reflect the address change from v6 to v4. The incremental checksum adjustment algorithm may be borrowed from [RFC3022]. In the case of NAPT-PT, TCP/UDP checksums should be adjusted to account for the address and TCP/UDP port changes, going from V6 to V4 addresses. For UDP packets, optionally, the checksum may simply be changed to zero. The checksum calculation for a V4 ICMP header needs to be derived from the V6 ICMP header by running the checksum adjustment algorithm [RFC3022] to remove the V6 pseudo header from the computation. Note, the adjustment must additionally take into account changes to the checksum as a result of updates to the source and destination addresses (and transport ports in the case of NAPT-PT) made to the payload carried within ICMP. 5.5 Address (and Port) unbinding When the last session based on an address or port binding is terminated, the binding itself may be terminated, if the binding is not static and a binding timer is not set. NAT-PT sessions are terminated by NAT-PT using various heuristics. In case of a connection oriented protocol like TCP, it will be a FIN/FIN-ACK or RST that indicates connection termination. However, in case of other protocols it will be an inactive timer that will remove the binding. Alternately, if the binding has an idle-time binding timer set, the binding is left unchanged for the period set by the timer, even as there is not a single NAT-PT session that uses the binding. When the binding timer is expired, the elements of the binding are freed into the resourse pool which will be used by NA(P)T-PT for subsequent address and port allocations. 6. Use case scenarios NAT-PT is expected to be used in a limited set of scenarios where the other forms of native IPv4 and IPv6 communication is not possible. This restriction could arise when a node, a network or an application is capable of supporting only one protocol, either IPv4 or IPv6. Park, et al. Expires April 22, 2006 [Page 14] Internet-Draft NATPT-bis October 2005 6.1 Scenario 1 - Small devices that runs single stack In cases of smaller devices that can run only a single stack of IPv4 or IPv6, either because of memory constraints or cost constraints, a NAT-PT will be used. IPv6 only---(IPv6/IPv4)---NAT-PT---( IPv4 )---IPv4 Device Device ( Network ) (Network) 6.2 Scenario 2 - IPv4 Server running a legacy application A IPv4 server running a legacy application in an IPv4 network that cannot be upgraded to IPv6 is a most common scenario. In this case, a NAT-PT is used in the stub network closest to the IPv4 network that has the server. IPv6 Host---(IPv6 only)---NAT-PT---( IPv4 )---IPv4 only Server Dual Stack ( Network ) (Network) 6.3 Scenario 3 - IPv6 only networks Some networks might be built totally as IPv6 networks only, because of operational issues like the overhead of maintaining and troubleshooting two different networks. This option could be chosen when a high percentage of the traffic stays within the IPv6 network and only a smaller percentage of the traffic needs the IPv4 connectivity. IPv6 Host---(IPv6 only)---NAT-PT---( IPv4 )---IPv4 only Server (Dual Stack) ( Network ) (Network) Park, et al. Expires April 22, 2006 [Page 15] Internet-Draft NATPT-bis October 2005 6.4 Scenario 4 - IPv6 3GPP networks As described in [RFC4215] 3GPP networks makes use of NAT-PT as generic translators. Due to the significant lack of IPv4 addresses in some domains, port multiplexing (NAPT-PT) is likely to be a necessary feature for translators. Several considerations is described in [RFC4215]. IPv6 UE---(GGSN)---NAT-PT---( IPv4 )---Peer---IPv4 Device (Network) 7. Support for application level transparency Some protocols carrying the IP address and port information in its payload for the data session require Application Level Gateway (ALG) or proxy to provide application level transparency for these popular Internet application, i.e., DNS, FTP, SIP and etc. Each ALG should be built on NAT-PT in order to use the application between V4 and V6 networks. Specific ALGs are out of scope and will be described in seperate documents. Implementation note: ALG/Proxy requirement described above are not restricted to the DNS, FTP and SIP, so implementor should consider of which ALG/Proxy functions are required when developing its NAT-PT system. 8. Known limitations All limitations associated to NAT [RFC2663] are also associated to NAT-PT. Here are the most important of them in detail, as well as some unique to NAT-PT. 8.1 Topology limitations There are limitations to using the NAT-PT translation method. It is mandatory that all requests and responses pertaining to a session be routed via the same NAT-PT router. One way to guarantee this would be to have NAT-PT based on a border router that is unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. This is a generic problem with NAT and it is fully described in [RFC2663]. Park, et al. Expires April 22, 2006 [Page 16] Internet-Draft NATPT-bis October 2005 Note, this limitation does not apply to packets originating from or directed to dual-stack nodes that do not require packet translation. This is because in a dual-stack set-up, IPv4 addresses implied in a V6 address can be identified from the address format PREFIX::x.y.z.w and a dual-stack router can accordingly route a packet between v4 and dual-stack nodes without tracking state information. This should also not affect IPv6 to IPv6 communication and in fact only actually use translation when no other means of communication is possible. for example NAT-PT may also have a native IPv6 connection and/or some kind of tunneled IPv6 connection. Both of the above connections should be preferred over translation when possible. The above makes sure that NAT-PT is a tool only to be used to assist transition to native IPv6 to IPv6 communication. 8.2 Protocol translation limitations A number of IPv4 fields have changed meaning in IPv6 and translation is not straightforward. For example, the option headers semantics and syntax have changed significantly in IPv6. In several cases, there are no equivalents for IPv6 in IPv4, like the flow labels in IPv6 header. Hence a pure IPv6 to IPv4 translation may not be possible in all cases. Details of IPv4 to IPv6 Protocol Translation can be found in [RFC2765]. 8.3 Impact of address translation Since NAT-PT performs address translation, applications that carry the IP address in the higher layers will not work. In this case Application Layer Gateways (ALG) need to be incorporated to provide support for those applications. This is a generic problem with NAT and it is fully described in [RFC2663]. 8.4 Lack of end-to-end security One of the most important limitations of the NAT-PT proposal is the fact that end-to-end network layer security is not possible. Also transport and application layer security may not be possible for applications that carry IP addresses to the application layer. This is an inherent limitation of the Network Address Translation function. Independent of NAT-PT, end-to-end IPSec security is not possible across different address realms. The two end-nodes that seek IPSec network level security must both support one of IPv4 or IPv6. Park, et al. Expires April 22, 2006 [Page 17] Internet-Draft NATPT-bis October 2005 8.5 DNS translation and DNSSEC When involving translation of DNS messages for address translation, this scheme can not be deployed in combination with secure DNS. I.e., an authoritative DNS name server in the V6 domain cannot sign replies to queries that originate from the V4 world. As a result, an V4 end-node that demands DNS replies to be signed will reject replies that have been tampered with by NAT-PT. The good news, however, is that only servers in V6 domain that need to be accessible from the V4 world pay the price for the above limitation, as V4 end-nodes may not access V6 servers due to DNS replies not being signed. Also note that zone transfers between DNS-SEC servers within the same V6 network are not impacted. Clearly, with DNS SEC deployment in DNS servers and end-host resolvers, the scheme suggested in this document would not work. 9. Security considerations Following the conceptual design of middlebox communication, end-to-end network and transport layer security are not possible when a session is intercepted by a NAT-PT. Also, application layer security may not be possible for applications that carry IP addresses in the application layer. Regarding the DNS aspect, secure DNS is not may adoptable for NAT-PT because of unchained authoritative DNS query/reply between V4 and V6 domain. Finally, all of the security considerations described in [RFC2663] are applicable to this document as well 10. Acknowledgements Thanks to the authors of the original NAT-PT (RFC 2766). 11. Change history 11.1 Since RFC 2766 o Removed all ALG stuff (DNS-ALG, FTP-ALG) and added a new section as "Support for application level transparency" to be considered a protocol carrying the IP address and port in its payload for the data session require ALG. Park, et al. Expires April 22, 2006 [Page 18] Internet-Draft NATPT-bis October 2005 o Added "Static address mapping within NAT-PT" section to support bi- directional NAT-PT operation. o Added a section on use case scenarios to help readers understood the rationale behind NAT-PT deployments. o Specified and reorganized translation phase within NAT-PT. 12. References 12.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. 12.2 Informative References [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005. Authors' Addresses Soohong Daniel Park, Editor SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 EMail: soohong.park@samsung.com Park, et al. Expires April 22, 2006 [Page 19] Internet-Draft NATPT-bis October 2005 Senthil Sivakumar, Editor Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 USA Phone: EMail: ssenthil@cisco.com Pyda Srisuresh Caymas Systems, Inc. 1179-A North McDowell Blvd. Petaluma, CA 94954 USA Phone: +1 707 283 5063 EMail: srisuresh@yahoo.com Tony Hain Cisco Systems, Inc. 500 108th Ave. NE Bellevue, Wa USA Phone: EMail: alh-ietf@tndh.net Park, et al. Expires April 22, 2006 [Page 20] Internet-Draft NATPT-bis October 2005 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. Park, et al. Expires April 22, 2006 [Page 21]