rfc2765.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.

   -  An existing network where a large number of IPv6 devices are
      added.  The IPv6 devices might have both an IPv4 and an IPv6
      protocol stack but there is not enough global IPv4 address space
      to give each one of them a permanent IPv4 address.  In this case
      it is more likely that the routers in the network already route
      IPv4 and are upgraded to dual routers.

   However, there are other potential solutions in this area:

   -  If there is no IPv4 routing inside the network i.e., the cloud
      that contains the new devices, some possible solutions are to
      either use the translators specified in this document at the
      boundary of the cloud, or to use Application Layer Gateways (ALG)
      on dual nodes at the cloud's boundary.  The ALG solution is less
      flexible in that it is application protocol specific and it is
      also less robust since an ALG box is likely to be a single point
      of failure for a connection using that box.

   -  Otherwise, if IPv4 routing is supported inside the cloud and the
      implementations support both IPv6 and IPv4 it might suffice to
      have a mechanism for allocating a temporary address IPv4 and use
      IPv4 end to end when communicating with IPv4-only nodes.  However,
      it would seem that such 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 an algorithm that is one of the components
   needed to make IPv6-only nodes interoperate with IPv4-only nodes.
   Other components, not specified in this document, are a mechanism for
   the IPv6-only node to somehow acquire a temporary IPv4 address, and a
   mechanism for providing routing (perhaps using tunneling) to and from
   the temporary IPv4 address assigned to the node.

   The temporary IPv4 address will be used as an IPv4-translated IPv6
   address and the packets will travel 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-translated or IPv4-mapped IPv6
   addresses on the other side.






Nordmark                    Standards Track                     [Page 3]

RFC 2765                          SIIT                     February 2000


   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.  Also, the mechanism for
   routing this IPv4-translated IPv6 address in the site is not
   specified in this document.

   The figures below show how the Stateless IP/ICMP Translation
   algorithm (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 a 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 due to the size of the IPv4 routing table that would
   potentially be injected into IPv6 routing in the form of IPv4-mapped
   addresses.)

                                     ___________
                                    /           \
      [IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host]
                       |            \___________/
                (pool of IPv4 addresses)

      IPv4-translatable ->          IPv4->IPv4 addresser
      IPv4-mapped


           Figure 1.  Using SIIT for a single IPv6-only subnet.


                     ___________              ___________
                    /           \            /           \
      [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host]
                    \___________/     |      \___________/
                             (pool of IPv4 addresses)

      IPv4-translatable ->                     IPv4->IPv4 addresser
      IPv4-mapped


    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.



Nordmark                    Standards Track                     [Page 4]

RFC 2765                          SIIT                     February 2000


   The protocol translators are assumed to fit around some piece of
   topology that includes some IPv6-only nodes and that may also include
   IPv4 nodes as well as dual nodes.  There has to be a translator on
   each path used by routing the "translatable" packets in and out of
   this cloud to ensure that such packets always get translated.  This
   does not require a translator at every physical connection between
   the cloud and the rest of the Internet since the routing can be used
   to deliver the packets to the translator.

   The IPv6-only node communicating with an IPv4 node through a
   translator will see an IPv4-mapped address for the peer and use an
   IPv4-translatable address for its local address for that
   communication.  When the IPv6-only node sends packets the IPv4-mapped
   address indicates that the translator needs to translate the packets.
   When the IPv4 node sends packets those will translated to have the
   IPv4-translatable address as a destination; it is not possible to use
   an IPv4-mapped or an IPv4-compatible address as a destination since
   that would either route the packet back to the translator (for the
   IPv4-mapped address) or make the packet be encapsulated in IPv4 (for
   the IPv4-compatible address).  Thus this specification introduces the
   new notion of an IPv4-translatable address.

1.1.  Applicability and Limitations

   The use of this translation algorithm assumes that the IPv6 network
   is somehow well connected i.e. when an IPv6 node wants to communicate
   with another IPv6 node there is an IPv6 path between them.  Various
   tunneling schemes exist that can provide such a path, but those
   mechanisms and their use is outside the scope of this document.

   The IPv6 protocol [IPv6] has been designed so that the TCP and UDP
   pseudo-header checksums are not affected by the translations
   specified in this document, thus the translator does not need to
   modify normal TCP and UDP headers.  The only exceptions are
   unfragmented IPv4 UDP packets which need to have a UDP checksum
   computed since a pseudo-header checksum is required for UDP in IPv6.
   Also, 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 included IP header.  However, all of the translator's operations,
   including path MTU discovery, are stateless in the sense that the
   translator operates independently on each packet and does not retain
   any state from one packet to another.  This allows redundant
   translator boxes without any coordination and a given TCP connection
   can have the two directions of packets go through different
   translator boxes.



Nordmark                    Standards Track                     [Page 5]

RFC 2765                          SIIT                     February 2000


   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.  It could be possible to define a translation between source
   routing in IPv4 and IPv6.  However such a translation would not be
   semantically correct due to the slight differences between the IPv4
   and IPv6 source routing.  Also, the usefulness of source routing when
   going through a header translator might be limited since all the
   IPv6-only routers would need to have an IPv4-translated IPv6 address
   since the IPv4-only node will send a source route option containing
   only IPv4 addresses.

   At first sight it might appear that the IPsec functionality [IPv6-SA,
   IPv6-ESP, IPv6-AH] 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.  [Note that this assumes that the key
   management can operate between the IPv6-only node and the IPv4-only
   node.]  The AH computation covers parts of the IPv4 header fields
   such as IP addresses, and the identification field (fields that are
   either immutable or predictable by the sender) [IPv6-AUTH].  While
   the SIIT algorithm is specified so that those IPv4 fields can be
   predicted by the IPv6 sender it is not possible for the IPv6 receiver
   to determine the value of the IPv4 Identification field in packets
   sent by the IPv4 node.  Thus as the translation algorithm is
   specified in this document it is not possible to use end-to-end AH
   through the translator.

   For ESP Tunnel-mode to work through the translator the IPv6 node
   would have to be able to both parse and generate "inner" IPv4 headers
   since the inner IP will be encrypted together with the transport
   protocol.

   Thus in practise, only ESP transport mode is relatively easy to make
   work through a translator.

   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 header translation aspect of this memo in
   theory works for multicast packets this address mapping limitation
   makes it impossible to apply the techniques in this memo for
   multicast traffic.







Nordmark                    Standards Track                     [Page 6]

RFC 2765                          SIIT                     February 2000


1.2.  Assumptions

   The IPv6 nodes using the translator must have an IPv4-translated IPv6
   address while it is communicating with IPv4-only nodes.

   The use of the algorithm assumes that there is an IPv4 address pool
   used to generate IPv4-translated addresses.  Routing needs to be able
   to route any IPv4 packets, whether generated "outside" or "inside"
   the translator, destined to addresses in this pool towards the
   translator.  This implies that the address pool can not be assigned
   to subnets but must be separated from the IPv4 subnets used on the
   "inside" of the translator.

   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.  An informal trace [MILLER] in the backbone showed that
   out of 34,984,468 IP packets there were 769 fragmented UDP packets
   with a zero checksum.  However, all of them were due to malicious or
   broken behavior; a port scan and first fragments of IP packets that
   are not a multiple of 8 bytes.

1.3.  Impact Outside the Network Layer