rfc2491.txt

RFC 的详细文档！

                   address.

   off-link  - the opposite of "on-link"; an address that is not
               assigned to any interfaces attached to a shared link.

   Off-link nodes are considered to only be accessible through one of
   the routers directly attached to the link.






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


   The NBMA environment complicates the sense of the word 'link' in much
   the same way as it complicated the sense of 'subnet' in the IPv4
   case. For IPv4 this required the definition of the Logical IP Subnet
   (LIS) - an administratively constructed set of hosts that would share
   the same routing prefixes (network and subnetwork masks).

   This document considers the IPv6 analog to be a Logical Link (LL).

      An LL consists of nodes administratively configured to be 'on
      link' with respect to each other.

      The members of an LL are an IPv6 interface's initial set of
      neighbors, and each interface's Link Local address only needs to
      be unique amongst this set.

   It should be noted that whilst members of an LL are IPv6 Neighbors,
   it is possible for Neighbors to exist that are not, administratively,
   members of the same LL.

   Neighbor Discovery events can result in the expansion of an IPv6
   interface's set of Neighbors. However, this does not change the set
   of interfaces that make up its LL. This leads to three possible
   relationships between any two IPv6 interfaces:

      - On LL, Neighbor.
      - Off LL, Neighbor.
      - Off LL, not Neighbor.

   Off LL Neighbors represent the 'shortcut' connections, where it has
   been ascertained that direct connectivity at the NBMA level is
   possible to a target that is not a member of the source's LL.

   Neighbors discovered through the operation of unsolicited messages,
   such as Redirects, are termed 'Transient Neighbors'.

3. Intra-LL and Inter-LL Discovery.

   This document makes a distinction between the discovery of neighbors
   within a Logical Link (intra-LL) and neighbors beyond the LL (inter-
   LL). The goal is to allow both inter- and intra-LL neighbor discovery
   to involve no changes to the host-side IPv6 stack for NBMA
   interfaces.

   Note that section 1.3.1 applies when the NBMA network is being used
   to provide only configured point to point (PVC) service.






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


3.1 Intra-LL - ND over emulated multicast.

   The basic model of ND assumes that a link layer interface will do
   something meaningful with an ICMPv6 packet sent to a multicast IP
   destination address. (IPv6 assumes that multicasting is an integral
   part of the Internet service.) This document assumes multicast
   support will be provided using the RFC 2022 (MARS) [5] service
   (generalized for use over other NBMA technologies in addition to
   ATM).  An IPv6 LL maps directly onto an IPv6 MARS Cluster in the same
   way an IPv4 LIS maps directly onto an IPv4 MARS Cluster.

   The goal of intra-LL operation is that the IPv6 layer must be able to
   simply pass multicast ICMPv6 packets down to the IPv6/NBMA driver
   without any special, NBMA specific processing. The underlying
   mechanism for distributing Neighbor Discovery and Router Discovery
   messages then works as expected.

   Sections 3.1.1 describes the additional functionality that SHALL be
   required of any MARS used in conformance with this document.
   Background discussion of these additions is provided in Appendix B.

3.1.1 Mandatory augmented MARS and MARS Client behavior.

   IPv6/NBMA interfaces SHALL register as MARS Cluster members as
   described in section 4.1, and SHALL send certain classes of outgoing
   IPv6 packets directly to their local MARS as described in section
   4.4.2.

   The MARS itself SHALL then re-transmit these packets according to the
   following rules:

      - When the MARS receives an IPv6 packet, it scans the group
        membership database to find the NBMA addresses of the IPv6
        destination group's members.

      - The MARS then checks to see if every group member currently has
        its pt-pt control VC open to the MARS. If so, the MARS sends a
        copy of the data packet directly to each group member over the
        existing pt-pt VCs.

      - If one or more of the discovered group members do not have an
        open pt-pt VC to the MARS, or if there are no group members
        listed, the packet is sent out ClusterControlVC instead. No
        copies of the packet are sent over the existing (if any) pt-pt
        VCs.






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


3.2 Inter-LL - Redirects, and their generation.

   Shortcut connections are justified on the grounds that demanding
   flows of IP packets may exist between source/destination pairs that
   are separated by IP routing boundaries. Shortcuts are created between
   Transient Neighbors.

   The key to creating transient neighbors is the Redirect message
   (section 8 [7]).  IPv6 allows a router to inform the members of an LL
   that there is a better 'first hop' to a given destination (section
   8.2 [7]).  The advertisement itself is achieved through a Router
   Redirect message, which may carry the link layer address of this
   better hop.

   A transmitting host only listens to Router Redirects from the router
   that is currently acting as the default router for the IP destination
   that the Redirect refers to. If a Redirect arrives that indicates a
   better first hop for a given destination, and supplies a link layer
   (NBMA) address to use as the better first hop, the associated
   Neighbor Cache entry in the source host is updated and its
   reachability set to STALE. Updating the cache in this context
   involves building a new VC to the new NBMA address. If this is
   successful, the old VC is torn down only if it no longer required
   (since the old VC was to the router, it may still be required by
   other packets from the host that are heading to the router).

   Two mechanisms are provided for triggering the discovery of a better
   first hop:

      Router-based flow identification/detection.

      Host-initiated shortcut request.

   Section 3.2.1 discusses flow-based triggers, section 3.2.2 discusses
   the host initiated trigger, and section 3.2.3 discusses the use of
   NHRP to discover mappings for IPv6 targets in remote LLs.

