--- 1/draft-ietf-ngtrans-header-trans-00.txt 2006-02-05 00:50:06.000000000 +0100 +++ 2/draft-ietf-ngtrans-header-trans-01.txt 2006-02-05 00:50:06.000000000 +0100 @@ -1,16 +1,17 @@ + INTERNET-DRAFT Erik Nordmark, Sun Microsystems -July 30, 1997 +November 20, 1997 - Site prefixes in Neighbor Discovery + Stateless IP/ICMP Translator (SIIT) - + Status of this Memo This document is an Internet-Draft. 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 @@ -18,83 +19,88 @@ material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. - This Internet Draft expires January 30, 1998. + This Internet Draft expires May 20, 1998. Abstract This document specifies a transition mechanism in addition to those already specified in RFC 1933. The new mechanism can be used as part of a solution that allows IPv6 hosts that do not have a permanently assigned IPv4 address to communication with IPv4-only hosts. Acknowledgements Some text has been pulled from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. - Gilligan, E. Nordmark, and B. Hinden. + Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the + figures for Section 1. Contents Status of this Memo.......................................... 1 - 1. INTRODUCTION AND MOTIVATION.............................. 2 - 1.1. Applicability and Limitations....................... 4 - 1.2. Impact Outside the Network Layer.................... 5 + 1. INTRODUCTION AND MOTIVATION.............................. 3 + 1.1. Applicability and Limitations....................... 5 + 1.2. Impact Outside the Network Layer.................... 6 - 2. TERMINOLOGY.............................................. 6 - 2.1. Requirements........................................ 6 + 2. TERMINOLOGY.............................................. 7 + 2.1. Requirements........................................ 8 - 3. OVERVIEW................................................. 6 - 3.1. Assumptions......................................... 7 + 3. OVERVIEW................................................. 8 + 3.1. Assumptions......................................... 8 - 4. TRANSLATING FROM IPv4 TO IPv6............................ 7 - 4.1. Translating IPv4 Headers............................ 8 - 4.2. Translating ICMPv4.................................. 10 - 4.3. Translating ICMPv4 Error Messages................... 12 - 4.4. Knowing when to Translate........................... 13 + 4. TRANSLATING FROM IPv4 TO IPv6............................ 9 + 4.1. Translating IPv4 Headers............................ 10 + 4.2. Translating ICMPv4.................................. 12 + 4.3. Translating ICMPv4 Error Messages................... 14 + 4.4. Knowing when to Translate........................... 14 - 5. TRANSLATING FROM IPv6 TO IPv4............................ 13 - 5.1. Translating IPv6 Headers............................ 14 - 5.2. Translating ICMPv6.................................. 16 - 5.3. Translating ICMPv6 Error Messages................... 17 - 5.4. Knowing when to Translate........................... 18 + 5. TRANSLATING FROM IPv6 TO IPv4............................ 15 + 5.1. Translating IPv6 Headers............................ 16 + 5.2. Translating ICMPv6.................................. 18 + 5.3. Translating ICMPv6 Error Messages................... 19 + 5.4. Knowing when to Translate........................... 20 - 6. SECURITY CONSIDERATIONS.................................. 18 + 6. SECURITY CONSIDERATIONS.................................. 20 - REFERENCES................................................... 19 + 7. OPEN ISSUES.............................................. 20 - AUTHOR'S ADDRESS............................................. 20 + REFERENCES................................................... 21 + + AUTHOR'S ADDRESS............................................. 22 + + APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 22 1. INTRODUCTION AND MOTIVATION The transition mechanisms specified in [TRANS-MECH] handle the case of dual IPv4/IPv6 hosts interoperating with both dual hosts and IPv4-only hosts which is needed early in the transition to IPv6. The dual hosts are assigned both an IPv4 and one or more IPv6 addresses. As the pool of globally unique IPv4 addresses becomes smaller and smaller as the Internet grows there will be a desire to take advantage of the large IPv6 address and not require that every new Internet node have a permanently assigned IPv4 address. There are several different scenarios where there might be IPv6-only - hosts that need to communicate with IPv4-only hosts. [Note: the - terminology is somewhat unclear is this area. Is a node with that - implements both IPv4 and IPv6 but has no IPv4 address assigned to any - of its interfaces a dual host or an IPv6-only host?] + hosts that need to communicate with IPv4-only hosts. These IPv6 + hosts might be IPv4-capable, i.e. include an IPv4 implementation but + not be assigned an IPv4 address, or they might not even include an + IPv4 implementation. - A completely new network with new devices that all support IPv6. In this case it might be beneficial to not have to configure the routers within the new network to route IPv4 since none of the hosts in the new network are configured with IPv4 addresses. But these new IPv6 devices might occasionally need to communicate with some IPv4 nodes out on the Internet. - An existing network where a large number of IPv6 devices are added. The IPv6 devices might have both an IPv4 and an IPv6 @@ -119,33 +125,63 @@ a solution would require the pool of temporary IPv4 addresses to be partitioned across all the subnets in the cloud which would either require a larger pool of IPv4 addresses or result in cases where communication would fail due to no available IPv4 address for the node's subnet. This document specifies a mechanism by which IPv6-only nodes can interoperate with IPv4-only nodes by having the IPv6-only nodes somehow acquire a temporary IPv4 address. That IPv4 address will be used as an IPv4-compatible IPv6 address and the packets will travel - through a stateless IP header translator that will translate the - packet headers between IPv4 and IPv6 and translate the addresses in - those headers between IPv4 addresses on one side and IPv4-compatible - or IPv4-mapped IPv6 addresses on the other side. + through a stateless IP/ICMP translator that will translate the packet + headers between IPv4 and IPv6 and translate the addresses in those + headers between IPv4 addresses on one side and IPv4-compatible or + IPv4-mapped IPv6 addresses on the other side. This specification does not cover how an IPv6 node can acquire a temporary IPv4 address and how such a temporary address be registered in the DNS. The DHCP protocol, perhaps with some extensions, could probably be used to acquire temporary addresses with short leases but that is outside the scope of this document. The mechanism for routing this temporary IPv4 address (or the IPv4-compatible IPv6 address) in the site is currently not specified in this document. + The figures below show how the Stateless IP/ICMP Translator (SIIT) + can be used initially for small networks (e.g., a single subnet) and + later for a site which has IPv6-only hosts in a dual IPv4/IPv6 + network. This use assumes a mechanism for the IPv6 nodes to acquire + an temporary address from the pool of IPv4 addresses. Note that SIIT + is not likely to be useful later during transition when most of the + Internet is IPv6 and there are only small islands of IPv4 nodes, + since such use would either require the IPv6 nodes to acquire + temporary IPv4 addresses from a "distant" SIIT box operated by a + different administration, or require that the IPv6 routing contain + routes for IPv6-mapped addresses. (The latter is known to be a very + bad idea.) + + ___________ + / \ + [IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host] + | \___________/ + (pool of v4 addresses) + + Figure 1. Using SIIT for a single IPv6-only subnet. + + ___________ ___________ + / \ / \ + [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host] + \___________/ | \___________/ + (pool of v4 addresses) + + Figure 2. Using SIIT for an IPv6-only or dual cloud (e.g. a site) + which contains some IPv6-only hosts as well as IPv4 hosts. + 1.1. Applicability and Limitations The IPv6 protocol [IPv6] has been designed so that the transport pseudo-header checksums are not affected by such a translation thus the translator does not need to modify TCP and UDP headers. However, ICMPv6 include a pseudo-header checksum but it is not present in ICMPv4 thus the checksum in ICMP messages need to be modified by the translator. In addition, ICMP error messages contain an IP header as part of the payload thus the translator need to rewrite those parts of the packets to make the receiver be able to understand the @@ -178,31 +214,40 @@ messages) packets encrypted using ESP in Transport-mode can be carried through the translator. [Note that this assumes that the key management can operate between the IPv6-only and the IPv4-only node.] The use of AH headers is more complex since the AH computation covers most of the fields in the IP header. Should it be possible for the IPv6 node to predict the value of all the IPv4 header fields on the other side of the translator then the IPv6 node could calculate the authentication data using an IPv4 header instead of the IPv6 header even though it is sending and receiving IPv6 packets. [Currently this is not possible since the IP fragment identification field is - not carried end-to-end through the translator in all cases.] For ESP - Tunnel-mode the IPv6 node would have to be able to parse and generate - "inner" IPv4 headers since the inner IP will be encrypted together - with the transport protocol. + not carried end-to-end through the translator in all cases. This + could be resolved by changing AH to not include the fragment + identification field in the AH computation for either IPv4 or IPv6.] + For ESP Tunnel-mode the IPv6 node would have to be able to parse and + generate "inner" IPv4 headers since the inner IP will be encrypted + together with the transport protocol. + + IPv4 multicast addresses can not be mapped to IPv6 multicast + addresses. For instance, ::ffff:224.1.2.3 is an IPv4 mapped IPv6 + address with a class D address, however it is not an IPv6 multicast + address. While the IP/ICMP translation aspect of this draft works + for multicast packets this address mapping limitation makes it hard + to the techniques in this draft for multicast traffic. 1.2. Impact Outside the Network Layer - The potential existence of header translators is already taken care - of from a protocol perspective in [IPv6]. However, an IPv6 node that - wants to be able to use translators need some additional logic in the - network layer. + The potential existence of stateless IP/ICMP translators is already + taken care of from a protocol perspective in [IPv6]. However, an + IPv6 node that wants to be able to use translators need some + additional logic in the network layer. The network layer in an IPv6-only node when presented with either an IPv4 destination address or an IPv4-mapped IPv6 destination address by the application is likely to drop the packet and return some error message to the application. In order to take advantage of translators such a node should instead send an IPv6 packet where the destination address is the IPv4-mapped address and the source address is the nodes temporarily assigned IPv4-compatible address. If the node does not have a temporarily assigned IPv4-compatible address it should acquire one using mechanisms that are not discussed in this @@ -234,21 +279,41 @@ generation of the IPv4 packets takes place in the sending node. In an IPv6-only node conceptually the only difference is that the IPv4 packet is generated by the translator - all the information that the transport layer passed to the network layer will be conveyed to the translator in some form. That form just "happens" to be in the form of an IPv6 header. 2. TERMINOLOGY This documents uses the terminology defined in [IPv6] and [TRANS- - MECH]. + MECH] with these clarifications: + + IPv4 capable node: + + A node which has an IPv4 protocol stack. In order + for the stack to be usable the node must be assigned + one or more IPv4 addresses. + + IPv4 enabled node: A node which has an IPv4 protocol stack + and is assigned one or more IPv4 addresses. Both + IPv4-only and IPv6/IPv4 nodes are IPv4 enabled. + + IPv6 capable node: + + A node which has an IPv6 protocol stack. In order + for the stack to be usable the node must be assigned + one or more IPv6 addresses. + + IPv6 enabled node: A node which has an IPv6 protocol stack + and is assigned one or more IPv6 addresses. Both + IPv6-only and IPv6/IPv4 nodes are IPv6 enabled. 2.1. Requirements 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 [KEYWORDS]. 3. OVERVIEW The protocol translators are assumed to fit around some piece of @@ -296,21 +361,21 @@ +-------------+ +-------------+ | | | Transport | ~ Data ~ | Layer | | | | Header | +-------------+ +-------------+ | | ~ Data ~ | | +-------------+ - IPv4-to-IPv6 Header Translation + IPv4-to-IPv6 Translation 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. When the IPv4 node performs path MTU discovery (by setting the DF bit in the header) the path MTU discovery can operate end-to-end i.e. across the translator. In this case either IPv4 or IPv6 routers might send back ICMP "packet too big" messages to the sender. When @@ -417,22 +482,22 @@ More Fragments bit copied from the IPv4 header. Identification: The low-order 16 bits copied from the Identification field in the IPv4 header. The high-order 16 bits set to zero. 4.2. Translating ICMPv4 All ICMP messages that are to be translated require that the ICMP - checksum field be updated as part of the translation since ICMPv6 has - a pseudo-header checksum just like UDP and TCP. + 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 needs 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: ICMPv4 query messages: Echo and Echo Reply (Type 8 and Type 0) @@ -479,23 +544,26 @@ Code 2: Translate to an ICMPv6 Parameter Problem (Type 4, Code 1) and make the Pointer point to the IPv6 Payload Type field. Code 3: Set Code to 4 (port unreachable). Code 4: Translate to an ICMPv6 Packet Too Big message (Type 2) with code 0. The MTU field needs to be adjusted for the difference between the IPv4 and IPv6 header sizes. - [TBD: What if the IPv4 router did not set the MTU field - i.e. does not implement [PMTUv4]. Should the translator - use the plateau values as specified?] + Note that if the IPv4 router did not set the MTU field + i.e. the router does not implement [PMTUv4], then the + translator must use the plateau values specified in + [PMTUv4] to determine a likely path MTU and include that + path MTU in the ICMPv6 packet. (Use the greatest plateau + value that is less than the returned Total Length field.) Code 5: Set Code to 2 (not a neighbor). Code 6,7: Set Code to 0 (no route to destination). Code 8: Set Code to 0 (no route to destination). Code 9, 10: Set Code to 1 (communication with destination administratively prohibited) @@ -533,37 +601,37 @@ +-------------+ +-------------+ | IPv4 | ===> | IPv6 | | Header | | Header | +-------------+ +-------------+ | Partial | | Partial | | Transport | | Transport | | Layer | | Layer | | Header | | Header | +-------------+ +-------------+ - IPv4-to-IPv6 ICMP Error Header Translation + IPv4-to-IPv6 ICMP Error Translation The translation of the inner IP header can be done by recursively invoking the function that translated the outer IP headers. 4.4. Knowing when to Translate The translator is assumed to know the pool(s) of IPv4 address that are used to represent the internal IPv6-only nodes. Thus if the destination address falls in these configured sets of prefixes the packet needs to be translated to IPv6. 5. TRANSLATING FROM IPv6 TO IPv4 When an IPv6-to-IPv4 translator receives an IPv6 datagram addressed to an IPv4-mapped IPv6 address, it translates the IPv6 header of that - packet into an IPv7 header. It then forwards the packet based on the + packet into an IPv6 header. It then forwards the packet based on the IPv4 destination address. The original IPv6 header on the packet is removed and replaced by a IPv4 header. Except for ICMP packets the transport layer header and data portion of the packet are left unchanged. +-------------+ +-------------+ | IPv6 | | IPv4 | | Header | | Header | +-------------+ +-------------+ | Fragment | | Transport | @@ -572,21 +640,21 @@ +-------------+ +-------------+ | Transport | | | | Layer | ~ Data ~ | Header | | | +-------------+ +-------------+ | | ~ Data ~ | | +-------------+ - IPv6-to-IPv4 Header Translation + IPv6-to-IPv4 Translation 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 576 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 576. However, [IPv6] requires IPv6 nodes to handle such ICMP "packet too big" message by @@ -703,22 +772,22 @@ Fragment Offset: Copied from the Fragment Offset field in the Fragment Header. Protocol: Next Header value copied from Fragment header. 5.2. Translating ICMPv6 All ICMP messages that are to be translated require that the ICMP - checksum field be updated as part of the translation since ICMPv6 has - a pseudo-header checksum just like UDP and TCP. + 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 needs to have the Type value translated and for ICMP error messages the included IP header also needs translation. The actions needed to translate various ICMPv6 messages are: ICMPv6 informational messages: Echo Request and Echo Reply (Type 128 and 129) @@ -788,33 +857,53 @@ +-------------+ +-------------+ | IPv6 | ===> | IPv4 | | Header | | Header | +-------------+ +-------------+ | Partial | | Partial | | Transport | | Transport | | Layer | | Layer | | Header | | Header | +-------------+ +-------------+ - IPv6-to-IPv4 ICMP Error Header Translation + IPv6-to-IPv4 ICMP Error Translation The translation of the inner IP header can be done by recursively invoking the function that translated the outer IP headers. 5.4. Knowing when to Translate When the translator receives a IPv6 packet with an IPv4-mapped destination address the packet will be translated to IPv4. 6. SECURITY CONSIDERATIONS - TBD + The use of stateless IP/ICMP translators does not introduce any new + security issues beyond the security issues that are already present + in the IPv4 and IPv6 protocols and in the routing protocols which are + used to make the packets reach the translator. + +7. OPEN ISSUES + + - Can/should we make AH work through a translator e.g. by removing + the fragment ID field from the AH computation for both IPv4 and + IPv6? + + - For IPv6 to IPv4 should the Identification be something other than + zero to be more friendly to header compression? These packets + have DF set thus it is possible to choose e.g. a local + incrementing counter without adverse effects on reassembly. + + - IPv6 to IPv4 when source is pure IPv6 address. What should the + IPv4 source address be set to in order to make traceroute usable? + If such packets are not translated an IPv4 traceroute would show + no responses from IPv6 routers. We could use 127.0.0.1 or + 0.0.0.0. REFERENCES [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, January 1996. [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981. @@ -854,13 +943,22 @@ IP version 6", RFC 1981, August 1996. AUTHOR'S ADDRESS Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA - phone: +1 415 786 5166 - fax: +1 415 786 5896 + phone: +1 650 786 5166 + fax: +1 650 786 5896 email: nordmark@sun.com + +APPENDIX A: CHANGES SINCE PREVIOUS DRAFT + + The following changes have been made since version 00 of the draft. + + o Added clarification about applicability for multicast. + o Clarified the terminology with IPv4 capable vs. enabled etc. + o Changed the title to provide an acronym (SIIT). + o Added some figures to explain the applicability.