rfc2491.txt

RFC 的详细文档！

   This architecture introduces no new protocols, but depends on
   existing protocols (NHRP, IPv6, ND, MARS) and is therefore subject to
   all the security threats inherent in these protocols. This
   architecture should not be used in a domain where any of the base
   protocols are considered unacceptably insecure. However, this
   protocol itself does not introduce additional security threats.

   While this proposal does not introduce any new security mechanisms
   all current IPv6 security mechanisms will work without modification
   for NBMA.  This includes both authentication and encryption for both
   Neighbor Discovery protocols as well as the exchange of IPv6 data
   packets. The MARS protocol is modified in a manner that does not
   affect or augment the security offered by RFC 2022.

Acknowledgments

   Eric Nordmark confirmed the usefulness of ND Redirect messages in
   private email during the March 1996 IETF. The discussions with
   various ION WG members during the June and December 1996 IETF helped
   solidify the architecture described here. Grenville Armitage's
   original work on IPv6/NBMA occurred while employed at Bellcore.
   Elements of section 5 were borrowed from Matt Crawford's memo on IPv6
   over Ethernet.


























Armitage, et. al.           Standards Track                    [Page 24]

RFC 2491                IPv6 over NBMA networks             January 1999


Authors' Addresses

   Grenville Armitage
   Bell Laboratories, Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, NJ 07733
   USA

   EMail: [e-mail]


   Peter Schulter
   Bright Tiger Technologies
   125 Nagog Park
   Acton, MA 01720

   EMail: [e-mail]


   Markus Jork
   European Applied Research Center
   Digital Equipment GmbH
   CEC Karlsruhe
   Vincenz-Priessnitz-Str. 1
   D-76131 Karlsruhe
   Germany

   EMail: [e-mail]


   Geraldine Harter
   Digital UNIX Networking
   Compaq Computer Corporation
   110 Spit Brook Road
   Nashua, NH 03062

   EMail: [e-mail]














Armitage, et. al.           Standards Track                    [Page 25]

RFC 2491                IPv6 over NBMA networks             January 1999


References

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

   [2] ATM Forum, "ATM User Network Interface (UNI) Specification
       Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood
       Cliffs, NJ, June 1995.

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

   [4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC 1483, July 1993.

   [5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
       Networks", RFC 2022, November 1996.

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

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

   [8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy,
       "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

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

   [10] "64-Bit Global Identifier Format Tutorial",
        http://standards.ieee.org/db/oui/tutorials/EUI64.html.

   [11] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router
        Architecture Extensions for ATM : Overview", RFC 2098, February
        1997.

   [12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under
        IP", Proceedings of INFOCOM'96, San Francisco, March 1996,
        pp.1251-1260

   [13] Piscitello, D. and J. Lawrence, "The Transmission of IP
        Datagrams over the SMDS Service", RFC 1209, March 1991.

   [14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
        Converting Network Protocol Addresses to 48.bit Ethernet Address
        for Transmission on Ethernet Hardware", STD 37, RFC 826,
        November 1982.



Armitage, et. al.           Standards Track                    [Page 26]

RFC 2491                IPv6 over NBMA networks             January 1999


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

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

   [17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
        Networks", RFC 2492, January 1999.

   [18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol for
        IPv6 (DHCPv6)", Work in Progress.

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





































Armitage, et. al.           Standards Track                    [Page 27]

RFC 2491                IPv6 over NBMA networks             January 1999


Appendix A.  IPv6 Protocol Operation Description

   The IPv6 over NBMA model described in this document maintains the
   complete semantics of the IPv6 protocols. No changes need to be made
   to the IPv6 Network Layer. Since the concept of the security
   association is not being changed for NBMA, this framework maintains
   complete IPv6 security semantics and features. This allows IPv6 nodes
   to choose their responses to solicitations based on security
   information as is done with other datalinks, thereby maintaining the
   semantics of Neighbor Discovery since it is always the solicited node
   that chooses what (and even if) to reply to the solicitation. Thus,
   NBMA will be transparent to the network layer except in cases where
   extra services (such as QoS VCs) are offered.

   The remainder of this Appendix describes how the core IPv6 protocols
   will operate within the model described here.

A.1 Neighbor Discovery Operations

   Before performing any sort of Neighbor discover operation, each node
   must first join the all-node multicast group, and it's solicited node
   multicast address (the use of this address in relation to DAD is
   described in A.1.4).  The IPv6 network layer will join these
   multicast groups as described in 4.2.

A.1.1 Performing Address Resolution

   An IPv6 host performs address resolution by sending a Neighbor
   Solicitation to the solicited-node multicast address of the target
   host, as described in [7]. The Neighbor Solicitation message will
   contain a Source Link-Layer Address Option set to the soliciting
   node's NBMA address on the LL.

   When the local node's IPv6/NBMA driver is passed the Neighbor
   Solicitation message from the IPv6 network layer, it follows the
   steps described in section 4.4.2 Sending Multicast Data.

   One or more nodes will receive the Neighbor Solicitation message.
   The nodes will process the data as described in section 4.5 and pass
   the de-encapsulated packets to the IPv6 network layer.

   If the receiving node is the target of the Neighbor Solicitation it
   will update its Neighbor cache with the soliciting node's NBMA
   address, contained in the Neighbor Solicitation message's Source
   Link-Layer Address Option as described in [7].






Armitage, et. al.           Standards Track                    [Page 28]

RFC 2491                IPv6 over NBMA networks             January 1999


   The solicited IPv6 host will respond to the Neighbor Solicitation
   with a Neighbor Advertisement message sent to the IPv6 unicast
   address of the soliciting node.  The Neighbor Advertisement message
   will contain a Target Link-Layer Address Option set to the solicited
   node's NBMA address on the LL.

   The solicited node's IPv6/NBMA driver will be passed the Neighbor
   Advertisement and the soliciting node's link-layer address from the
   IPv6 network layer.  It will then follow the steps described in
   section section 4.4.1 to send the NA message to the soliciting node.
   This will create a pt-pt VC between the solicited node and soliciting
   node if one did not already exist.

   The soliciting node will then receive the Neighbor Advertisement
   message over the new PtP VC, de-encapsulate the message, and pass it
   to the IPv6 Network layer for processing as described in section 4.5.
   The soliciting node will then make the appropriate entries in it's
   Neighbor cache, including caching the NBMA link-layer address of the
   solicited node as described in [7].

   At this point each system has a complete Neighbor cache entry for the
   other system. They can exchange data over the pt-pt VC newly created
   by the solicited node when it returned the Neighbor Advertisement, or
   create a new VC.

   An IPv6 host can also send an Unsolicited Neighbor Advertisemnent to
   the all-nodes multicast address. When the local node IPv6/NBMA driver
   is passed the Neighbor Advertisement from the IPv6 network layer, it
   follows the steps described in section 4.4.2 to send the NA message
   to the all-nodes multicast address.  Each node will process the
   incoming packet as described in section 4.5 and then pass the packet
   to the IPv6 network layer where it will be processed as described in
   [7].

A.1.2 Performing Router Discovery

   Router Discovery is described in [7]. To support Router Discovery an
   IPv6 router will join the IPv6 all-routers multicast group address.
   When the IPv6/NBMA driver gets the JoinLocalGroup request from the
   IPv6 Network Layer, it follows the process described in section 4.2.

   IPv6 routers periodically send unsolicited Router Advertisem