IPv6 Operations I. van Beijnum Internet-Draft October 17, 2007 Expires: April 17, 2008 Enhanced Stateless IP/ICMP Translation Algorithm (ESIIT) draft-van-beijnum-v6ops-esiit-00 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 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an extension to the mechanism outlined in RFC 2765 that allows IPv4 hosts to communicate with IPv6 hosts through a protocol translation device with full IPv6 compatibility. For this purpose, a new header is inserted between the IP header and the payload protocol such as TCP and UDP. The new header contains the bits truncated from the IPv6 address when the IPv6 address is translated into an IPv4 address in the 240.0.0.0/4 (class E) range. Van Beijnum Expires April 17, 2008 [Page 1] Internet-Draft Enhanced SIIT (ESIIT) October 17, 2007 1 Translation The SIIT device translates IPv6 packets into IPv4 packets and vice versa as outlined in RFC 2765. However, there are two differences: there is a fixed relationship between the IPv4 and IPv6 addresses, and there is an extra header. An IPv6 address is translated into an IPv4 address by taking bits 4 - 31 from the IPv6 address and placing them in bits 4 - 31 in the IPv4 address. Bits 0 - 3 are set to 1111 in the IPv4 address. When converting in the other direction, bits 0 - 3 in the IPv6 address are set to 0010. This means that only IPv6 addresses in the range 2000::/4 can be translated. If an IPv4 packet has only a source address in the 240.0.0.0/4 range, this indicates that the 96 bits immediately following the IPv4 header are copied from bits 32 - 127 from the original IPv6 source address. If an IPv4 packet has only a destination address in the 240.0.0.0/4 range, this indicates that the 96 bits immediately following the IPv4 header are copied from bits 32 - 127 from the original IPv6 destination address address. If an IPv4 packets has IPv4 source and destination addresses that both fall inside the 240.0.0.0/4 range, the 96 bits immediately following the IPv4 header are copied from bits 32 - 127 from the original IPv6 source address, followed by 96 bits copied from bits 32 - 127 from the original IPv6 destination address address. In each case, the next protocol header is moved up 96 or 192 bits. The original value of the protocol / next header field in the IP header is retained; the presence of the extra bits is solely indicated by the value of the upper bits in the source and/or destination addresses. Unlike original RFC 2765 SIIT translation, it is necessary to adjust the TCP or UDP checksum during the ESIIT translation stage. 2 Modifications to IPv4 Hosts In order to be able to use the mechanism described here to communicate with IPv6 hosts, IPv4 hosts MUST recognize the 240.0.0.0/4 prefix and process the extra address bits as outlined above accordingly. The TCP/IP stack in the host can operate in two modes: 1. IPv4-compatible: in this mode, the extra address bits are hidden from the application. However, the TCP/IP stack makes sure that when sending packets in reply to earlier packets with the extra address bits in them, the reply packets also contain the extra bits so the reply packets can be translated back into IPv6 packets that can be sent back to the original source host without the need for the SIIT device to maintain state. There is a slight chance that Van Beijnum Expires April 17, 2008 [Page 2] Internet-Draft Enhanced SIIT (ESIIT) October 17, 2007 two IPv6 hosts with the same upper 32 address bits use the same TCP or UDP port numbers which makes their sessions look identical without considering the extra address bits that IPv4 applications won't have access to. Implementations SHOULD have a mechanism for operators to select whether these seemingly duplicate sessions are accepted or rejected. Applications that embed IPv4 addresses in their protocols can't successfully operate in this mode. 2. IPv6-compatible: in this mode, the TCP/IP stack internally translates between the IPv4 header with extra address bits and IPv6 addresses in order to present regular IPv6 addresses to the application. The application uses normal IPv6 semantics. I.e., an application that embeds IP addresses proceeds to embed IPv6 addresses rather than IPv4 addresses in this case. The IPv6 address of the host is the IPv4 address preceded by 96 0-bits in this case. IPv4 hosts implementing ESIIT MUST consider the length of packets generated both in ESIIT and in native IPv6 format for the purposes of MTU and MSS limitations. Packets between an IPv4 host and an IPv6 host have a 40-byte IPv6 header in IPv6 format but the IPv4 header and extra address bits are only 32 bytes in IPv4 ESIIT format. This means that IPv4 packets must be 8 bytes smaller than the maximum size the IPv6 host and the IPv6 part of the network path can handle. 3 Operation When operators are satisfied that all devices in the path that look beyond the IPv4 header support the mechanism, they can add AAAA records to the DNS for hosts that either run applications that use IPv4 semantics but only use IP version agnostic protocols (e.g., that don't embed IPv4 addresses) and/or IPv6-compatible applications. To IPv6 hosts, these IPv4 hosts with ESIIT capability are located in the ::/96 prefix. If this prefix isn't routed to an ESIIT translator device, the ESIIT-compatible IPv4 addresses will be unreachable. This is somewhat suboptimal, but the author is of the opinion that using a DNS ALG or other mechanism to make sure that ESIIT-compatible IPv4 addresses remain hidden in this case are more harmful than the non-obviousness of the lack of connectivity. Placement of translation devices is important, because translation needs to happen in two directions. A logical place for this to happen would be in service provider networks. Service providers have /32 or shorter IPv6 prefixes, so a prefix falling inside 240.0.0.0/4 can be inserted into IPv4 routing to attract IPv4 packets towards IPv6 destinations and a ::/96 prefix can be inserted on the IPv6 side. However, end-users can also run their own translators in at least one direction. Van Beijnum Expires April 17, 2008 [Page 3] Internet-Draft Enhanced SIIT (ESIIT) October 17, 2007 IPv6 hosts implementing an RFC 3484 policy table SHOULD give the ::/96 a sufficiently low priority that real IPv4 (or IPv6) connectivity is preferred over ESIIT IPv4. 4 Discussion Alternative ways to encode the extra IPv6 address bits in IPv4 packets would be: 1. Use a full header with a length and next header field 2. Stuff the bits in a TCP option These could be more compatible with existing implementations and would be capable of encoding all 128 bits of the IPv6 address rather than just 124 bits. Limitations on which more specific prefixes in ::/96 may be injected into the IPv6 global routing table are desireable to avoid importing the full IPv4 routing table into the IPv6 one. 5 IANA Considerations IANA is asked to reclassifity 240.0.0.0/4 for ESIIT use. 6 Security Considerations The insertion of address bits where devices that don't implement ESIIT expect protocol headers has the potential to confuse devices enforcing security policies. As such, it is highly recommended that such devices are updated to support ESIIT. Non-conforming implementations SHOULD be configured to filter out all packets with source and/or destination addresses in the 240.0.0.0/4 range. 5 Document and Author Information This document expires April, 2008. The latest version will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the v6ops mailinglist or directly to the author: Iljitsch van Beijnum Email: iljitsch@muada.com Van Beijnum Expires April 17, 2008 [Page 4] Internet-Draft Enhanced SIIT (ESIIT) October 17, 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Van Beijnum Expires April 17, 2008 [Page 5]