rfc3056.txt

RFC 的详细文档！

   advertised by BGP.

   It will be necessary for 6to4 routers to obtain routes to relay
   routers in order to access the native IPv6 domain.  In the simplest
   case there will be a manually configured default IPv6 route to a
   relay router's address under the prefix
   {FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address
   of the relay router.  Such a route could be used to establish a BGP
   session for the exchange of additional IPv6 routes.

   By construction, unicast IPv6 traffic within a 6to4 domain will
   follow exactly the same path as unicast IPv4 traffic.

5.11. Routing loop prevention

   Since 6to4 has no impact on IPv4 routing, it cannot induce routing
   loops in IPv4.  Since 2002: prefixes behave exactly like standard
   IPv6 prefixes, they will not create any new mechanisms for routing
   loops in IPv6 unless misconfigured.  One very dangerous
   misconfiguration would be an announcement of the 2002::/16 prefix
   into a 6to4 exterior routing domain, since this would attract all
   6to4 traffic into the site making the announcement.  Its 6to4 router
   would then resend non-local 6to4 traffic back out, forming a loop.

   The 2002::/16 routing prefix may be legitimately advertised into the
   native IPv6 routing domain by a relay router, and into an IPv6 site's
   local IPv6 routing domain; hence there is a risk of misconfiguration
   causing it to be advertised into a 6to4 exterior routing domain.

   To summarize, the 2002::/16 prefix MUST NOT be advertised to a 6to4
   exterior routing domain.









Carpenter & Moore           Standards Track                    [Page 18]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


6. Multicast and Anycast

   It is not possible to assume the general availability of wide-area
   IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must assume
   only unicast capability in its underlying IPv4 carrier network.  An
   IPv6 multicast routing protocol is needed [MULTI].

   The allocated anycast address space [ANYCAST] is compatible with
   2002:: prefixes, i.e., anycast addresses formed with such prefixes
   may be used inside a 6to4 site.

7. ICMP messages

   ICMP "unreachable" and other messages returned by the IPv4 routing
   system will be returned to the 6to4 router that generated a
   encapsulated 2002:: packet.  However, this router will often be
   unable to return an ICMPv6 message to the originating IPv6 node, due
   to the lack of sufficient information in the "unreachable" message.
   This means that the IPv4 network will appear as an undiagnosable link
   layer for IPv6 operational purposes.  Other considerations are as
   described in Section 4.1.3 of [MECH].

8. IANA Considerations

   No assignments by the IANA are required beyond the special TLA value
   0x0002 already assigned.

9. Security Considerations

   Implementors should be aware that, in addition to possible 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 6to4
   domain.  Therefore, implementing IPv6 security is required even if
   IPv4 security is available.

   By default, 6to4 traffic will be accepted and decapsulated from any
   source from which regular IPv4 traffic is accepted.  If this is for
   any reason felt to be a security risk (for example, if IPv6 spoofing
   is felt to be more likely than IPv4 spoofing), then additional source
   address based packet filtering could be applied.  A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address.  If this check is




Carpenter & Moore           Standards Track                    [Page 19]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


   applied, exceptions to it must be configured to admit traffic from
   relay routers (Section 5).  2002:: traffic must also be excepted from
   checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].

   In any case, any 6to4 traffic whose source or destination address
   embeds a V4ADDR which is not in the format of a global unicast
   address MUST be silently discarded by both encapsulators and
   decapsulators.  Specifically, this means that IPv4 addresses defined
   in [RFC 1918], broadcast, subnet broadcast, multicast and loopback
   addresses are unacceptable.

Acknowledgements

   The basic idea presented above is probably not original, and we have
   had invaluable comments from Magnus Ahltorp, Harald Alvestrand, Jim
   Bound, Scott Bradner, Randy Bush, Matt Crawford, Richard Draves,
   Jun-ichiro itojun Hagino, Joel Halpern, Tony Hain, Andy Hazeltine,
   Bob Hinden, Geoff Huston, Perry Metzger, Thomas Narten, Erik
   Nordmark, Markku Savela, Ole Troan, Sowmini Varadhan, members of the
   Compaq IPv6 engineering team, and other members of the NGTRANS
   working group.  Some text has been copied from [6OVER4].  George
   Tsirtsis kindly drafted two of the diagrams.

References

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

   [AGGR]     Hinden., R, O'Dell, M. and S. Deering, "An IPv6
              Aggregatable Global Unicast Address Format", RFC 2374,
              July 1998.

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

   [BGP4+]    Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
              Extensions for IPv6 Inter-Domain Routing", RFC 2545, March
              1999.

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





Carpenter & Moore           Standards Track                    [Page 20]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


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

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

   [ANYCAST]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
              Addresses", Work in Progress.

   [MULTI]    Thaler, D., "Support for Multicast over 6to4 Networks",
              Work in Progress.

   [SCALE]    Hain, T., "6to4-relay discovery and scaling", Work in
              Progress.

   [SELECT]   Draves, R., "Default Address Selection for IPv6", Work in
              Progress.

   [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",
              BCP 5, RFC 1918, February 1996.

   [MECH]     Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

   [RSIP]     Borella, M., Grabelsky, D., Lo, J. and K. Tuniguchi,
              "Realm Specific IP: Protocol Specification", Work in
              Progress.

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

   [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 2283, February
              1998.













Carpenter & Moore           Standards Track                    [Page 21]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


Authors' Addresses

   Brian E. Carpenter
   IBM
   iCAIR, Suite 150
   1890 Maple Avenue
   Evanston IL 60201, USA

   EMail: [e-mail]


   Keith Moore
   UT Computer Science Department
   1122 Volunteer Blvd, Ste 203
   Knoxville, TN  37996-3450
   USA

   EMail: [e-mail]

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.











Carpenter & Moore           Standards Track                    [Page 22]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


Full Copyright Statement

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



















Carpenter & Moore           Standards Track                    [Page 23]