rfc2765.txt

RFC 的详细文档！


RFC 2765                          SIIT                     February 2000


   The actions needed to translate various ICMPv4 messages are:

      ICMPv4 query messages:

        Echo and Echo Reply (Type 8 and Type 0)
           Adjust the type to 128 and 129, respectively, and adjust the
           ICMP checksum both to take the type change into account and
           to include the ICMPv6 pseudo-header.

        Information Request/Reply (Type 15 and Type 16)
           Obsoleted in ICMPv4.  Silently drop.

        Timestamp and Timestamp Reply (Type 13 and Type 14)
           Obsoleted in ICMPv6.  Silently drop.

        Address Mask Request/Reply (Type 17 and Type 18)
           Obsoleted in ICMPv6.  Silently drop.

        ICMP Router Advertisement (Type 9)
           Single hop message.  Silently drop.

        ICMP Router Solicitation (Type 10)
           Single hop message.  Silently drop.

        Unknown ICMPv4 types
           Silently drop.

      IGMP messages:

           While the MLD messages [MLD] are the logical IPv6
           counterparts for the IPv4 IGMP messages all the "normal" IGMP
           messages are single-hop messages and should be silently
           dropped by the translator.  Other IGMP messages might be used
           by multicast routing protocols and, since it would be a
           configuration error to try to have router adjacencies across
           IPv4/IPv6 translators those packets should also be silently
           dropped.

      ICMPv4 error messages:

        Destination Unreachable (Type 3)
           For all that are not explicitly listed below set the Type to
           1.

           Translate the code field as follows:
              Code 0, 1 (net, host unreachable):
                     Set Code to 0 (no route to destination).




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


              Code 2 (protocol unreachable):
                     Translate to an ICMPv6 Parameter Problem (Type 4,
                     Code 1) and make the Pointer point to the IPv6 Next
                     Header field.

              Code 3 (port unreachable):
                     Set Code to 4 (port unreachable).

              Code 4 (fragmentation needed and DF set):
                     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.  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 (source route failed):
                     Set Code to 0 (no route to destination).  Note that
                     this error is unlikely since source routes are not
                     translated.

              Code 6,7:
                     Set Code to 0 (no route to destination).

              Code 8:
                     Set Code to 0 (no route to destination).

              Code 9, 10 (communication with destination host
              administratively prohibited):
                     Set Code to 1 (communication with destination
                     administratively prohibited)

              Code 11, 12:
                     Set Code to 0 (no route to destination).

        Redirect (Type 5)
           Single hop message.  Silently drop.

        Source Quench (Type 4)
           Obsoleted in ICMPv6.  Silently drop.

        Time Exceeded (Type 11)
           Set the Type field to 3.  The Code field is unchanged.




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


        Parameter Problem (Type 12)
           Set the Type field to 4.  The Pointer needs to be updated to
           point to the corresponding field in the translated include
           IP header.

3.4.  Translating ICMPv4 Error Messages into ICMPv6

   There are some differences between the IPv4 and the IPv6 ICMP error
   message formats as detailed above.  In addition, the ICMP error
   messages contain the IP header for the packet in error which needs to
   be translated just like a normal IP header.  The translation of this
   "packet in error" is likely to change the length of the datagram thus
   the Payload Length field in the outer IPv6 header might need to be
   updated.

        +-------------+                 +-------------+
        |    IPv4     |                 |    IPv6     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |   ICMPv4    |                 |   ICMPv6    |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |    IPv4     |      ===>       |    IPv6     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |   Partial   |                 |   Partial   |
        |  Transport  |                 |  Transport  |
        |   Layer     |                 |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+

                    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.

3.5.  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 IPv4
   destination field contains an address that falls in these configured
   sets of prefixes the packet needs to be translated to IPv6.









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


