Stateless IP/ICMP Translation Algorithm (SIIT)
RFC 2765
Document | Type |
RFC - Proposed Standard
(February 2000; No errata)
Obsoleted by RFC 6145
|
|
---|---|---|---|
Author | Erik Nordmark | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2765 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group E. Nordmark Request for Comments: 2765 Sun Microsystems Category: Standards Track February 2000 Stateless IP/ICMP Translation Algorithm (SIIT) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. Acknowledgements This document is a product of the NGTRANS working group. Some text has been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for Section 1. Keith Moore provided a careful review of the document. Nordmark Standards Track [Page 1] RFC 2765 SIIT February 2000 Table of Contents 1. Introduction and Motivation.............................. 2 1.1. Applicability and Limitations....................... 5 1.2. Assumptions......................................... 7 1.3. Impact Outside the Network Layer.................... 7 2. Terminology.............................................. 8 2.1. Addresses........................................... 9 2.2. Requirements........................................ 9 3. Translating from IPv4 to IPv6............................ 9 3.1. Translating IPv4 Headers into IPv6 Headers.......... 11 3.2. Translating UDP over IPv4........................... 13 3.3. Translating ICMPv4 Headers into ICMPv6 Headers...... 13 3.4. Translating ICMPv4 Error Messages into ICMPv6....... 16 3.5. Knowing when to Translate........................... 16 4. Translating from IPv6 to IPv4............................ 17 4.1. Translating IPv6 Headers into IPv4 Headers.......... 18 4.2. Translating ICMPv6 Headers into ICMPv4 Headers...... 20 4.3. Translating ICMPv6 Error Messages into ICMPv4....... 22 4.4. Knowing when to Translate........................... 22 5. Implications for IPv6-Only Nodes......................... 22 6. Security Considerations.................................. 23 References................................................... 24 Author's Address............................................. 25 Full Copyright Statement..................................... 26 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 number of available 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. 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 Nordmark Standards Track [Page 2] RFC 2765 SIIT February 2000 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.Show full document text