rfc2529.txt

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


RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999


   During transition, routers may need to advertise at least two IPv6
   prefixes, one for the native LAN (e.g. Ethernet) and one for
   "6over4".  As with any IPv6 prefix assigned to an IPv6 subnet, the
   latter MUST be unique within its scope, whether site-local or global
   addressing is used.

   Also note that when a router is handling both native LAN and "6over4"
   on the same physical interface,  during stateless autoconfiguration,
   there is a period when IPv6 link-local addresses are used, in both
   cases with the prefix FE80::/64. Note that the prefix-length for
   these link-local adddress MUST then be 128 so that the two cases can
   be distinguished.

   As the site installs additional IPv6 routers, "6over4" hosts which
   become physically adjacent to IPv6 routers can be changed to run as
   native IPv6 hosts, with the the only impact on IPv6 applications
   being a slight increase in MTU size. At some stage during transition,
   it might be convenient to dual home hosts in both native LAN and
   "6over4" mode, but this is not required.

8. IANA Considerations

   No assignments by the IANA are required beyond those in [ADMIN].

9. Security Considerations

   Implementors should be aware that, in addition to posssible attacks
   against IPv6, security attacks against IPv4 must also be considered.
   Use of IP security at both IPv4 and IPv6 levels should nevertheless
   be avoided, for efficiency reasons.  For example, if IPv6 is running
   encrypted, encryption of IPv4 would be redundant except if traffic
   analysis is felt to be a threat.  If IPv6 is running authenticated,
   then authentication of IPv4 will add little.  Conversely, IPv4
   security will not protect IPv6 traffic once it leaves the IPv6-over-
   IPv4 domain.  Therefore, implementing IPv6 security is required even
   if IPv4 security is available.

   There is a possible spoofing attack in which spurious 6over4 packets
   are injected into a 6over4 domain from outside. Thus, boundary
   routers MUST discard multicast IPv4 packets with source or
   destination multicast addresses of organisation local scope as
   defined in section 6 above, if they arrive on physical interfaces
   outside that scope. To defend against spurious unicast 6over4
   packets, boundary routers MUST discard incoming IPv4 packets with
   protocol type 41 from unknown sources, i.e.  IPv6-in-IPv4 tunnels
   must only be accepted from trusted sources.  Unless IPSEC





Carpenter & Jung            Standards Track                     [Page 6]

RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999


   authentication is available, the RECOMMENDED technique for this is to
   configure the boundary router only to accept protocol type 41 packets
   from source addresses within a trusted range or ranges.

Acknowledgements

   The basic idea presented above is not original, and we have had
   invaluable comments from Matt Crawford, Steve Deering, Dan
   Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten,
   and other members of the IPNG and NGTRANS working groups.

   This document is seriously ripped off from RFC 1972 written by Matt
   Crawford. Brian Carpenter was at CERN when the work was started.

References

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

   [ADMIN]    Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
              RFC 2365, July 1998.

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

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

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

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

   [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
              and E. Lear, "Address Allocation for Private Internets",
              RFC 1918, February 1996.

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

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

   [RFC 1972] Crawford, M., "A Method for the Transmission of IPv6
              Packets over Ethernet Networks", RFC 1972, August 1996.




Carpenter & Jung            Standards Track                     [Page 7]

RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999


APPENDIX A:  IPv4 Multicast Addresses for Neighbor Discovery

   The following IPv4 multicast groups are used to support Neighbor
   Discovery with this specification. The IPv4 addresses listed in this
   section were obtained by looking at the IPv6 multicast addresses that
   Neigbour Discovery uses, and deriving the resulting IPv4 "virtual
   link-layer" addresses that are generated from them using the
   algorithm given in Section 6.

   all-nodes multicast address
         - the administratively-scoped IPv4 multicast address used to
           reach all nodes in the local IPv4 domain supporting this
           specification.  239.OLS.0.1

   all-routers multicast address
         - the administratively-scoped IPv4 multicast address to reach
           all routers in the local IPv4 domain supporting this
           specification.  239.OLS.0.2

   solicited-node multicast address
         - an administratively scoped multicast address that is computed
           as a function of the solicited target's address by taking the
           low-order 24 bits of the IPv4 address used to form the IPv6
           address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104
           [AARCH]. This is then mapped to the IPv4 multicast address by
           the method described in this document. For example, if the
           IPv4 address used to form the IPv6 address is W.X.Y.Z, then
           the IPv6 solicited node multicast address is
           FF02::1:255.X.Y.Z and the corresponding IPv4 multicast
           address is 239.OLS.Y.Z





















Carpenter & Jung            Standards Track                     [Page 8]

RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999


Authors' Addresses

   Brian E. Carpenter
   Internet Division
   IBM United Kingdom Laboratories
   MP 185, Hursley Park
   Winchester, Hampshire S021 2JN, UK

   EMail: [e-mail]


   Cyndi Jung
   3Com Corporation
   5400 Bayfront Plaza, Mailstop 3219
   Santa Clara, California  95052-8145

   EMail: [e-mail]


































Carpenter & Jung            Standards Track                     [Page 9]

RFC 2529         Transmission of IPv6 Packets over IPv4       March 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.
























Carpenter & Jung            Standards Track                    [Page 10]