rfc2893.txt

<VC++网络游戏建摸与实现>源代码

   Tunneling is not known to introduce any security holes except for the
   possibility to circumvent ingress filtering [13].  This is prevented
   by requiring that decapsulating routers only forward packets if they
   have been configured to accept encapsulated packets from the IPv4
   source address in the receive packet.  Additionally, in the case of
   automatic tunneling, nodes are required by not forwarding the
   decapsulated packets since automatic tunneling ends the tunnel and
   the destination.

8.  Authors' Addresses

   Robert E. Gilligan
   FreeGate Corp
   1208 E. Arques Ave
   Sunnyvale, CA 94086
   USA

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


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

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









Gilligan & Nordmark         Standards Track                    [Page 24]

RFC 2893               IPv6 Transition Mechanisms            August 2000


9.  References

   [1]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
        September 1985.

   [2]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
        October 1993.

   [3]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
        Domains without Explicit Tunnels", RFC 2529, March 1999.

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

   [5]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration," RFC 2462, December 1998.

   [6]  Crawford, M., Thomson, S., and C. Huitema. "DNS Extensions to
        Support IPv6 Address Allocation and Renumbering", RFC 2874, July
        2000.

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

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

   [9]  Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "Reverse
        Address Resolution Protocol", STD 38, RFC 903, June 1984.

   [10] Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.

   [11] Kent, C. and J. Mogul, "Fragmentation Considered Harmful".  In
        Proc.  SIGCOMM '87 Workshop on Frontiers in Computer
        Communications Technology.  August 1987.

   [12] Callon, R. and D. Haskin, "Routing Aspects of IPv6 Transition",
        RFC 2185, September 1997.

   [13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
        Denial of Service Attacks which employ IP Source Address
        Spoofing", RFC 2267, January 1998.

   [14] Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.





Gilligan & Nordmark         Standards Track                    [Page 25]

RFC 2893               IPv6 Transition Mechanisms            August 2000


   [15] Rechter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and
        E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
        1918, February 1996.

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

   [17] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.

   [18] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
        June 1995.

10.  Changes from RFC 1933

   -  Deleted section 3.1.1 (IPv4 loopback address) in order to prevent
      it from being mis-construed as requiring routers to filter the
      address ::127.0.0.1, which would put another test in the
      forwarding path for IPv6 routers.

   -  Deleted section 4.4 (Default Sending Algorithm).  This section
      allowed nodes to send packets in "raw form" to IPv4-compatible
      destinations on the same datalink.  Implementation experience has
      shown that this adds complexity which is not justified by the
      minimal savings in header overhead.

   -  Added definitions for operating modes for IPv6/IPv4 nodes.

   -  Revised DNS section to clarify resolver filtering and ordering
      options.

   -  Re-wrote the discussion of IPv4-compatible addresses to clarify
      that they are used exclusively in conjunction with the automatic
      tunneling mechanism.  Re-organized document to place definition of
      IPv4-compatible address format with description of automatic
      tunneling.

   -  Changed the term "IPv6-only address" to "IPv6-native address" per
      current usage.

   -  Updated to algorithm for determining tunnel MTU to reflect the
      change in the IPv6 minimum MTU from 576 to 1280 bytes [4].

   -  Deleted the definition for the term "IPv6-in-IPv4 encapsulation."
      It has not been widely used.

   -  Revised IPv4-compatible address configuration section (5.2) to
      recognize multiple interfaces.




Gilligan & Nordmark         Standards Track                    [Page 26]

RFC 2893               IPv6 Transition Mechanisms            August 2000


   -  Added discussion of source address selection when using IPv4-
      compatible addresses.

   -  Added section on the combination of the default configured
      tunneling technique with hosts using automatic tunneling.

   -  Added prohibition against automatic tunneling to IPv4 broadcast or
      multicast destinations.

   -  Clarified that configured tunnels can be unidirectional or
      bidirectional.

   -  Added description of bidirectional virtual links as another type
      of tunnels.  Nodes MUST respond to NUD probes on such links and
      SHOULD send NUD probes.

   -  Added reference to [16] specification as an alternative for
      tunneling over a multicast capable IPv4 cloud.

   -  Clarified that IPv4-compatible addresses are assigned exclusively
      to nodes that support automatic tunnels i.e. nodes that can
      receive such packets.

   -  Added text about formation of link-local addresses and use of
      Neighbor Discovery on tunnels.

   -  Added restriction that decapsulated packets not be forwarded
      unless the source address is acceptable to the decapsulating
      router.

   -  Clarified that decapsulating nodes MUST be capable of reassembling
      an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).

   -  Clarified that when using a default tunnel to an IPv4 "anycast
      address" the network must either have an IPv4 MTU of least 1300
      bytes (to avoid fragmentation of minimum size IPv6 packets) or be
      configured to avoid frequent changes to IPv4 routing to the
      "anycast address" (to avoid different IPv4 fragments arriving at
      different tunnel endpoints).

   -  Using A6/AAAA instead of AAAA to reference IPv6 address records in
      the DNS.

   -  Specified when to put IPv6 addresses in the DNS.

   -  Added reference to the tunnel mib for TTL specification for the
      tunnels.




Gilligan & Nordmark         Standards Track                    [Page 27]

RFC 2893               IPv6 Transition Mechanisms            August 2000


   -  Added a table of contents.

   -  Added recommendations for use of source and target link layer
      address options for the tunnel links.

   -  Added checks in the decapsulation checking both an IPv4-compatible
      IPv6 source address and the outer IPv4 source addresses for
      multicast, broadcast, all-zeros etc.











































Gilligan & Nordmark         Standards Track                    [Page 28]

RFC 2893               IPv6 Transition Mechanisms            August 2000


11.  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.



















Gilligan & Nordmark         Standards Track                    [Page 29]