3.2.1 Flow Triggered Redirection.

   The modification of forwarding paths based on the dynamic detection
   of IP packet flows is at the core of models such as the Cell Switch
   Router [11] and the IP Switch [12]. Responsibility for detecting
   flows is placed into the routers, where packets cross the edges of IP
   routing boundaries.







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


   For the purpose of conformance with this document, a router MAY
   choose to initiate the discovery of a better first-hop when it
   determines that an identifiable flow of IP packets are passing
   through it.

      Such a router:

         SHALL only track flows that originate from a directly attached
         host (a host that is within the LL-local scope of one of the
         router's interfaces).

         SHALL NOT use IP packets arriving from another router to
         trigger the generation of a Router Redirect.

         SHALL only consider IPv6 packets with FlowID of zero for the
         purposes of flow detection as defined in this section.

         SHALL utilize NHRP as described in section 3.2.3 to ascertain a
         better first-hop when a suitable flow is detected, and
         advertise the information in a Router Redirect.

   IPv6 routers that support the OPTIONAL flow detection behavior
   described above SHALL support administrative mechanisms to switch off
   flow-detection. They MAY provide mechanisms for adding additional
   constraints to the categories of IPv6 packets that constitute a
   'flow'.

   The actual algorithm(s) for determining what sequence of IPv6 packets
   constitute a 'flow' are outside the scope of this document.  Appendix
   C discusses the rationale behind the use of non-zero FlowID to
   suppress flow detection.

3.2.2 Host Triggered Redirection

   A source host MAY also trigger a redirection to a transient neighbor.
   To support host-triggered redirects, routers conforming to this
   document SHALL recognize specific Neighbor Solicitation messages sent
   by hosts as requests for the resolution of off-link addresses.

   To perform a host-triggered redirect, a source host SHALL:

      Create a Neighbor Solicitation message referring to the off-LL
      destination (target) for which a shortcut is desired

      Address the NS message to the router that would be the next hop
      for traffic sent towards the off-LL target (rather than the
      target's solicited node multicast address).




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


      Use the standard ND hop limit of 255 to ensure the NS won't be
      discarded by the router.

      Include the shortcut limit option defined in appendix D. The value
      of this option should be equal to the hop limit of the data flow
      for which this trigger is being sent. This ensures that the router
      is able to restrict the shortcut attempt to not exceed the reach
      of the data flow.

      Forward the NS packet to the router that would be the next hop for
      traffic sent towards the off-LL target.

   Routers SHALL consider a unicast NS with shortcut limit option as a
   request for a host-triggered redirect. However, actual shortcut
   discovery is OPTIONAL for IPv6 routers.

   When shortcut discovery is not supported, the router SHALL construct
   a Redirect message identifying the router itself as the best
   'shortcut', and return it to the soliciting host.

   If shortcut discovery is to be supported, the router's response SHALL
   be:

      A suitable NHRP Request is constructed and sent as described in
      section 3.2.3.  The original NS message SHOULD be discarded.

      Once the NHRP Reply is received by the originating router, the
      router SHALL construct a Redirect message containing the IPv6
      address of the transient neighbor, and the NBMA link layer address
      returned by the NHRP resolution process.

      The resulting Redirect message SHALL then be transmitted back to
      the source host. When the Redirect message is received, the source
      host SHALL update its Neighbor and Destination caches.

      The off-LL target is now considered a Transient Neighbor.  The
      next packet sent to the Transient Neighbor will result in the
      creation of the direct, shortcut VC (to the off-LL target itself,
      or to the best egress router towards that neighbor as determined
      by NHRP).

      If a NHRP NAK or error indication is received for a host-triggered
      shortcut attempt, the requesting router SHALL construct a Redirect
      message identifying the router itself as the best 'shortcut', and
      return it to the soliciting host.






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


3.2.3 Use of NHRP between routers.

   Once flow detection has occurred, or a host trigger has been
   detected, routers SHALL use NHRP in an NHS to NHS mode to establish
   the IPv6 to link level address mapping of a better first hop.

   IPv6/NBMA routers supporting shortcut discovery will need to perform
   some or all of the following functions:

      - Construct NHRP Requests and Replies.

   - Parse incoming NHRP Requests and Replies from other NHSes
        (routers).

      - Forward NHRP Requests towards an NHS that is topologically
        closer to the IPv6 target.

      - Forward NHRP Replies towards an NHS that is topologically closer
        to the requester.

      - Perform syntax translation between Neighbor Solicitations and
        outbound NHRP Requests.

      - Perform syntax translation between inbound NHRP Replies and
        Redirects.