rfc2491.txt

RFC 的详细文档！

   The destination of the flow that caused the trigger (or the target of
   the host initiated trigger) is used as the target for resolution in a
   NHRP Request. The router then forwards this NHRP Request to the next
   closest NHS. The process continues (as it would for normal NHRP)
   until the Request reaches an NHS that believes the IP target is
   within link-local scope of one of its interfaces.  (This may
   potentially occur within a single router.)

   As NHRP resolution requests always follow the routed path for a given
   target protocol address, the scope of a shortcut request will be
   automatically bounded to the scope of the IPv6 target address.  (e.g.
   resolution requests for site-local addresses will not be forwarded
   across site boundaries.)

   The last hop router SHALL resolve the NHRP Request from mapping
   information contained in its neighbor cache for the interface on
   which the specified target is reachable. If there is no appropriate
   entry in the Neighbor cache, or the destination is currently
   considered unreachable, the last hop router SHALL perform Neighbor
   Discovery on the local interface, and build the NHRP Reply from the
   resulting answer. (Note, in the case where the NHRP Request
   originated due to flow detection, there must already be a hop-by-hop



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


   flow of packets going through the last hop router towards the target.
   In this typical case the Neighbor cache will already have the desired
   information.)

   The NHRP Reply is propagated back to the source of the NHRP Request,
   using a hop-by-hop path as it would for normal NHRP.

   If the discovery process was triggered through flow detection at the
   originating router, the return of the NHRP Reply results in the
   following events:

      A Redirect is constructed using the IPv6/NBMA mapping carried in
      the NHRP Reply.

      The Redirect is unicast to the IP packet flow's source (using the
      VC on which the flow is arriving at the router, if it is a bi-
      directional pt-pt VC).

      Any Redirect message sent by a router MUST conform to all the
      rules described in [7] so that the packet is properly validated by
      the receiving host.  Specifically, if the target of the resulting
      short-cut is the destination host then the ICMP Target Address
      MUST be the same as the ICMP Destination Address in the original
      message.  If the target of the short-cut is an egress router then
      the ICMP Target Address MUST be a Link Local address of the egress
      router that is unique to the NBMA cloud to which the router's NBMA
      interface is attached.

      Also note that egress routers may subsequently redirect the source
      host. To do so, the Link Local ICMP Source Address of the Redirect
      message MUST be the same as the Link Local ICMP Target Address of
      the original Redirect message.

   Note that the router constructing the NHRP Reply does so using the
   NBMA address returned by the target host when the target host first
   accepted the flow of IP traffic. This retains a useful feature of
   Neighbor Discovery - destination interface load sharing.

   Upon receipt of a NHRP NAK reply or error indication for a flow-
   triggered shortcut attempt, no indication is sent to the source of
   the flow.

3.2.3.1  NHRP/ND packet translation rules.

   The following translation rules are meant to augment the packet
   format specification in section 5 of the NHRP specification [8],
   covering those packet fields specifically utilized by the IPv6/NBMA
   architecture.



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


   NHRP messages are constructed and sent according to the rules in [8].
   The value of the NBMA technology specific fields such as ar$afn,
   ar$pro.type, ar$pro.snap and link layer address format are defined in
   NBMA-specific companion documents. Source, destination or client
   protocol addresses in the common header or CIE of a NHRP message are
   always IPv6 addresses of length 16.

   When constructing an host-triggered NHRP resolution request in
   response to a Neighbor Solicitation:

      The ar$hopcnt field MUST be smaller than the shortcut limit value
      specified in the shortcut limit option included in the triggering
      NS message. This ensures that hosts have control over the reach of
      their shortcut request. Note that the shortcut limit given in the
      option is relative to the requesting host, thus the requirement of
      ar$hopcnt being smaller than the given shortcut limit.

      The Flags field in the common header of the NHRP resolution
      request SHOULD have the Q and S bits set.

      The U bit SHOULD be set.  NBMA and protocol source addresses are
      those of the router constructing the request.

      The target address from the NS message is used as the NHRP
      destination protocol address.  A CIE SHALL NOT be specified.

   When constructing a NHRP resolution request as a result of flow
   detection, the choice of values is configuration dependent.

   A NHRP resolution reply is build according to the rules in [8].

      For each CIE returned, the holding time is 10 minutes.

      The MTU may be 0 or a value specified in the NBMA-specific
      companion document.

   A successful NHRP resolution reply for a host-triggered shortcut
   attempt is translated into an IPv6 Redirect message as follows:

   IP Fields:
      Source Address
            The link-local address assigned to the router's interface
            from which this message is sent.
      Destination Address
            IPv6 Source Address of the triggering NS
      Hop Limit
            255




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


   ICMP Fields:
      Target Address
            NHRP Client Protocol Address
      Destination Address
            Target of triggering NS (this is equivalent to the NHRP
            Destination Protocol Address)
      Target link-layer address
            NHRP Client NBMA Address

   All NHRP extensions currently defined in [8] have no effect on
   NHRP/ND translation and MAY be used in NHRP messages for IPv6.

