rfc2765.txt

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

4.2.  Translating ICMPv6 Headers into ICMPv4 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.

   The actions needed to translate various ICMPv6 messages are:

      ICMPv6 informational messages:

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

        MLD Multicast Listener Query/Report/Done (Type 130, 131, 132)
           Single hop message.  Silently drop.





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


        Neighbor Discover messages (Type 133 through 137)
           Single hop message.  Silently drop.

        Unknown informational messages
           Silently drop.

      ICMPv6 error messages:

        Destination Unreachable (Type 1)
           Set the Type field to 3.  Translate the code field as
           follows:
              Code 0 (no route to destination):
                     Set Code to 1 (host unreachable).

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

              Code 2 (beyond scope of source address):
                     Set Code to 1 (host unreachable).  Note that this
                     error is very unlikely since the IPv4-translatable
                     source address is considered to have global scope.

              Code 3 (address unreachable):
                     Set Code to 1 (host unreachable).

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

        Packet Too Big (Type 2)
           Translate to an ICMPv4 Destination Unreachable with code 4.
           The MTU field needs to be adjusted for the difference between
           the IPv4 and IPv6 header sizes taking into account whether or
           not the packet in error includes a Fragment header.

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

        Parameter Problem (Type 4)
           If the Code is 1 translate this to an ICMPv4 protocol
           unreachable (Type 3, Code 2).  Otherwise set the Type to 12
           and the Code to zero.  The Pointer needs to be updated to
           point to the corresponding field in the translated include IP
           header.

        Unknown error messages
           Silently drop.



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


4.3.  Translating ICMPv6 Error Messages into ICMPv4

   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 Total Length field in the outer IPv4 header might need to be
   updated.

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

              IPv6-to-IPv4 ICMP Error Translation

   The translation of the inner IP header can be done by recursively
   invoking the function that translated the outer IP headers.

4.4.  Knowing when to Translate

   When the translator receives an IPv6 packet with an IPv4-mapped
   destination address the packet will be translated to IPv4.

5.  Implications for IPv6-Only Nodes

   An IPv6-only node which works through SIIT translators need some
   modifications beyond a normal IPv6-only node.

   As specified in Section 1.3 the application protocols need to handle
   operation on a dual stack node.  In addition the protocol stack needs
   to be able to:







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


   o  Determine when an IPv4-translatable address needs to be allocated
      and the allocation needs to be refreshed/renewed.  This can
      presumably be done without involving the applications by e.g.
      handling this under the socket API.  For instance, when the
      connect or sendto socket calls are invoked they could check if the
      destination is an IPv4-mapped address and in that case
      allocate/refresh the IPv4-translatable address.

   o  Ensure, as part of the source address selection mechanism, that
      when the destination address is an IPv4-mapped address the source
      address MUST be an IPv4-translatable address.  And an IPv4-
      translatable address MUST NOT be used with other forms of IPv6
      destination addresses.

   o  Should the peer have AAAA/A6 address records the application (or
      resolver) SHOULD never fall back to looking for A address records
      even if communication fails using the available AAAA/A6 records.
      The reason for this restriction is to prevent traffic between two
      IPv6 nodes (which AAAA/A6 records in the DNS) from accidentally
      going through SIIT translators twice; from IPv6 to IPv4 and to
      IPv6 again.  It is considered preferable to instead signal a
      failure to communicate to the application.

6.  Security Considerations

   The use of stateless IP/ICMP translators does not introduce any new
   security issues beyond the security issues that are already present
   in the IPv4 and IPv6 protocols and in the routing protocols which are
   used to make the packets reach the translator.

   As the Authentication Header [IPv6-AUTH] is specified to include the
   IPv4 Identification field and the translating function not being able
   to always preserve the Identification field, it is not possible for
   an IPv6 endpoint to compute AH on received packets that have been
   translated from IPv4 packets.  Thus AH does not work through a
   translator.

   Packets with ESP can be translated since ESP does not depend on
   header fields prior to the ESP header.  Note that ESP transport mode
   is easier to handle than ESP tunnel mode; in order to use ESP tunnel
   mode the IPv6 node needs to be able to generate an inner IPv4 header
   when transmitting packets and remove such an IPv4 header when
   receiving packets.








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


References

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IPv6]       Deering, S. and R. Hinden, Editors, "Internet Protocol,
                Version 6 (IPv6) Specification", RFC 2460, December
                1998.

   [IPv4]       Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [ADDR-ARCH]  Deering, S. and R. Hinden, Editors, "IP Version 6
                Addressing Architecture", RFC 2373, July 1998.

   [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
                IPv6 Hosts and Routers", RFC 1933, April 1996.

   [DISCOVERY]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
                Discovery for IP Version 6 (IPv6)", RFC 2461, December
                1998.

   [IPv6-SA]    Atkinson, R., "Security Architecture for the Internet
                Protocol", RFC 2401, November 1998.

   [IPv6-AUTH]  Atkinson, R., "IP Authentication Header", RFC 2402,
                November 1998.

   [IPv6-ESP]   Atkinson, R., "IP Encapsulating Security Payload (ESP)",
                RFC 2406, November 1998.

   [ICMPv4]     Postel, J., "Internet Control Message Protocol", STD 5,
                RFC 792, September 1981.

   [ICMPv6]     Conta, A. and S. Deering, "Internet Control Message
                Protocol (ICMPv6) for the Internet Protocol Version 6
                (IPv6)", RFC 2463, December 1998.

   [IGMP]       Deering, S., "Host extensions for IP multicasting", STD
                5, RFC 1112, August 1989.

   [PMTUv4]     Mogul, J. and S. Deering, "Path MTU Discovery", RFC
                1191, November 1990.

   [PMTUv6]     McCann, J., Deering, S. and J. Mogul, "Path MTU
                Discovery for IP version 6", RFC 1981, August 1996.





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


   [DIFFSERV]   Nichols, K., Blake, S., Baker, F. and D. Black,
                "Definition of the Differentiated Services Field (DS
                Field) in the IPv4 and IPv6 Headers", RFC 2474, December
                1998.

   [MLD]        Deering, S., Fenner, W. and B. Haberman, "Multicast
                Listener Discovery (MLD) for IPv6", RFC 2710, October
                1999.

   [FTPEXT]     Allman, M., Ostermann, S. and C. Metz, "FTP Extensions
                for IPv6 and NATs.", RFC 2428, September 1998.

   [MILLER]     G. Miller, Email to the ngtrans mailing list on 26 March
                1999.

   [BSDAPI]     Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
                "Basic Socket Interface Extensions for IPv6", RFC 2553,
                March 1999.

Author's Address

   Erik Nordmark
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]





















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


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Nordmark                    Standards Track                    [Page 26]