4.  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 IPv4 header.  It then forwards the packet based on the
   IPv4 destination address.  The original IPv6 header on the packet is
   removed and replaced by an 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  |
        |   Header    |      ===>       |   Layer     |
        |(if present) |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |             |
        |   Layer     |                 ~    Data     ~
        |   Header    |                 |             |
        +-------------+                 +-------------+
        |             |
        ~    Data     ~
        |             |
        +-------------+

                    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 1280 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 1280.  However, [IPv6]
   requires that IPv6 nodes handle such an ICMP "packet too big" message
   by reducing the path MTU to 1280 and including an IPv6 fragment
   header with each packet.  This allows end-to-end path MTU discovery
   across the translator as long as the path MTU is 1280 bytes or
   greater.  When the path MTU drops below the 1280 limit the IPv6
   sender will originate 1280 byte packets that will be fragmented by
   IPv4 routers along the path after being translated to IPv4.

   The only drawback with this scheme is that it is not possible to use
   PMTU to do optimal UDP fragmentation (as opposed to completely
   avoiding fragmentation) at sender since the presence of an IPv6



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


   Fragment header is interpreted that is it OK to fragment the packet
   on the IPv4 side.  Thus if a UDP application wants to send large
   packets independent of the PMTU, the sender will only be able to
   determine the path MTU on the IPv6 side of the translator.  If the
   path MTU on the IPv4 side of the translator is smaller then the IPv6
   sender will not receive any ICMP "too big" errors and can not adjust
   the size fragments it is sending.

   Other than the special rules for handling fragments and path MTU
   discovery the actual translation of the packet header consists of a
   simple mapping as defined below.  Note that ICMP packets require
   special handling in order to translate the content of ICMP error
   message and also to add the ICMP pseudo-header checksum.

4.1.  Translating IPv6 Headers into IPv4 Headers

   If there is no IPv6 Fragment header the IPv4 header fields are set as
   follows:

         Version:
                 4

         Internet Header Length:
                 5 (no IPv4 options)

         Type of Service and Precedence:
                 By default, copied from the IPv6 Traffic Class (all 8
                 bits).  According to [DIFFSERV] the semantics of the
                 bits are identical in IPv4 and IPv6.  However, in
                 some IPv4 environments these bits might be used with
                 the old semantics of "Type Of Service and
                 Precedence".  An implementation of a translator
                 SHOULD provide the ability to ignore the IPv6 traffic
                 class and always set the IPv4 "TOS" to zero.

         Total Length:
                 Payload length value from IPv6 header, plus the size
                 of the IPv4 header.

         Identification:
                 All zero.

         Flags:
                 The More Fragments flag is set to zero.  The Don't
                 Fragments flag is set to one.

         Fragment Offset:
                 All zero.



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


         Time to Live:
                 Hop Limit value copied from IPv6 header.  Since the
                 translator is a router, as part of forwarding the
                 packet it needs to decrement either the IPv6 Hop
                 Limit (before the translation) or the IPv4 TTL (after
                 the translation).  As part of decrementing the TTL or
                 Hop Limit the translator (as any router) needs to
                 check for zero and send the ICMPv4 or ICMPv6 "ttl
                 exceeded" error.

         Protocol:
                 Next Header field copied from IPv6 header.

         Header Checksum:
                 Computed once the IPv4 header has been created.

         Source Address:
                 If the IPv6 source address is an IPv4-translated
                 address then the low-order 32 bits of the IPv6 source
                 address is copied to the IPv4 source address.
                 Otherwise, the source address is set to 0.0.0.0.  The
                 use of 0.0.0.0 is to avoid completely dropping e.g.
                 ICMPv6 error messages sent by IPv6-only routers which
                 makes e.g. traceroute present something for the
                 IPv6-only hops.

         Destination Address:
                 IPv6 packets that are translated have an IPv4-mapped
                 destination address.  Thus the low-order 32 bits of
                 the IPv6 destination address is copied to the IPv4
                 destination address.

   If any of an IPv6 hop-by-hop options header, destination options
   header, or routing header with the Segments Left field equal to zero
   are present in the IPv6 packet, they are ignored i.e., there is no
   attempt to translate them.  However, the Total Length field and the
   Protocol field would have to be adjusted to "skip" these extension
   headers.

   If a routing header with a non-zero Segments Left field is present
   then the packet MUST NOT be translated, and an ICMPv6 "parameter
   problem/ erroneous header field encountered" (Type 4/Code 0) error
   message, with the Pointer field indicating the first byte of the
   Segments Left field, SHOULD be returned to the sender.







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


   If the IPv6 packet contains a Fragment header the header fields are
   set as above with the following exceptions:

         Total Length:
                 Payload length value from IPv6 header, minus 8 for
                 the Fragment header, plus the size of the IPv4
                 header.

         Identification:
                 Copied from the low-order 16-bits in the
                 Identification field in the Fragment header.

         Flags:
                 The More Fragments flag is copied from the M flag in
                 the Fragment header.  The Don't Fragments flag is set
                 to zero allowing this packet to be fragmented by IPv4
                 routers.

         Fragment Offset:
                 Copied from the Fragment Offset field in the Fragment
                 Header.

         Protocol:
                 Next Header value copied from Fragment header.