rfc2765.txt

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

   The potential existence of stateless IP/ICMP translators is already
   taken care of from a protocol perspective in [IPv6].  However, an
   IPv6 node that wants to be able to use translators needs some
   additional logic in the network layer.

   The network layer in an IPv6-only node, when presented by the
   application with either an IPv4 destination address or an IPv4-mapped
   IPv6 destination address, is likely to drop the packet and return
   some error message to the application.  In order to take advantage of
   translators such a node should instead send an IPv6 packet where the
   destination address is the IPv4-mapped address and the source address
   is the node's temporarily assigned IPv4-translated address.  If the
   node does not have a temporarily assigned IPv4-translated address it
   should acquire one using mechanisms that are not discussed in this
   document.

   Note that the above also applies to a dual IPv4/IPv6 implementation
   node which is not configured with any IPv4 address.

   There are no extra changes needed to applications to operate through
   a translator beyond what applications already need to do to operate
   on a dual node.  The applications that have been modified to work on
   a dual node already have the mechanisms to determine whether they are
   communicating with an IPv4 or an IPv6 peer.  Thus if the applications



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


   need to modify their behavior depending on the type of the peer, such
   as ftp determining whether to fallback to using the PORT/PASV command
   when EPRT/EPSV fails (as specified in [FTPEXT]), they already need to
   do that when running on dual nodes and the presense of translators
   does not add anything.  For example, when using the socket API
   [BSDAPI] the applications know that the peer is IPv6 if they get an
   AF_INET6 address from the name service and the address is not an
   IPv4-mapped address (i.e., IN6_IS_ADDR_V4MAPPED returns false).  If
   this is not the case, i.e., the address is AF_INET or an IPv4-mapped
   IPv6 address, the peer is IPv4.

   One way of viewing the translator, which might help clarify why
   applications do not need to know that a translator is used, is to
   look at the information that is passed from the transport layer to
   the network layer.  If the transport passes down an IPv4 address
   (whether or not is in the IPv4-mapped encoding) this means that at
   some point there will be IPv4 packets generated.  In a dual node the
   generation of the IPv4 packets takes place in the sending node.  In
   an IPv6-only node conceptually the only difference is that the IPv4
   packet is generated by the translator - all the information that the
   transport layer passed to the network layer will be conveyed to the
   translator in some form.  That form just "happens" to be in the form
   of an IPv6 header.

2.  Terminology

   This documents uses the terminology defined in [IPv6] and
   [TRANS-MECH] with these clarifications:

         IPv4 capable node:
                 A node which has an IPv4 protocol stack.
                 In order for the stack to be usable the node must be
                 assigned one or more IPv4 addresses.

         IPv4 enabled node:
                 A node which has an IPv4 protocol stack
                 and is assigned one or more IPv4 addresses.  Both
                 IPv4-only and IPv6/IPv4 nodes are IPv4 enabled.

         IPv6 capable node:
                 A node which has an IPv6 protocol stack.
                 In order for the stack to be usable the node must be
                 assigned one or more IPv6 addresses.

         IPv6 enabled node:
                 A node which has an IPv6 protocol stack
                 and is assigned one or more IPv6 addresses.  Both
                 IPv6-only and IPv6/IPv4 nodes are IPv6 enabled.



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


2.1.  Addresses

   In addition to the forms of addresses defined in [ADDR-ARCH] this
   document also introduces the new form of IPv4-translated address.
   This is needed to avoid using IPv4-compatible addresses outside the
   intended use of automatic tunneling.  Thus the address forms are:

         IPv4-mapped:
                 An address of the form 0::ffff:a.b.c.d which refers
                 to a node that is not IPv6-capable.  In addition to
                 its use in the API this protocol uses IPv4-mapped
                 addresses in IPv6 packets to refer to an IPv4 node.

         IPv4-compatible:
                 An address of the form 0::0:a.b.c.d which refers to
                 an IPv6/IPv4 node that supports automatic tunneling.
                 Such addresses are not used in this protocol.

         IPv4-translated:
                 An address of the form 0::ffff:0:a.b.c.d which refers
                 to an IPv6-enabled node.  Note that the prefix
                 0::ffff:0:0:0/96 is chosen to checksum to zero to
                 avoid any changes to the transport protocol's pseudo
                 header checksum.

2.2.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [KEYWORDS].

