Internet Engineering Task Force H. Miyata Internet-Draft M. Endo Intended status: Experimental Yokogawa Electric Corp. Expires: March 29, 2009 September 29, 2008 sNAT-PT: Simplified Network Address Translation - Protocol Translation draft-miyata-v6ops-snatpt-02 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 March 29, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies an IPv4-to-IPv6 transition mechanism to provide accessibility for IPv6 node to IPv4 node, and vice-versa. The goal of this document is not providing the most fundamental technology which could works well with additional technology. We used to have an technology called NAT-PT[RFC2766]. NAT-PT was designed to work with problematic DNS Application Level Gateway. So, it was changed to historical state by [RFC4966]. This document attempts to simplify NAT-PT specification, removing dependability on Application Layer Gateway as well as resolving problems pointed in [RFC4966]. Miyata Expires March 29, 2009 [Page 1] Internet-Draft sNAT-PT September 2008 Table of Contents 1. Introduction.................................................. 3 2. Terminology................................................... 4 2.1 Network Address Translation (NAT)......................... 4 2.2 NAT-PT flavors............................................ 4 2.2.1 Traditional-NAT-PT................................... 4 2.2.2 Bi-directional-NAT-PT................................ 5 2.3 Protocol Translation (PT)................................. 5 2.4 Application Level Gateway (ALG)........................... 6 2.5 Dummy Prefix.............................................. 6 2.6 Requirements Language..................................... 6 3. Conceptual Model.............................................. 6 3.1 Address Mapping Table..................................... 8 3.2 Translation Rule Table.................................... 8 3.3 Session Status Table...................................... 9 3.4 Configuration Interface................................... 10 4. Dummy Prefix Definition....................................... 11 5. NAT-PT Operation.............................................. 12 5.1 Traditional NAT-PT(IPv6 to IPv4).......................... 12 5.1.1 Basic NAT-PT Operation............................... 12 5.1.2 NAPT-PT Operation.................................... 13 5.2 Bi-Directional NAT-PT..................................... 14 5.2.1 Basic Bi-directional NAT-PT Operation................ 14 5.2.2 Port Mapping Operation............................... 15 6. IPv6 Address mapping.......................................... 16 7. IPv4 Address mapping.......................................... 16 8. Protocol Translation Details.................................. 16 8.1 Translating IPv4 Headers to IPv6 Headers.................. 17 8.2 Translating IPv6 Headers to IPv4 Headers.................. 17 8.3 TCP/UDP/ICMP Checksum Update.............................. 17 8.3.1 TCP/UDP/ICMP Checksum Update from IPv4 to IPv6....... 18 8.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv4....... 18 8.4 ICMP translation.......................................... 18 8.4.1 ICMP translation from IPv4 to IPv6................... 19 8.4.2 ICMP translation from IPv6 to IPv4................... 19 9. Host Implementation........................................... 19 10. Application Level Gateway Support............................ 20 11. NAT-PT Limitations and Future Work........................... 20 11.1 Load Balance............................................. 20 11.2 Redundancy............................................... 20 11.3 SCTP..................................................... 21 11.4 Topology Limitations..................................... 21 11.5 Protocol Translation Limitations........................ 21 11.6 Impact of Address Translation............................ 21 11.7 Lack of End-to-End Security.............................. 21 11.8 Multicast Translation.................................... 22 11.8.1 The translation of multicast from IPv6 to IPv4....... 22 11.8.2 The translation of multicast from IPv4 to IPv6....... 22 Miyata Expires March 29, 2009 [Page 2] Internet-Draft sNAT-PT September 2008 11.9 Twice NAT-PT............................................. 23 12. Applicability Statement...................................... 23 13. IANA Considerations.......................................... 24 14. Security Considerations...................................... 25 15. References................................................... 25 15.1 Normative References..................................... 25 15.2 Informative References................................... 26 Appendix A....................................................... 27 Authors' Addresses............................................... 28 Intellectual Property and Copyright Statements................... 29 1. Introduction Disclaimer: This proposal is incomplete. It is posted to seek comments on plausibility and to represent the approach how to simplify the NAT-PT which was mixed up with ALGs. IPv6 is a new version of the Internet Protocol(IP) designed to improve IPv4 to allow for future Internet growth. Recently, it is predicted that the IPv4 address would be run out in several years and IPv6 would be deployed. On the other hand, IPv4 has been maintained to extend its lifetime. So, the transition period is predicted to be long. During the period, IPv6 node need to co-exist with IPv4 node. During the period, there would be some node which can use only IPv4 (IPv4 Only Node) as well as node which can use only IPv6(IPv6 Only Node). And they will need to communicate. So, the translation technology is required. There are some standarized translation technologies, "Stateless IP/ICMP Translation Algorithm"(SIIT)[RFC2765] and "An IPv6-to-IPv4 Transport Relay Translator"(TRT)[RFC3142]. SIIT has a big advantage that does not require to maintain the session state in Translator Box. But SIIT is designed to be used by small IPv6 network. And it requires IPv6 host to implement functionalities to be assinged IPv4 address. TRT has simple architecture and it does not require any modification for both IPv6 and IPv4 host. But TRT Translatoion Box is designed to translate in transport layer. To provide communication between IPv6 Only Node and IPv4 Only Node, it establishs two sessions, one is with IPv6 Only Node, another is with IPv4 Only Node. So it is costful. Also it is designed to provide only TCP sessions initiated by IPv6 Only Node. Miyata Expires March 29, 2009 [Page 3] Internet-Draft sNAT-PT September 2008 NAT-PT was designed to provide both TCP and UDP communications. Also it attempted to provide communications initiated by both IPv6 Only Node and IPv4 Only Node. NAT-PT does not require IPv6 node and IPv4 node to implement special functionalities to communicate via Translation Box. In 2007 it was depricated by some reasons described in [RFC4966]. But its basic and simple translation behavior is helpful for some situations, which does not expect perfect translation. This documents attmept to recycle NAT-PT specification removing dependability on specific application and resolving some issues listed in [RFC4966]. 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. 2.1 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 IPv4 NAT [RFC2663] provides routing between private IPv4 and external IPv4 address realms, NAT in this document provides routing between a IPv6 address realm and an external IPv4 address realm. 2.2 NAT-PT flavors Just as there are various flavors identified with IPv4 NAT in [RFC2663], the following NAT-PT variations may be identified in this document. 2.2.1 Traditional NAT-PT Traditional-NAT-PT would allow hosts within a IPv6 network to access hosts in the IPv4 network. In a traditional-NAT-PT, sessions are uni- directional, outbound from the IPv6 network. This is in contrast with Bi-directional-NAT-PT, which permits sessions in both inbound and outbound directions. Just as with IPv4 traditional-NAT, there are two variations to traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT. Miyata Expires March 29, 2009 [Page 4] Internet-Draft sNAT-PT September 2008 With Basic-NAT-PT, a block of IPv4 addresses are set aside for translating addresses of IPv6 hosts as they originate sessions to the IPv4 hosts in external domain. For packets outbound from the IPv6 domain, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above 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 IPv6 hosts to be multiplexed into the transport identifiers of a single mapped IPv4 address. NAPT-PT allows a set of IPv6 hosts to share a single IPv4 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 IPv6 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.2.2 Bi-Directional-NAT-PT With Bi-directional-NAT-PT, sessions can be initiated from hosts in IPv4 network as well as the IPv6 network. IPv6 network addresses are bound to IPv4 addresses statically or dynamically. For dynamic address binding Application Level Gateway(ALG)[RFC2663] is required. There should be various kinds of ALG. The detail specification of ALG is out of scope of this document. Bi-directional-NAT-PT which maps one IPv4 address to one IPv6 address should be called Basic-Bi-directional-NAT-PT. Port-Mapping maps a pair of IPv4 address and TCP or UDP port to a pair of IPv6 address and TCP or UDP port. 2.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]. Miyata Expires March 29, 2009 [Page 5] Internet-Draft sNAT-PT September 2008 2.4 Application Level Gateway (ALG) ALG is an application specific agent that allows a IPv6 node to communicate with a IPv4 node and vice versa. Some applications carry network addresses in payloads. But NAT-PT is application unaware and does not snoop the payload. ALG would snoop the payload to modify and configure the NAT-PT gateway dynamically if required. ALG could work in conjunction with NAT-PT to provide support for many kind of such applications. 2.5 Dummy Prefix The IPv6 Prefix to map IPv4 address to IPv6 address. And the length is 96 bit. In this document Dummy Prefix is represented as PREFIX or PREFIX::/96 when IPv6 address or prefix is described. The prefix PREFIX::/96 is advertised in the IPv6 network by the NAT-PT gateway, and packets addressed to this PREFIX will be routed to the NAT-PT gateway. The pre-configured PREFIX only needs to be routable within the IPv6 network and as such it can be any routable prefix that the network administrator chooses. 2.6 Requirements Language 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]. 3. Conceptual Model This document attempts to separate ALGs form NAT-PT gateway logically as described in Fig. 3.1. NAT-PT gateway and ALG can colocate physically. Some ALG can be implemented in Translation Engine if required. This chapter makes use of internal conceptual variables to describe the behavior of NAT-PT gateway. The specific variable names are just an example. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. One of the most important point here is that "Address Mapping Table" and "Translation Rule Table" is the most fundamental point that define the behavior how to translate the packet regardless how the entries are generated. Miyata Expires March 29, 2009 [Page 6] Internet-Draft sNAT-PT September 2008 Another point is that the NAT-PT gateway MUST maintain the address mapping, translation rule or session status to recycle the IPv4 address and TCP/UDP ports. Also, to send ICMP Error Messages to appropriate destination, the information of translated session is important to map the destination address. +------------------------+ | ALG | | e.g., DNS-ALG, SIP-ALG | +------------------------+ | ^ | | +---------|---|------------------------+ +-> | v | | Config. | | +-----------+ +-----+ | I/F -+ | | ALG-IF | | CUI | | (*4) | | +-----------+ +-----+ | +-> | | | / | | | | | / | | | | |/ | | | | | | | | | /| | | | | / | | | +-> | | / | | | | | v v v v | | | +---------+ +---------+ +---------+ | | | |AAtbl(*1)| |TRtbl(*2)| |TStbl(*3)| | | | +---------+ +---------+ +---------+ | Target | | ^ ^ ^ | of -+ | | | | | This | | | | | | Document | | +----------------------+ | | | | Translation Engine | | | | +----------------------+ | | | | | | NAT-PT gateway | +-> +--------------------------------------+ Fig. 3.1 Conceptual Model (*1) Address Mapping Table (*2) Translation Rule Table (*3) Session Status Table (*4) Configuration Interface Miyata Expires March 29, 2009 [Page 7] Internet-Draft sNAT-PT September 2008 3.1 Address Mapping Table To translate the packet, An IPv4 address must be mapped to an IPv6 address regardless the direction of the session. So, the address mapping must be defined in this table. This table must have following informations. IPv6 Address The IPv6 address to which IPv4 address be mapped. IPv4 Address The IPv4 address which is mapped to above IPv6 address. If the Translation Type of correspondent entry is NAPT-PT, the specified address can be shared with other entry. Translation Type The type of translation must be defined. e.g., NAPT-PT or NAT-PT Stability The stability type of this mapping. This is used for recycle purpose. This value specifies this mapping is "static" or "dynamic". If it is mapped dynamically, and there are no session entry on "Session Status Table" associated to this entry for a while, the entry and associated entry in "Translation Rule Table" MUST be removed for recycle purpose. 3.2 Translation Rule Table The NAT-PT gateway needs to know how to handle the packet. So, this table defines the rule what kind of packet must be handled in what kind of manner. This table must have following informations. Address Mapping Table Entry The entry number of Address Mapping Table which is used by this entry. Direction The allowed direction of session initiation is defined. e.g., IPv6-to-IPv4 (IPv6 node initiate the session) IPv4-to-IPv6 (IPv4 node initiate the session) Bi-dir (Bi-direction) Miyata Expires March 29, 2009 [Page 8] Internet-Draft sNAT-PT September 2008 IPv6 Address The IPv6 address of end-node which can use this entry. If the Direction value of correspondent entry is IPv6-to-IPv4, the address can be specified by range as well as wildcard. e.g., 2001:DB8:b:a::/64 2001:DB8:b:a:1234:5678:9abc:def0/128 any IPv4 Address The IPv4 address of end-node which can use this entry. If the Direction value of correspondent entry is IPv4-to-IPv6, the address can be specified by range as well as wildcard. e.g., 192.0.2.0/24 192.0.2.4/32 any Protocol The Protocol which is allowed to translate. e.g., TCP, UDP, ICMP 3.3 Session Status Table The entries of this table MUST be generated dynamically when the session is initiated. And it MUST be maintained and removed according to the session status. The correspondent session entry is generated after examining the "Translation Rule Table", if the session is allowed. In TCP session: The entry is generated by SYN packet. The entry is deleted when session is closed. In UDP session: The entry is generated by first packet. The entry is deleted after pre-configured time from last packet. Protocol The protocol of this entry. e.g., TCP, UDP, ICMP IPv6 Node The IPv6 address of IPv6 side end node of correspondent session. It can not be specified by range or wildcard. IPv4 Node The IPv4 address of IPv4 side end node of correspondent session. It can not be specified by range or wildcard. Miyata Expires March 29, 2009 [Page 9] Internet-Draft sNAT-PT September 2008 Port on IPv6 Node The Port number of TCP or UDP, which is used on IPv6 side end node for this session. Port on IPv4 Node The Port number of TCP or UDP, which is used on IPv4 side end node for this session. Mapped IPv6 Address The address which is mapped to the address specified in "IPv4 Node" field. It must be the synthesis address. The packet addressed to this address MUST be routed to the NAT-PT gateway. Mapped IPv4 Address The address which is mapped to the address specified in "IPv6 Node" field. The packet addressed to this address MUST be routed to the NAT-PT gateway. Port on Gateway IPv6 Side The Port number of TCP or UDP, which is used on NAT-PT gateway for this session on IPv6 side. Port on Gateway IPv4 Side The Port number of TCP or UDP, which is used on NAT-PT gateway for this session on IPv4 side. Remaining Time Typically in UDP session, the entry MUST be removed when it is not in use. This field stores the remaining time for its expiration. After each packet translation, NAT-PT gateway must reset to the pre-configured value. The value MUST be decreased by aging method. 3.4 Configuration Interface "Address Mapping Table" and "Translation Rule Table" MUST be configured statically or dynamically. So, the configuration Interface is required. The administrator would configure static rule. So, the User Interface (A.K.A. GUI, CUI) would be used. Some kinds of ALG, (e.g.. DNS-ALG, FTP-ALG) would generate dynamic rule, so the interface to set the rules are required. The Interface is TBD Miyata Expires March 29, 2009 [Page 10] Internet-Draft sNAT-PT September 2008 4. Dummy Prefix Definition Each NAT-PT gateway MUST be pre-configured a Dummy Prefix. The Dummy Prefix assigned to individual NAT-PT gateway MUST be unique. The uniqueness MUST be guaranteed within the IPv6 network they attached. Backup model and Load balance model is out of scope of this document. The packet addressed to the synthesis IPv6 address MUST arrive to the associated NAT-PT gateway. The format is described in Fig. 4.1. 1 1 2 6 7 9 2 0123456789012345678901234...01234567890...01234567890...012345678 +------------------------//-----+------//-------+----//---------+ | IPv6 Prefix | IDENT | IPv4 Address | | 64 bit | 32 bit | 32 bit | +------------------------//-----+------//-------+----//---------+ | | |<-----------------Dummy Prefix---------------->| Fig. 4.1 Dummy Prefix Format The length of Dummy Prefix is 96-bit. The top 64-bit is a routable unicast prefix of IPv6. Any prefix can be assigned by the administrator from the address space he/her is administrating as far as it is not assigned. The following 32-bit, represented as IDENT MUST be an value assigned by IANA to indicate that translator would exist in the path. More requirement for IDENT is described in Chapter 13. The Dummy Prefix MUST be followed by encoded IPv4 address. NOTE: As [ID-baker] mentioned if the Dummy Prefix less matches to the address assigned to the IPv6 client, it chooses the non-synthetic address naturally, Assigning the Dummy Prefix range from the range which is far from actual used unicast range. Moreover, considering the usage inside the enterprise (See the third NOTE in Chapter 12, Applicability Statement), if the Dummy Prefix is selected from the prefix assigned to the enterprise, the client would prefer synthetic address than native address. To avoide this situation, using a prefix which less matchs to the enterprise prefix is useful. But assigning a prefix to each enterprise will significantly increase the routing table. This is difficult trade-off. When using DNS rewriting service, the client will not receive both synthetic and native address as far as DNS service attempt Miyata Expires March 29, 2009 [Page 11] Internet-Draft sNAT-PT September 2008 to resolve the native service first. Or, if the IPv6 network is stub network, well-known address which is far from commonly used unicast address area would be helpful. 5. NAT-PT Operation NAT-PT offers a straight forward solution based on transparent routing [RFC2663] and address/protocol translation, allowing a large number of applications in IPv6 and IPv4 realms to inter-operate without requiring any changes to these applications. 5.1 Traditional NAT-PT (IPv6 to IPv4) In the following paragraphs we describe the operation of traditional-NAT-PT and the way that connections can be initiated from a host in IPv6 domain to a host in IPv4 domain through a traditional-NAT-PT 5.1.1 Basic NAT-PT Operation (IPv6-B)-+ | +==============+ (IPv6-A)-+-(NAT-PT)---------| IPv4 network |--(IPv4-C) | +==============+ (pool of IPv4 addresses) Figure 4.1: IPv6 to IPv4 communication Node IPv6-A has an IPv6 address -> 2001:DB8:b:a::7654:3210 Node IPv6-B has an IPv6 address -> 2001:DB8:b:a::7654:3211 Node IPv4-C has an IPv4 address -> 192.0.2.12 NAT-PT has a pool of addresses including the IPv4 subnet 10.0.0.0/24 The IPv4 addresses in the address pool could be allocated one-to-one to the IPv6 addresses of the IPv6 end nodes in which case one needs as many IPv4 addresses as IPv6 end points. In this document we assume that the IPv6 network has less IPv4 addresses than IPv6 end nodes and thus dynamic address allocation is required for at least some of them. Say the IPv6 Node IPv6-A wants to communicate with the IPv4 Node IPv4-C. IPv6-A creates a packet with: Miyata Expires March 29, 2009 [Page 12] Internet-Draft sNAT-PT September 2008 SA=2001:DB8:b:a::7654:3210 and DA=PREFIX::192.0.2.12 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 mapped 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: 10.0.0.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=10.0.0.10 and DA=192.0.2.12. 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::192.0.2.12, DA=2001:DB8:b:a::7654:3210. Note that this packet can now be routed inside the IPv6-only stub network as normal. 5.1.2 NAPT-PT Operation NAPT-PT, which stands for "Network Address Port Translation + Protocol Translation", would allow IPv6 nodes to communicate with the IPv4 nodes transparently using a single IPv4 address. The TCP/UDP ports of the IPv6 nodes are translated into TCP/UDP ports of the registered IPv4 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 fall flat when the pool of IPv4 addresses mapped for translation purposes is exhausted. Once the address pool is exhausted, newer IPv6 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 map. To modify the example sited in figure 4.1, we could have NAPT-PT on the border router (instead of NAT-PT) and all IPv6 addresses could be mapped to a single IPv4 address 10.0.0.10. IPv6 Node IPv6-A would establish a TCP session with the IPv4 Node IPv4-C as follows: Miyata Expires March 29, 2009 [Page 13] Internet-Draft sNAT-PT September 2008 IPv6-A creates a packet with: SA=2001:DB8:b:a::7654:3210 , source TCP port = 3017 and DA=PREFIX::192.0.2.12, destination TCP port = 23. When the packet reaches the NAPT-PT box, NAPT-PT would map one of the TCP ports from the mapped IPv4 address to translate the tuple of (Source Address, Source TCP port) as follows: SA=10.0.0.10, source TCP port = 1025 and DA=192.0.2.12, destination TCP port = 23. The returning traffic from 192.0.2.12, TCP port 23 will be recognized as belonging to the same session and will be translated back to IPv6 as follows: SA=PREFIX::192.0.2.12, source TCP port = 23; DA=2001:DB8:b:a::7654:3210 , destination TCP port = 3017 5.2 Bi-Directional-NAT-PT 5.2.1 Basic Bi-Directional-NAT-PT Operation To provide incoming session, IPv4 address MUST be mapped one-to-one to IPv6 address. The mapping could be done via configuration interface. In this section the description is based on the situation that mapped address and translation rule are already configured. NAT-PT has a pool of addresses including the IPv4 subnet 10.0.0.0/24. Say the IPv4-C wants to communicate with the IPv6-A. Somehow 10.0.0.10 is mapped to the IPv6-A, and IPv4-C knows the mapped address. (ALG is expected to map the address and inform the address to IPv4-C dynamically.) Then, the IPv4-C creates a packet with: SA=192.0.2.12 and DA=10.0.0.10 The packet is routed via the NAT-PT gateway, where it is translated to IPv6. If the incoming packet is not a session initialisation packet, the NAT-PT SHOULD already have stored some state about the related session, including mapped 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 search the IPv6 address associated to 10.0.0.10 (2001:DB8:b:a::7654:3210) from its "Address Mapping Table" and the Miyata Expires March 29, 2009 [Page 14] Internet-Draft sNAT-PT September 2008 packet is translated to IPv6. The translation parameters are cached for the duration of the session and the IPv6 to IPv6 mapping is retained by NAT-PT. The resulting IPv6 packet has SA=PREFIX::192.0.2.12 and DA=2001:DB8:b:a::7654:3210. 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 as follows. SA=10.0.0.10, DA=192.0.2.12. 5.2.2 Port-Mapping Operation Basic Bi-directional-NAT-PT maps one IPv4 address to one IPv6 address. Port-Mapping requires to map one pair of IPv4 address and port to one pair of IPv6 address and port. Say the IPv4-C wants to access to http service on the IPv6-A. Somehow IPv4 address and TCP port pair (10.0.0.10, 30080) are mapped to the IPv6 address and TCP port pair(2001:DB8:b:a::7654:3210, 80), and IPv4-C knows the mapped pair. Actually, the method how to inform the mapped information is out of scope of this document. But several method could be considered. for example, the administrator of the server advertise it to the users manually(most primitive method). or if the application uses some protocol to negotiate the session initiation, the proxy of the application can configure the mapping to translator and inform it to client application. Then, the IPv4-C creates a packet with: SA=192.0.2.12, source TCP port = 1025 DA=10.0.0.10, destination TCP port = 30080 The packet is routed via the NAT-PT gateway, where it is translated to IPv6. The translated packet is; SA=PREFIX::192.0.2.12, source TCP port = 1025 DA=2001:DB8:b:a::7654:3210, destination TCP port = 80 The returning traffic from 2001:DB8:b:a::7654:3210, TCP port 80 will be recognized as belonging to the same session and will be translated back to IPv6 as follows: SA=2001:DB8:b:a::7654:3210 , source TCP port = 80 DA=PREFIX::192.0.2.12, destination TCP port = 1025 And it should be translated as follows: SA=10.0.0.10, source TCP port = 30080 DA=192.0.2.12, destination TCP port = 1025 Miyata Expires March 29, 2009 [Page 15] Internet-Draft sNAT-PT September 2008 6. IPv6 Address mapping An IPv6 address MUST be mapped to an IPv4 address by prepending Dummy Prefix to the IPv4 address. The format MUST be as [PREFIX]::[IPv4 address]. The address can be automatically calculated. 7. IPv4 Address mapping IPv4 address mapping can be done by either statically or dynamically. To map dynamically some ALGs are required. The ALG could be DNS-ALG, SIP-ALG, FTP-ALG etc... The specification of ALG is various, it depends on application. This document is attempting to remove the dependency on specific application. So the specifications of ALGs are out of scope of this document. The borderline between ALG and NAT-PT gateway is "Address Mapping Table" and "Translation Rule Table". This documents describes the behavior after the entry in both tables are set. For the NAT-PT gateway, the behavior for both static entry and dynamic one are almost same. Only the difference is expiration of the entry based on the value of Stability field of "Address Mapping Table". If the value of Stability field indicate Dynamic, the entries in these tables MUST be maintained as described in chapter 3. 8. Protocol Translation Details The IPv4 and ICMPv4 headers are similar to their IPv6 counterparts but a number of field are either missing, have different meaning or different length. NAT-PT SHOULD translate all IP/ICMP headers from IPv4 to IPv6 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. Some application requires ALG to complete its communication. FTP-ALG, for example, would make to FTP payload as an FTP packet traverses from IPv4 to IPv6 realm or vice versa. But any kind of ALG is out of scope of this document. Miyata Expires March 29, 2009 [Page 16] Internet-Draft sNAT-PT September 2008 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. 8.1 Translating 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 IPv4 communications. Addresses using this PREFIX will be routed to the NAT-PT gateway (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. 8.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 a mapped IPv4 address. The IPv6 source address is replaced by the IPv4 address retained in that mapping. Destination Address: The original 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. 8.3 TCP/UDP/ICMP Checksum Update NAT-PT retains mapping between IPv6 address and an IPv4 address. This mapping is used in the translation of packets that go through NAT-PT gateway. The following sub-sections describe TCP/UDP/ICMP checksum update procedure in NAT-PT, as packets are translated from IPv4 to IPv6 and vice versa. Miyata Expires March 29, 2009 [Page 17] Internet-Draft sNAT-PT September 2008 8.3.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 IPv4 to IPv6. 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 IPv4 to IPv6 address. When the checksum of a IPv4 UDP packet is set to zero, NAT-PT MUST evaluate the checksum in its entirety for the IPv6-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. 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. 8.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv4 TCP and UDP checksums SHOULD be recalculated to reflect the address change from IPv6 to IPv4. 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 IPv6 to IPv4 addresses. For UDP packets, optionally, the checksum may simply be changed to zero. The checksum calculation for a IPv4 ICMP header needs to be derived from the IPv6 ICMP header by running the checksum adjustment algorithm [RFC3022] to remove the IPv6 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. 8.4 ICMP translation The ICMP translation is described in [RFC2765], It is based on previous RFC for ICMPv6[RFC2463]. And it is obsoleted by [RFC4443]. So the description of ICMP translation needs to be revised. Miyata Expires March 29, 2009 [Page 18] Internet-Draft sNAT-PT September 2008 8.4.1 ICMP translation from IPv4 to IPv6 There are no additional type and code for ICMPv4 after 2765. So, no change is required. 8.4.2 ICMP translation from IPv6 to IPv4 [RFC4443] additionaly assigned the type 100, 101, 200 and 201. There is not common meaming of them, So, the translator SHOULD silently drop them. And the translator MAY have the interface to confiigure correspoondent IPv4 type and code only for private experimentation purpose. Other added code should be dealed as follows. Destination Unreachable (Type 1), Code 2 - Beyond scope of source address Set Code to 1 (host unreachable). This would happen by mis-configuration of Dummy Prefix. So, the translator SHOULD inform the issue to its administrator somehow. Code 5 - Source address failed ingress/egress policy Set Code to 1 (host unreachable). Code 6 - Reject route to destination Set Code to 1 (host unreachable). 9. Host Implementation This specification does not require any additional function to use NAT-PT gateway. So current existing IPv6 devices can use NAT-PT gateway. However, if IPv6 devices implement some functionality it can resolve some issues listed on [RFC4966]. e.g., Client application can display dialog to indicate users that the there is a translator in the path. Server application detect the existence of translator in the path. Then it can select the behavior according to the pre-defined policy. The detail behavior should be described in higher version or individual document. Miyata Expires March 29, 2009 [Page 19] Internet-Draft sNAT-PT September 2008 NOTE: The method how to identify the synthetic address is shown in Chapter 4 and 13. [ID-bagnulo] also mentioned the another approach, DNS option namely SAS. Basically, from the layer point of view, those ideas are not so different. The better method should be discussed. 10. Application Layer Gateway support Some applications contain IP address in payload of the packet to initiate a new session. In such case, the translation rule should be configured dynamically. To allow this, ALG is required and the communication method between ALG and NAT-PT gateway is required. NAT-PT gateway needs the information in both "Address Mapping Table" and "Translation Rule Table". The protocol between NAT-PT gateway and ALG is TBD. 11. NAT-PT Limitations and Future Work 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. 11.1 Load Balance Once we separate ALGs from NAT-PT gateway, load balance is easily achieved. For smarter dynamic load balance, ALG and NAT-PT gateway SHOULD have communication method to share the load of NAT-PT gateways as described in [ID-endo]. Anyway the ALG will inform some informations to NAT-PT gateway to be stored in "Address Mapping Table" and "Translation Rule Table". The purpose of this document is describing the behavior after those informations have been set. So load balance is out of the scope of this document. 11.2 Redundancy The router redundancy technology is defined in [RFC3768]. It is called "Virtual Router Redundancy Protocol"(VRRP). But it is not enough to provide redundancy, because NAT-PT gateway MUST maintain the state of each session and rule. So, status synchronization technology would be required in addition to VRRP. It is clear that the status synchronization technology MUST synchronize the information in all of "Address Mapping Table", Miyata Expires March 29, 2009 [Page 20] Internet-Draft sNAT-PT September 2008 "Translation Rule Table" and "Session Status Table". So, the redundancy can be provide by extending sNAT-PT. But it is out of the scope of this document. 11.3 SCTP SCTP is the useful protocol for the stable communications. If the two pathes use the different translator, the associations can be stable as expected. And it is possible by using different Dummy Prefix for each destination address. On the other hand, SCTP is possible to add independetly from other tranport protocols. And as [ID-jennings] mentioned it is not the time to support it, since even IPv4-IPv4 NAT does not support it. So, it should be considered later, considering the consistency of IPv4-IPv4 NAT. 11.4 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 has unique Dummy Prefix to a stub domain, where all IP packets are either originated from the domain or destined to the domain. 11.5 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. Details of IPv4 to IPv6 Protocol Translation can be found in [RFC2765]. 11.6 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]. 11.7 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. Miyata Expires March 29, 2009 [Page 21] Internet-Draft sNAT-PT September 2008 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. 11.8 Multicast Translation The packet translation of multicast is almost same as unicast case. The Bi-directional-NAT-PT gives the hint of the method. The multicast translation requires two mapping of destination multicast addresses and source addresses. 11.8.1 The translation of multicast from IPv6 to IPv4 The IPv4 multicast address MUST be assigned to the IPv6 multicast address somehow. Also, the IPv4 address MUST be assinged to the IPv6 address of the sendor. These mapping can be done manually at least. The well-known address like the addresses assigned to ntp serveice MUST be mapped to the correspondent addresses. Following example shows the case when IPv6-A sends a multicast packet addressed to ff08::101. The address 224.0.1.1 MUST be assigned to ff08::101. and 10.0.0.10 must be assinged to 2001:DB8:b:a::7654:3210. SA=2001:DB8:b:a::7654:3210 and DA=ff08::101 The translator translates the packet as follows; SA=10.0.0.10 and DA=224.0.1.1 To make the packet addressed to the IPv6 multicast address reach the the translator, the translator MUST join for the correspondent address. When the configuration was removed the translator must send leave as well. 11.8.2 The translation of multicast from IPv4 to IPv6 The IPv6 multicast address MUST be assigned to the IPv4 multicast address somehow. The IPv6 address to be assinged to the IPv4 address of the sendor is calucurated by prependig the Dummy Prefix to the original IPv4 address. The well-known address like the addresses assigned to ntp server MUST be mapped to the correspondent addresses. To make the packet addressed to the IPv4 multicast address reach the the translator, the translator MUST join for the correspondent address. Miyata Expires March 29, 2009 [Page 22] Internet-Draft sNAT-PT September 2008 When the configuration was removed the translator must send leave as well. 11.9 Twice NAT-PT Theoretically, it should work well. Further investigation should be done later. 12. Applicability Statement NAT-PT is a very useful tool to provide communication between IPv6 Only Node and IPv4 Only Node. When only the communication which IPv6 Only Node initiate is required, NAPT-PT is useful because it requires few IPv4 address. In this direction, the Translation engine can work separately from ALGs. But, as [ID-bagnulo] and [ID-endo] introduced, DNS-ALG like service, which provide synthetic address, should be helpful. Such kind of service does not need to intercommunicate with Translation Engine. They just need to share Dummy Prefix. i.e., The introduced Translation Engine can work with totd, which deos not have any interface to intercommunicate with Translation Engine. It is same as TRT. TRT itself can work alone, but using totd should be very helpful. NOTE: This document takes the same approach as TRT, Basically the Translation Engine can work alone. Some kind of ALGs are considered as the utility services. NOTE: Totd is a famous DNS proxy implementation, which can generate synthetic address using pre-configured Dummy Prefix. The packets, addressed to the synthetic address, arrive to the appropriate Translation Engine, which is pre-configured the same Dummy Prefix. Usually, totd attempts to provide non-synthetic address first. If it is impossible it attempts to provide synthetic address. Though it is designed to work with TRT, it works with sNATPT for the communication initiated by IPv6 Only node. The most primitive usage is manual configuration. If the application allows to specify the address directly, the user can specify the synthetic address. Also, if an administrator wants to provide some services to IPv6 Only Node which works on IPv4 Only Node. The administrator can configure the actual DNS RR using synthetic address. This usage could occur when the Translation Engine is placed in front of the servers. Miyata Expires March 29, 2009 [Page 23] Internet-Draft sNAT-PT September 2008 NOTE: There are two kinds of typical usage at least. One is placing the Translation Engine in front of the clients, around the entrance/exit of enterprise network. The other one is placing Translation Engine in front of the servers. When the communication needs to be able to initiated by either IPv4 Only Node or IPv6 Only Node, Bi-Directional-NAT-PT is helpful. The Bi-directional-NAT-PT can work with statically configured address mapping. Also, when using Bi-Directional-NAT-PT, ALG should be helpful. Some ALG can be implemented inside the Translation Engine(Fig. 3.1). Some ALG can be implemented outside the Translation Engine. Moreover it can be implemented outside the NAT-PT gateway. sNAT-PT provides very basic functions. So, it has some limitations when it works alone. But it can be helpful when it is combined with some other technologies. 13. IANA Considerations The Dummy Prefix format is described in Fig. 4.1. The 32-bit, represented as IDENT in Fig. 4.1, MUST be the value which indicates that this address is synthesis address. IANA has assigned FE under their OUI(00-00-5E) to indicate that an IPv4 address is encoded in following 32-bit as represented in Fig.13.1. According to the definition, it could be used for NAT-PT technology as the address contains the encoded IPv4 address. 0 23 31 63 | OUI | 0xFE | IPv4 address | 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx Fig. 13.1 IPv4 embedded address Format This address is used by ISATAP [RFC5214], one of tunneling technologies. In RFC4966 it is stated that NAT-PT gateway existence in the path must be detected by the end-node, so same address SHOULD not used for NAT-PT. It is desired to assign another value to NAT-PT technology. Miyata Expires March 29, 2009 [Page 24] Internet-Draft sNAT-PT September 2008 14. Security Considerations Section 11.4 of this document states that 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. Finally, all of the security considerations described in [RFC2663] are applicable to this document as well. 15. References 15.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3022] P. Srisuresh and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. [RFC3768] R. Hinden, Ed, "Virtual Router Redundancy Protocol (VRRP)" , RFC 3768, April 2004. [RFC3142] J. Hagino and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001. [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)" , RFC 5214, March 2008. [RFC4443] A. Conta, S. Deering, M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4966] C. Aoun, E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator", RFC 4966, July 2007. Miyata Expires March 29, 2009 [Page 25] Internet-Draft sNAT-PT September 2008 15.2 Informative References [RFC2463] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) specificagtion", RFC 2766, December 1998. [RFC2766] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [ID-bagnulo] M. Bangnulo, P. Matthews, I.van Beijnum,"NAT64/DNS64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-00, June 2008. [ID-endo] M. Endo, H. Miyata, "Translator Friendly DNS Proxy", draft-endo-v6ops-dnsproxy-00, August 2008. [ID-baker] X. Li, C. Bao, F. Baker, "IVI Update to SIIT and NAT-PT", draft-baker-behave-ivi-00, September 2008. [ID-jennings] C. Jennings, "NAT for IPv6-Only Hosts", draft-jennings-behave-nat6-00, July 2008. Miyata Expires March 29, 2009 [Page 26] Internet-Draft sNAT-PT September 2008 Appendix A: Changes from draft-miyata-v6ops-snatpt-01 (Sep. 8, 2008) o 2.2.2 Bi-Directional-NAT-PT was modified to support "Port-Mapping". o Add "NOTE" in Chapter 4. to discuss the Dummy Prefix. o In 5.1.2 NAT-PT Operation, "inbound NAPT-PT" description was removed. o 5.2 Bi-Directional-NAT-PT was separated into "5.2.1 Basic-Bidirectional-NAT-PT" and "5.2.2 Port-Mapping". o 5.2.2 Port-Mapping was added to improve the "inbound NAPT-PT" o 11.3 SCTP, fill the description. o 11.8 Multicast, fill the description. o 12. Applicability Statement. the 3rd NOTE and the last sentence were improved. o Correcting typos. Appendix B: Changes from draft-miyata-v6ops-snatpt-00 (Feb. 1, 2008) o In 5.2 Bi-directional NAT-PT, clarified the description on address mapping.Dynamic address mapping was removed.(Comment by Dan Wing) o Improve the description of conceptual figure. Fig. 3.1. o Add "NOTE" in Chapter 8. And based on it, add an informative reference. o Enriched Chapter "12. Applicability Statement". Adding example. o Correcting typos. Miyata Expires March 29, 2009 [Page 27] Internet-Draft sNAT-PT September 2008 Author's Address Hiroshi Miyata Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 JAPAN Email: h.miyata@jp.yokogawa.com M. Endo Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 JAPAN Email: masahito.endou@jp.yokogawa.com Miyata Expires March 29, 2009 [Page 28] Internet-Draft sNAT-PT September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Dan Wing gave me a comment to improve this document. Miyata Expires March 29, 2009 [Page 29]