1. IP/ICMP Translation Algorithm (IIT) Xing Li, Congxiao Bao, Fred Baker 2008-11-17

2. 2 Abstract This document specifies an update to the Stateless IP/ICMP Translation Algorithm described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). The specification addresses both a stateful and a stateless mode. –In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment. –In the stateful mode, translation state is maintained between IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network. This document confines itself to the actual translation.

3. 3 Outline Introduction Scenario and Terminology Assumptions and Applicability Translating from IPv4 to IPv6 Translating from IPv6 to IPv4 Host operation New testing codes

4. 4 Introduction and motivation Dual stack is preferable. There are several different scenarios where there might be IPv6-only hosts that need to communicate with IPv4-only hosts. This document specifies a mechanism that is one of the components needed to make IPv6-only nodes interoperate with IPv4- only nodes.

5. 5 Scenario IPv6-onlyIPv4-only Xlate DNS IPv4 packetsIPv6 packets The IPv4 packets arrived in the IP/ICMP translator will be translated to IPv6 packets. –The translator translates the packet headers from IPv4 to IPv6 and translate the addresses in those headers from IPv4 addresses to IPv6 addresses. The IPv6 packets arrived in the IP/ICMP translator will be translated to IPv4 packets. –The translator translates the packet headers from IPv6 to IPv4 and translate the addresses in those headers from IPv6 addresses to IPv4 addresses.

6. 6 Assumptions The use of this translation algorithm assumes that the IPv6 network is somehow well connected. The translating function as specified in this document does not translate any IPv4 options and it does not translate IPv6 routing headers, hop-by-hop extension headers, or destination options headers. The translation of datagram containing TCP segments is described in [RFC5382]. Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e. the UDP checksum field is zero) are not of significant use over wide-areas in the Internet and will not be translated by the translator.

7. 7 Applicability At first sight it might appear that the IPsec functionality [RFC4301] can not be carried across the translator. However, since the translator does not modify any headers above the logical IP layer (IP headers, IPv6 fragment headers, and ICMP messages) packets encrypted using ESP in Transport-mode can be carried through the translator. IPv4 multicast addresses can not be mapped to IPv6 multicast addresses based on the unicast mapping rule. However, special rule can be created for the multicast packet translation.

8. 8 Translating from IPv4 to IPv6

9. 9 4  6 Address translation Source Address: –In both the stateless mode and the stateful mode, the IPv6 address is the IPv4-mapped IPv6 address, which embeds the IPv4 address as specified in [Framework]. Destination Address: –In stateless mode, which is to say that if the IPv4 destination address is within the range of the stateless translation prefix, the IPv6 address is the IPv4-mapped IPv6 address, which embeds the IPv4 address as specified in [Framework]. –In stateful mode, which is to say that if the IPv4 destination address is within the range of the stateful translation prefix, the IPv6 address and transport layer destination port corresponding to the IPv4 destination address and destination port are derived from the database reflecting current session state in the translator.

10. 10 4  6 Address translation examples IPv6-only IPv4-only Xlate src: 2001:250:ff12:b500:1f00:: dst: 2001:250:ffca:266c:0200:: src: 18.181.0.31 dst: 202.38.108.2 Stateless IPv6-only IPv4-only Xlate src: 2001:250:ff12:b500:1f00:: dst: 2001:da8:abcd::X#Q src: 18.181.0.31 dst: 166.111.1.1#P Stateful Mapping stable 166.111.1.1#P  2001:da8:abcd::X#Q LIR PrefixIPv4 addr 032407296127 Prefix part Host part 64 Entirely 0 Based on the algorithm Based on the state Based on the algorithm IPv4-mapped IPv6 addressunmapped IPv6 address

11. 11 ICMPv4 Headers  ICMPv6 Headers All ICMP messages that are to be translated require that the ICMP checksum field be updated as part of the translation since ICMPv6 unlike ICMPv4 has a pseudo- header checksum just like UDP and TCP. In addition all ICMP packets need to have the Type value translated and for ICMP error messages the included IP header also needs translation. The actions needed to translate various ICMPv4 messages are: –……

12. 12 ICMPv4 Error Messages  ICMPv6