3.  Translating from IPv4 to IPv6

   When an IPv4-to-IPv6 translator receives an IPv4 datagram addressed
   to a destination that lies outside of the attached IPv4 island, it
   translates the IPv4 header of that packet into an IPv6 header.  It
   then forwards the packet based on the IPv6 destination address.  The
   original IPv4 header on the packet is removed and replaced by an IPv6
   header.  Except for ICMP packets the transport layer header and data
   portion of the packet are left unchanged.











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


        +-------------+                 +-------------+
        |    IPv4     |                 |    IPv6     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Fragment   |
        |   Layer     |      ===>       |   Header    |
        |   Header    |                 |(not always) |
        +-------------+                 +-------------+
        |             |                 |  Transport  |
        ~    Data     ~                 |   Layer     |
        |             |                 |   Header    |
        +-------------+                 +-------------+
                                        |             |
                                        ~    Data     ~
                                        |             |
                                        +-------------+

                    IPv4-to-IPv6 Translation

   One of the differences between IPv4 and IPv6 is that in IPv6 path MTU
   discovery is mandatory but it is optional in IPv4.  This implies that
   IPv6 routers will never fragment a packet - only the sender can do
   fragmentation.

   When the IPv4 node performs path MTU discovery (by setting the DF bit
   in the header) the path MTU discovery can operate end-to-end i.e.
   across the translator.  In this case either IPv4 or IPv6 routers
   might send back ICMP "packet too big" messages to the sender.  When
   these ICMP errors are sent by the IPv6 routers they will pass through
   a translator which will translate the ICMP error to a form that the
   IPv4 sender can understand.  In this case an IPv6 fragment header is
   only included if the IPv4 packet is already fragmented.

   However, when the IPv4 sender does not perform path MTU discovery the
   translator has to ensure that the packet does not exceed the path MTU
   on the IPv6 side.  This is done by fragmenting the IPv4 packet so
   that it fits in 1280 byte IPv6 packet since IPv6 guarantees that 1280
   byte packets never need to be fragmented.  Also, when the IPv4 sender
   does not perform path MTU discovery the translator MUST always
   include an IPv6 fragment header to indicate that the sender allows
   fragmentation.  That is needed should the packet pass through an
   IPv6-to-IPv4 translator.

   The above rules ensure that when packets are fragmented either by the
   sender or by IPv4 routers that the low-order 16 bits of the fragment
   identification is carried end-end to ensure that packets are
   correctly reassembled.  In addition, the rules use the presence of an




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


   IPv6 fragment header to indicate that the sender might not be using
   path MTU discovery i.e. the packet should not have the DF flag set
   should it later be translated back to IPv4.

   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.

3.1.  Translating IPv4 Headers into IPv6 Headers

   If the DF flag is not set and the IPv4 packet will result in an IPv6
   packet larger than 1280 bytes the IPv4 packet MUST be fragmented
   prior to translating it.  Since IPv4 packets with DF not set will
   always result in a fragment header being added to the packet the IPv4
   packets must be fragmented so that their length, excluding the IPv4
   header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and
   8 for the Fragment header).  The resulting fragments are then
   translated independently using the logic described below.

   If the DF bit is set and the packet is not a fragment (i.e., the MF
   flag is not set and the Fragment Offset is zero) then there is no
   need to add a fragment header to the packet.  The IPv6 header fields
   are set as follows:

         Version:
                 6

         Traffic Class:
                 By default, copied from IP Type Of Service and
                 Precedence field (all 8 bits are copied).  According
                 to [DIFFSERV] the semantics of the bits are identical
                 in IPv4 and IPv6.  However, in some IPv4 environments
                 these fields 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 IPv4 "TOS" and always set the IPv6 traffic class
                 to zero.

         Flow Label:
                 0 (all zero bits)

         Payload Length:
                 Total length value from IPv4 header, minus the size
                 of the IPv4 header and IPv4 options, if present.





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


         Next Header:
                 Protocol field copied from IPv4 header

         Hop Limit:
                 TTL value copied from IPv4 header.  Since the
                 translator is a router, as part of forwarding the
                 packet it needs to decrement either the IPv4 TTL
                 (before the translation) or the IPv6 Hop Limit (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.

         Source Address:
                 The low-order 32 bits is the IPv4 source address.
                 The high-order 96 bits is the IPv4-mapped prefix
                 (::ffff:0:0/96)

         Destination Address:
                 The low-order 32 bits is the IPv4 destination
                 address.  The high-order 96 bits is the IPv4-
                 translated prefix (0::ffff:0:0:0/96)

   If IPv4 options are present in the IPv4 packet, they are ignored
   i.e., there is no attempt to translate them.  However, if an
   unexpired source route option is present then the packet MUST instead
   be discarded, and an ICMPv4 "destination unreachable/source route
   failed" (Type 3/Code 5) error message SHOULD be returned to the
   sender.

   If there is need to add a fragment header (the DF bit is not set or
   the packet is a fragment) the header fields are set as above with the
   following exceptions:

      IPv6 fields:

          Payload Length:
                  Total length value from IPv4 header, plus 8 for the
                  fragment header, minus the size of the IPv4 header
                  and IPv4 options, if present.

          Next Header:
                  Fragment Header (44).

      Fragment header fields:

          Next Header:
                  Protocol field copied from IPv4 header.



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


          Fragment Offset:
                  Fragment Offset copied from the IPv4 header.

          M flag:
                  More Fragments bit copied from the IPv4 header.

          Identification:
                  The low-order 16 bits copied from the Identification
                  field in the IPv4 header.  The high-order 16 bits set
                  to zero.

3.2.  Translating UDP over IPv4

   If a UDP packet has a zero UDP checksum then a valid checksum must be
   calculated in order to translate the packet.  A stateless translator
   can not do this for fragmented packets but [MILLER] indicates that
   fragmented UDP packets with a zero checksum appear to only be used
   for malicious purposes.  Thus this is not believed to be a noticeable
   limitation.

   When a translator receives the first fragment of a fragmented UDP
   IPv4 packet and the checksum field is zero the translator SHOULD drop
   the packet and generate a system management event specifying at least
   the IP addresses and port numbers in the packet.  When it receives
   fragments other than the first it SHOULD silently drop the packet,
   since there is no port information to log.

   When a translator receives an unfragmented UDP IPv4 packet and the
   checksum field is zero the translator MUST compute the missing UDP
   checksum as part of translating the packet.  Also, the translator
   SHOULD maintain a counter of how many UDP checksums are generated in
   this manner.

3.3.  Translating ICMPv4 Headers into ICMPv6 Headers

   All ICMP messages that are to be translated require that the ICMP
   checksum field be updated as part of the translation since ICMPv6,
   unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.

   In addition all ICMP packets need to have the Type value translated
   and for ICMP error messages the included IP header also needs
   translation.









Nordmark                    Standards Track                    [Page 13]