3.2.3.2  NHRP Purge rules.

   Purges are generated by NHRP when changes are detected that
   invalidate a previously issued NHRP Reply (this may include topology
   changes, or a target host going down or changing identity). Any IPv6
   shortcut previously established on the basis of newly purged
   information SHOULD be torn down.

   Routers SHALL keep track of NHRP cache entries for which they have
   issued Neighbor Advertisements or Router Redirects. If a NHRP Purge
   is received that invalidates information previously issued to local
   host, the router SHALL issue a Router Redirect specifying the router
   itself as the new best next-hop for the affected IPv6 target.

   Routers SHALL keep track of Neighbor cache entries that have
   previously been used to generate an NHRP Reply. The expiry of any
   such Neighbor cache entry SHALL result in a NHRP Purge being sent
   towards the router that originally requested the NHRP Reply.

3.3. Neighbor Unreachability Detection.

   Neighbor Solicitations sent for the purposes of Neighbor
   Unreachability Detection (NUD) are unicast to the Neighbor in
   question, using the VC that is already open to that Neighbor. This
   suggests that as far as NUD is concerned, the Transient Neighbor is
   indistinguishable from an On-LL Neighbor.

3.4. Duplicate Address Detection.

   Duplicate Address Detection is only required within the link-local
   scope, which in this case is the LL-local scope. Transient Neighbors
   are outside the scope of the LL. No particular interaction is
   required between the mechanism for establishing shortcuts and the
   mechanism for detection of duplicate link local addresses.





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


4 Node Operation Concepts.

   This section describes node operations for performing basic functions
   (such as sending and receiving data) on a Logical Link.  The
   application of these basic functions to the operation of the various
   IPv6 protocols such as Neighbor Discovery is described in Appendix A.

   The majority of this section applies only to NBMA networks when used
   to provide point to point and point to multipoint SVCs.  Section 7
   discusses the case where the NBMA network is being used to supply
   only point to point PVCs.

4.1.Connecting to a Logical Link.

   Before a node can send or receive IPv6 datagrams its underlying
   IPv6/NBMA interface(s) must first join a Logical Link.

   An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated
   with its Logical Link, and register as a Cluster Member [5].  The
   node's IPv6/NBMA interface will then be a member of the LL, have a
   Cluster Member ID (CMI) assigned, and can begin supporting IPv6 and
   IPv6 ND operations.

   If the node is a host or router starting up it SHALL issue a single
   group MARS_JOIN for the following groups:

      - Its derived Solicited-node address(es) with link-local scope.
      - The All-nodes address with link-local scope.
      - Other configured multicast groups with at least link-local
        scope.

   If the node is a router it SHALL additionally issue:

      - A single group MARS_JOIN for the All-routers address with
        link-local scope.
      - A block MARS_JOIN for the range(s) of IPv6 multicast addresses
        (with greater than link-local scope) for which promiscuous
        reception is required.

   The encapsulation mechanism for, and key field values of, MARS
   control messages SHALL be defined in companion documents specific to
   particular NBMA network technologies.

4.2 Joining a Multicast Group.

   This section describes the node's behavior when it gets a
   JoinLocalGroup request from the IPv6 Layer. The details of how this
   behavior is achieved are going to be implementation specific.



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


   If a JoinLocalGroup for a node-local address is received, the
   IPv6/NBMA driver SHALL return success indication to the caller and
   take no additional action. (Packets sent to node-local addresses
   never reach the IPv6/NBMA driver.)

   If a JoinLocalGroup is received for an address with greater than
   node-local scope, the IPv6/NBMA driver SHALL send an appropriate
   single group MARS_JOIN request to register this address with the
   MARS.

4.3. Leaving a Multicast Group.

   This section describes the node's behavior when it gets a
   LeaveLocalGroup request from the IPv6 Layer. The details of how this
   behavior is achieved are going to be implementation specific.

   If a LeaveLocalGroup for a node-local address is received, the
   IPv6/NBMA driver SHALL return success indication to the caller and
   take no additional action. (Packets sent to node-local addresses
   never reach the IPv6/NBMA driver.)

   If a LeaveLocalGroup is received for an address with greater than
   node-local scope, the IPv6/NBMA driver SHALL send an appropriate
   single group MARS_LEAVE request to deregister this address with the
   MARS.

4.4.  Sending Data.

   Separate processing and encapsulation rules apply for outbound
   unicast and multicast packets.

4.4.1. Sending Unicast Data.

   The IP level 'next hop' for each outbound unicast IPv6 packet is used
   to identify a pt-pt VC on which to forward the packet.

      For NBMA networks where LLC/SNAP encapsulation is typically used
      (e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with the
      following LLC/SNAP header and sent over the VC.

         [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
             (LLC)       (OUI)     (PID)

      For NBMA networks that do not use LLC/SNAP encapsulation, an
      alternative rule SHALL be specified in the NBMA-specific companion
      document.





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


   If no pt-pt VC exists for the next hop address for the packet, the
   node SHALL place a call to set up a VC to the next hop destination.
   Any time the IPv6/NBMA driver receives a unicast packet for
   transmission the IPv6 layer will already have determined the link-
   layer (NBMA) address of the next hop.  Thus, the information needed
   to place the NBMA call to the next hop will be available.

   The sending node SHOULD queue the packet that triggered the call
   request, and send it when the call is established.

   If the call to the next hop destination node fails the sending node
   SHALL discard the packet that triggered the call setup.  Persistent
   failure to create a VC to the next hop destination will be detected
   and handled at the IPv6 Network Layer through NUD.