13. 13 MTU and segmentation handling One of the differences between IPv4 and IPv6 is that in IPv6 path MTU discovery is mandatory but it is optional in IPv4. This implies that IPv6 routers will never fragment a packet - only the sender can do fragmentation. Other than the special rules for handling fragments and path MTU discovery the actual translation of the packet header consists of a simple mapping as defined below. Note that ICMP packets require special handling in order to translate the content of ICMP error message and also to add the ICMP pseudo-header checksum. If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the IPv4 packet MUST be fragmented prior to translating it. If the DF bit is set and the packet is not a fragment Header translation –…… If there is need to add a fragment header (the DF bit is not set or the packet is a fragment) the header fields are set as above with the following exceptions: –…… If a UDP packet has a zero UDP checksum then a valid checksum must be calculated in order to translate the packet. A stateless translator can not do this for fragmented packets but [MILLER] indicates that fragmented UDP packets with a zero checksum appear to only be used for malicious purposes. Thus this is not believed to be a noticeable limitation. When a translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero the translator SHOULD drop the packet and generate a system management event specifying at least the IP addresses and port numbers in the packet. When it receives fragments other than the first it SHOULD silently drop the packet, since there is no port information to log. When a translator receives an unfragmented UDP IPv4 packet and the checksum field is zero the translator MUST compute the missing UDP checksum as part of translating the packet. Also, the translator SHOULD maintain a counter of how many UDP checksums are generated in this manner.

14. 14 Knowing when to Translate The translator is assumed to know the address mapping algorithm and the IPv4 prefix range of the stateless translation in the stateless mode or the pool (s) of IPv4 address in the stateful mode. If the translator is implemented in a router providing both translation and normal forwarding, and the address is reachable by a more specific route without translation, the router should forward it without translating it. In general, however, if the IPv4 destination field contains an address that falls in these configured sets of prefixes the packet needs to be translated to IPv6.

15. 15 Translating from IPv6 to IPv4

16. 16 6  4 Address translation Source Address: –In stateless mode, IPv6 packets that are translated always have an IPv4-mapped IPv6 address. Thus the IPv4 address is derived from the IPv4-mapped IPv6 address as specified in [Framework]. –In stateful mode, IPv6 packets that are translated have an unmapped IPv6 address. The IPv4 source address and transport layer source port corresponding to the IPv6 source address and source port are derived from the database reflecting current session state in the translator as described in [nat64]. Destination Address: –In both the stateless mode and the stateful mode, IPv6 packets that are translated always have an IPv4-mapped IPv6 address. Thus the IPv4 address is derived from the IPv4-mapped IPv6 address as specified in [Framework].

17. 17 6  4 Address translation examples IPv6-only IPv4-only Xlate src: 2001:250:ffca:266c:0200:: dst: 2001:250:ff12:b500:1f00:: src: 202.38.108.2 dst: 18.181.0.31 Stateless IPv6-only IPv4-only Xlate src: 2001:da8:abcd::X#Q dst: 2001:250:ff12:b500:1f00:: src: 166.111.1.1#P dst: 18.181.0.31 Stateful Mapping stable 166.111.1.1#P  2001:da8:abcd::X#Q LIR PrefixIPv4 addr 032407296127 Prefix part Host part 64 Entirely 0 Based on the algorithm Based on the state Based on the algorithm IPv4-mapped IPv6 addressunmapped IPv6 address

18. 18 ICMPv6 Headers  ICMPv4 Headers All ICMP messages that are to be translated require that the ICMP checksum field be updated as part of the translation since ICMPv6 unlike ICMPv4 has a pseudo- header checksum just like UDP and TCP.

19. 19 ICMPv6 Error Messages  ICMPv4

20. 20 MTU and segmentation handling There are some differences between IPv6 and IPv4 in the area of fragmentation and the minimum link MTU that effect the translation. An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes. Thus, unless there were special measures, it would not be possible to do end-to-end path MTU discovery when the path includes an IPv6-to-IPv4 translator since the IPv6 node might receive ICMP "packet too big" messages originated by an IPv4 router that report an MTU less than 1280. However, [RFC2460] requires that IPv6 nodes handle such an ICMP "packet too big" message by reducing the path MTU to 1280 and including an IPv6 fragment header with each packet. This allows end-to-end path MTU discovery across the translator as long as the path MTU is 1280 bytes or greater. When the path MTU drops below the 1280 limit the IPv6 sender will originate 1280 byte packets that will be fragmented by IPv4 routers along the path after being translated to IPv4.[RFC2460]

21. 21 Knowing when to Translate If the translator is implemented in a router providing both translation and normal forwarding, and the address is reachable by a more specific route without translation, the router should forward it without translating it. Otherwise, when the translator receives an IPv6 packet with an IPv4-mapped destination IPv6 address the packet will be translated to IPv4.

22. 22 Host operation Interaction of IPv4-mapped IPv6 addresses with RFC3484 address selection –IPv6 systems should select source and destination addresses that are as similar as possible. IPv6-only systems with IPv4-mapped IPv6 addresses to connect from their IPv4-mapped IPv6 address when communicating with IPv4-only systems. This is important, because it promotes stateless translation operation. The IPv4-mapped IPv6 address systems may also find the IPv4-mappded IPv6 address pair "most similar" when communicating with other systems with IPv4-mapped IPv6 addresses.

23. 23 New testing code of Xlate http://www.ivi2.org/IVI/ http://www.ivi2.org/IVI/