Stateless IP/ICMP Translation Algorithm (SIIT)
RFC 2765

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

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.