doc: Add RFC documents

1 files changed, 2467 insertions, 0 deletions

diff --git a/doc/rfc/rfc2491.txt b/doc/rfc/rfc2491.txt
new file mode 100644
index 0000000..4a39310
--- /dev/null
+++ b/doc/rfc/rfc2491.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group                                       G. Armitage
+Request for Comments: 2491                          Lucent Technologies
+Category: Standards Track                                   P. Schulter
+                                              Bright Tiger Technologies
+                                                                M. Jork
+                                                 Digital Equipment GmbH
+                                                              G. Harter
+                                                                 Compaq
+                                                           January 1999
+
+
+        IPv6 over Non-Broadcast Multiple Access (NBMA) networks
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document describes a general architecture for IPv6 over NBMA
+   networks. It forms the basis for subsidiary companion documents that
+   describe details for various specific NBMA technologies (such as ATM
+   or Frame Relay). The IPv6 over NBMA architecture allows conventional
+   host-side operation of the IPv6 Neighbor Discovery protocol, while
+   also supporting the establishment of 'shortcut' NBMA forwarding paths
+   when dynamically signaled NBMA links are available. Operations over
+   administratively configured Point to Point NBMA links are also
+   described.
+
+   Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor
+   Discovery protocol operation within Logical Links, and inter-router
+   NHRP for the discovery of off-Link NBMA destinations. Both flow-
+   triggered and explicitly source-triggered shortcuts are supported.
+
+1. Introduction.
+
+   Non Broadcast Multiple Access (NBMA) networks may be utilized in a
+   variety of ways. At one extreme, they can be used to simply provide
+   administratively configurable point to point service, sufficient to
+   interconnect IPv6 routers (and even IPv6 hosts, in certain
+
+
+
+Armitage, et. al.           Standards Track                     [Page 1]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   situations). At the other extreme, NBMA networks that support dynamic
+   establishment and teardown of Virtual Circuits (or functional
+   equivalents) may be used to emulate the service provided to the IPv6
+   layer by conventional broadcast media such as Ethernet.  Typically
+   this emulation requires complex convergence protocols, particularly
+   to support IPv6 multicast.
+
+   This document describes a general architecture for IPv6 over NBMA
+   networks. It forms the basis for companion documents that provide
+   details specific to various NBMA technologies (for example, ATM [17]
+   or Frame Relay). The IPv6 over NBMA architecture allows conventional
+   host-side operation of the IPv6 Neighbor Discovery protocol, while
+   also supporting the establishment of 'shortcut' NBMA forwarding paths
+   (when dynamically signaled NBMA links are available).
+
+   The majority of this document focuses on the use of dynamically
+   managed point to point and point to multipoint calls between
+   interfaces on an NBMA network. These will be generically referred to
+   as "SVCs" in the rest of the document. The use of administratively
+   configured point to point calls will also be discussed. Such calls
+   will be generically referred to as "PVCs". Depending on context,
+   either may be shortened to "VC".
+
+   Certain NBMA networks may provide a form of connectionless service
+   (e.g. SMDS). In these cases, a "call" or "VC" shall be considered to
+   implicitly exist if the sender has an NBMA destination address to
+   which it can transmit packets whenever it desires.
+
+1.1 Neighbor Discovery.
+
+   A key difference between this architecture and previous IP over NBMA
+   protocols is its mechanism for supporting IPv6 Neighbor Discovery.
+
+   The IPv4 world evolved an approach to address resolution that
+   depended on the operation of an auxiliary protocol operating at the
+   'link layer' - starting with Ethernet ARP (RFC 826 [14]). In the
+   world of NBMA (Non Broadcast, Multiple Access) networks ARP has been
+   applied to IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC 1577
+   [3]). More recently the ION working group has developed NHRP (Next
+   Hop Resolution Protocol [8]), a general protocol for performing
+   intra-subnet and inter-subnet address resolution applicable to a
+   range of NBMA network technologies.
+
+   IPv6 developers opted to migrate away from a link layer specific
+   approach, chosing to combine a number of tasks into a protocol known
+   as Neighbor Discovery [7], intended to be non-specific across a
+   number of link layer technologies.  A key assumption made by Neighbor
+   Discovery's actual protocol is that the link technology underlying a
+
+
+
+Armitage, et. al.           Standards Track                     [Page 2]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   given IP interface is capable of native multicasting.  This is not
+   particularly true of most NBMA network services, and usually requires
+   convergence protocols to emulate the desired service.  (The MARS
+   protocol, RFC 2022 [5], is an example of such a convergence
+   protocol.) This document augments and optimizes the MARS protocol for
+   use in support of IPv6 Neighbor Discovery, generalizing the
+   applicability of RFC 2022 beyond ATM networks.
+
+1.2 NBMA Shortcuts.
+
+   A shortcut is an NBMA level call (VC) directly connecting two IP
+   endpoints that are logically separated by one or more routers at the
+   IP level. IPv6 packets traversing this VC are said to 'shortcut' the
+   routers that are in the logical IPv6 path between the VC's endpoints.
+
+   NBMA shortcuts are a mechanism for minimizing the consumption of
+   resources within an IP over NBMA cloud (e.g. router hops and NBMA
+   VCs).
+
+   It is important that NBMA shortcuts are supported whenever IP is
+   deployed across NBMA networks capable of supporting dynamic
+   establishment of calls (SVCs or functional equivalent).  For IPv6
+   over NBMA, shortcut discovery and management is achieved through a
+   mixture of Neighbor Discovery and NHRP.
+
+1.3 Key components of the IPv6 over NBMA architecture.
+
+1.3.1 NBMA networks providing PVC support.
+
+   When the NBMA network is used in PVC mode, each PVC will connect
+   exactly two nodes and the use of Neighbor Discovery and other IPv6
+   features is limited.  IPv6/NBMA interfaces have only one neighbor on
+   each Link. The MARS and NHRP protocols are NOT necessary, since
+   multicast and broadcast operations collapse down to an NBMA level
+   unicast operation. Dynamically discovered shortcuts are not
+   supported.
+
+   The actual details of encapsulations and link token generation SHALL
+   be covered by companion documents covering specific NBMA technology.
+   They SHALL conform to the following guidelines:
+
+      Both unicast and multicast IPv6 packets SHALL be transmitted over
+      PVC links using the encapsulation described in section 4.4.1.
+
+      Interface tokens for PVC links SHALL be constructed as described
+      in section 5. Interface tokens need only be unique between the two
+      nodes on the PVC link.
+
+
+
+
+Armitage, et. al.           Standards Track                     [Page 3]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+      This use of PVC links does not mandate, nor does it prohibit the
+      use of extensions to the Neighbor Discovery protocol which may be
+      developed for either general use of for use in PVC connections
+      (for example, Inverse Neighbor Discovery).
+
+   NBMA-specific companion documents MAY additionally specify the
+   concatenation of IPv6 over PPP and PPP over NBMA mechanisms as an
+   OPTIONAL approach to point to point IPv6.
+
+   Except where noted above, the remainder of this document focuses on
+   the SVC case.
+
+1.3.2 NBMA networks providing SVC support.
+
+   When the NBMA network is used in SVC mode, the key components are:
+
+      - The IPv6 Neighbor model, where neighbors are discovered through
+        the use of messages multicast to members of an IPv6 interface's
+        local IPv6 Link.
+      - The MARS model, allowing emulation of general multicast using
+        multipoint calls provided by the underlying NBMA network.
+      - The NHRP service for seeking out the NBMA identities of IP
+        interfaces who are logically distant in an IP topological sense.
+      - The modeling of IP traffic as 'flows', and optionally using the
+        existence of a flow as the basis for attempting to set up a
+        shortcut link level connection.
+
+   In summary:
+
+      The IPv6 "Link" is generalized to "Logical Link" (LL) in NBMA
+      environments (analogous to the generalization of IPv4 IP Subnet to
+      Logical IP Subnet in RFC 1209 and subsequently RFC 1577).
+
+      IPv6/NBMA interfaces utilize RFC 2022 (MARS) for general intra-
+      Logical Link multicasting. The MARS itself is used to optimally
+      distribute discovery messages within the Logical Link.
+
+      For destinations not currently considered to be Neighbors, a host
+      sends the packets to one of its default routers.
+
+      When appropriately configured, the egress router from a Logical
+      Link is responsible for detecting the existence of an IP packet
+      flow through it that might benefit from a shortcut connection.
+
+         While continuing to conventionally forward the flow's packets,
+         the router initiates an NHRP query for the flow's destination
+         IP address.
+
+
+
+
+Armitage, et. al.           Standards Track                     [Page 4]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+         The last router/NHS before the target of the NHRP query
+         ascertains the target interface's preferred NBMA address.
+
+         The originally querying router then issues a Redirect to the IP
+         source, identifying the flow's destination as a transient
+         Neighbor.
+
+      Host-initiated triggering of shortcut discovery, regardless of the
+      existence of a packet flow, is also supported through specific
+      Neighbor Solicitations sent to a source host's default router.
+
+   A number of key advantages are claimed for this approach. These are:
+
+      The IPv6 stacks on hosts do not implement separate ND protocols
+      for each link layer technology.
+
+      When the destination of a flow is solicited as a transient
+      neighbor, the returned NBMA address will be the one chosen by the
+      destination when the flow was originally established through hop-
+      by-hop processing. This supports the existing ND ability for IPv6
+      destinations to perform their own dynamic interface load sharing.
+
+1.4 Terminology.
+
+   The bit-pattern or numeric value used to identify a particular NBMA
+   interface at the NBMA level will be referred to as an "NBMA address".
+   (An example would be an ATM End System Address, AESA, when applying
+   this architecture to ATM networks, or an E.164 number when applying
+   this architecture to SMDS networks.)
+
+   The call that, once established, is used to transfer IP packets from
+   one NBMA interface to another will be referred to as an SVC or PVC
+   depending on whether the call is dynamically established through some
+   signaling mechanism, or administratively established. The specific
+   signaling mechanisms used to establish or tear down an SVC will be
+   defined in the NBMA-specific companion specifications.  Certain NBMA
+   networks may provide a form of connectionless service (e.g. SMDS). In
+   these cases, a "call" or "SVC" shall be considered to implicitly
+   exist if the sender has an NBMA destination address to which it can
+   transmit packets whenever it desires.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [16].
+
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                     [Page 5]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+1.5 Document Structure.
+
+   The remainder of this document is structured as follows: Section 2
+   explains the generalization of IPv6 Link to "Logical Link" when used
+   over NBMA networks, and introduces the notion of the Transient
+   Neighbor.  Section 3 describes the modifications to the MARS protocol
+   for efficient distribution of ND messages within a Logical Link, and
+   the rules and mechanisms for discovering Transient Neighbors.
+   Section 4 covers the basic rules governing IPv6/NBMA interface
+   initialization, packet and control message encapsulations, and rules
+   for SVC management. Section 5 describes the general rules for
+   constructing Interface Tokens, the Link Layer Address Option, and
+   Link Local addresses.  Section 6 concludes the normative sections of
+   the document.  Appendix A provides some non-normative descriptive
+   text regarding the operation of Ipv6 Neighbor Discovery.  Appendix B
+   describes some sub-optimal solutions for emulating the multicasting
+   of Neighbor Discovery messages around a Logical Link.  Appendix C
+   discusses shortcut suppression and briefly reviews the future
+   relationships between flow detection and mapping of flows onto SVCs
+   of differing qualities of service.
+
+2. Logical Links, and Transient Neighbors.
+
+
+   IPv6 contains a concept of on-link and off-link. Neighbors are those
+   nodes that are considered on-link and whose link-layer addresses may
+   therefore be located using Neighbor Discovery.  Borrowing from the
+   terminology definitions in the ND text:
+
+   on-link   - an address that is assigned to a neighbor's interface on
+               a shared link.  A host considers an address to be on-
+               link if:
+                 - it is covered by one of the link's prefixes, or
+                 - a neighboring router specifies the address as the
+                   target of a Redirect message, or
+                 - a Neighbor Advertisement message is received for the
+                   target address, or
+                 - a Neighbor Discovery message is received from the
+                   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.
+
+   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.
+
+   At this time no rules are specified for mapping outbound packets to
+   VCs using anything more than the packet's destination address.
+
+4.4.2. Sending Multicast Data.
+
+   The IP level 'next hop' for each outbound multicast IPv6 packet is
+   used to identify a pt-pt or pt-mpt VC on which to forward the packet.
+
+      For NBMA networks where LLC/SNAP encapsulation is typically used
+      (e.g. ATM or SMDS), multicast packets SHALL be encapsulated in the
+      following manner:
+
+         [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
+         packet]
+             (LLC)       (OUI)     (PID)    (mars encaps)
+
+         The IPv6/NBMA driver's Cluster Member ID SHALL be copied into
+         the 2 octet pkt$cmi field prior to transmission.
+
+      For NBMA networks that do not use LLC/SNAP encapsulation, an
+      alternative rule SHALL be specified in the NBMA-specific companion
+      document. Some mechanism for carrying the IPv6/NBMA driver's
+      Cluster Member ID SHALL be provided.
+
+   If the packet's destination is one of the following multicast
+   addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt
+   VC to the MARS:
+
+      - A Solicited-node address with link-local scope.
+      - The All-nodes address with link-local scope.
+      - The All-routers address with link-local scope.
+      - A DHCP-v6 relay or server multicast address.
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 18]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   The MARS SHALL then redistribute the IPv6 packet as described in
+   section 3.1.1.  (If the VC to the MARS has been idle timed out for
+   some reason, it MUST be re-established before forwarding the packet
+   to the MARS.)
+
+   If packet's destination is any other address, then the usual MARS
+   client mechanisms are used by the IPv6/NBMA driver to select and/or
+   establish a pt-mpt VC on which the packet is to be sent.
+
+   At this time no rules are specified for mapping outbound packets to
+   VCs using anything more than the packet's destination address.
+
+4.5. Receiving Data.
+
+   Packets received using the encapsulation shown in section 4.4.1 SHALL
+   be de-encapsulated and passed up to the IPv6 layer.  The IPv6 layer
+   then determines how the incoming packet is to be handled.
+
+   Packets received using the encapsulation specified in section 4.4.2
+   SHALL have their pkt$cmi field compared to the local IPv6/NBMA
+   driver's own CMI.  If the pkt$cmi in the header matches the local CMI
+   the packet SHALL be silently dropped.  Otherwise, the packet SHALL be
+   de-encapsulated and passed to the IPv6 layer.  The IPv6 layer then
+   determines how the incoming packet is to be handled.
+
+   For NBMA networks that do not use LLC/SNAP encapsulation, alternative
+   rules SHALL be specified in the NBMA-specific companion document.
+
+   The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6
+   packets arriving with encapsulation defined for unicast packets, nor
+   attempt to filter out unicast IPv6 packets arriving with
+   encapsulation defined for multicast packets.
+
+4.6. VC Setup and release for unicast data.
+
+   Unicast VCs are maintained separately from multicast VCs.  The setup
+   and maintenance of multicast VCs are handled by the MARS client in
+   each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-pt
+   VCs for unicast IPv6 traffic will be described here.  Only best
+   effort unicast VCs are considered.  The creation of VCs for other
+   classes of service is outside the scope of this document.
+
+   Before sending a packet to a new destination within the same LL a
+   node will first perform a Neighbor Discovery on the intra-LL target.
+   This is done to resolve the IPv6 destination address into a link-
+   layer address which the sender can then use to send unicast packets.
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 19]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   Appendix A.1.1 contains non-normative, descriptive text covering the
+   Neighbor Solicitation/Advertisement exchange and eventual
+   establishment of a new SVC.
+
+   A Redirect message (either a redirect to a node on the same LL, or a
+   shortcut redirect to a node outside the LL) results in the sending
+   (redirected) node creating a new pt-pt VC to a new receiving node.
+   the Redirect message SHALL contain the link layer (NBMA) address of
+   the new receiving IPv6/NBMA interface.  The redirected node does not
+   concern itself where the new receiving node is located on the NBMA
+   network.  The redirected node will set up a pt-pt VC to the new node
+   if one does not previously exist.  The redirected node will then use
+   the new VC to send data rather than whatever VC it had previously
+   been using.
+
+   Redirects are unidirectional.  Even after the source has reacted to a
+   redirect, the destination will continue to send IPv6 packets back to
+   the redirected node on the old path.  This happens because the
+   destination node has no way of determining the IPv6 address of the
+   other end of a new VC in the absence of Neighbor Discovery. Thus,
+   redirects will not result in both ends of a connection using the new
+   VC. IPv6 redirects are not intended to provide symmetrical
+   redirection.  If the non-redirected node eventually receives a
+   redirect it MAY discover the existing VC to the target node and use
+   that rather than creating a new VC.
+
+   It is desirable that VCs are released when no longer needed.
+
+      An IPv6/NBMA driver SHALL release any VC that has been idle for 20
+      minutes.
+
+   This time limit MAY be reduced through configuration or as specified
+   in companion documents for specific NBMA networks.
+
+   If a Neighbor or Destination cache entry is purged then any VCs
+   associated with the purged entry SHOULD be released.
+
+   If the state of an entry in the Neighbor cache is set to STALE, then
+   any VCs associated with the stale entry SHOULD be released.
+
+4.7 NBMA SVC Signaling Support and MTU issues.
+
+   Mechanisms for signaling the establishment and teardown of pt-pt and
+   pt-mpt SVCs for different NBMA networks SHALL be specified in
+   companion documents.
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 20]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   Since any given IPv6/NBMA driver will not know if the remote end of a
+   VC is in the same LL, drivers SHALL implement NBMA-specific
+   mechanisms to negotiate acceptable MTUs at the VC level. These
+   mechanisms SHALL be specified in companion documents.
+
+   However, IPv6/NBMA drivers can assume that they will always be
+   talking to another driver attached to the same type of NBMA network.
+   (For example, an IPv6/NBMA driver does not need to consider the
+   possibility of establishing a shortcut VC directly to an IPv6/FR
+   driver.)
+
+5. Interface Tokens, Link Layer Address Options, Link-Local Addresses
+
+5.1 Interface Tokens
+
+   Each IPv6 interface must have an interface token from which to form
+   IPv6 autoconfigured addresses. This interface token must be unique
+   within a Logical Link to prevent the creation of duplicate addresses
+   when stateless address configuration is used.
+
+   In cases where two nodes on the same LL produce the same interface
+   token then one interface MUST choose another host-token.  All
+   implementations MUST support manual configuration of interface tokens
+   to allow operators to manually change a interface token on a per-LL
+   basis.  Operators may choose to manually set interface tokens for
+   reasons other than eliminating duplicate addresses.
+
+   All interface tokens MUST be 64 bits in length and formatted as
+   described in the following sections.  The hosts tokens will be based
+   on the format of an EUI-64 identifier [10]. Refer to [19 - Appendix
+   A] for a description of creating IPv6 EUI-64 based interface
+   identifiers.
+
+5.1.1 Single Logical Links on a Single NBMA Interface
+
+   Physical NBMA interfaces will generally have some local identifier
+   that may be used to generate a unique IPv6/NBMA interface token. The
+   exact mechanism for generating interface tokens SHALL be specified in
+   companion documents specific to each NBMA network.
+
+5.1.2 Multiple Logical Links on a Single NBMA Interface
+
+   Physical NBMA interfaces MAY be used to provide multiple logical NBMA
+   interfaces. Since each logical NBMA interface MAY support an
+   independent IPv6 interface, two separate scenarios are possible:
+
+      - A single host with separate IPv6/NBMA interfaces onto a number
+        of independent Logical Links.
+
+
+
+Armitage, et. al.           Standards Track                    [Page 21]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+      - A set of 2 or more 'virtual hosts' (vhosts) sharing a common
+        NBMA driver. Each vhost is free to establish IPv6/NBMA
+        interfaces associated with different or common LLs. However,
+        vhosts are bound by the same requirement as normal hosts - no
+        two interfaces to the same LL can share the same interface
+        token.
+
+   In the first scenario, since each IPv6/NBMA interface is associated
+   with a different LL, each interface's external identity can be
+   differentiated by the LL's routing prefix.  Thus, the host can re-use
+   a single unique interface token across all its IPv6/NBMA interfaces.
+   (Internally the host will tag received packets in some locally
+   specific manner to identify what IPv6/NBMA interface they arrived on.
+   However, this is an issue generic to IPv6, and does not required
+   clarification in this document.)
+
+   The second scenario is more complex, but likely to be rarer.
+
+   When supporting multiple logical NBMA interfaces over a single
+   physical NBMA interface, independent and unique identifiers SHALL be
+   generated for each virtual NBMA interface to enable the construction
+   of unique IPv6/NBMA interface tokens.  The exact mechanism for
+   generating interface tokens SHALL be specified in companion documents
+   specific to each NBMA network.
+
+5.2 Link Layer Address Options
+
+   Neighbor Discovery defines two option fields for carrying link-layer
+   specific source and target addresses.
+
+   Between IPv6/NBMA interfaces, the format for these two options is
+   adapted from the MARS [5] and NHRP [8] specs. It SHALL be:
+
+          [Type][Length][NTL][STL][..NBMA Number..][..NBMA
+          Subaddress..]
+          |   Fixed    ||            Link layer address
+          |
+
+   [Type] is a one octet field.
+
+          1 for Source link-layer address.
+          2 for Target link-layer address.
+
+   [Length] is a one octet field.
+
+   The total length of the option in multiples of 8 octets. Zeroed bytes
+   are added to the end of the option to ensure its length is a multiple
+   of 8 octets.
+
+
+
+Armitage, et. al.           Standards Track                    [Page 22]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   [NTL] is a one octet 'Number Type & Length' field.
+
+   [STL] is a one octet 'SubAddress Type & Length' field.
+
+   [NBMA Number] is a variable length field. It is always present. This
+   contains the primary NBMA address.
+
+   [NBMA Subaddress] is a variable length field. It may or may not be
+   present. This contains any NBMA subaddress that may be required.
+
+   If the [NBMA Subaddress] is not present, the option ends after the
+   [NBMA Number] ( and any additional padding for 8 byte alignment).
+
+   The contents and interpretation of the [NTL], [STL], [NBMA Number],
+   and [NBMA Subaddress] fields are specific to each NBMA network, and
+   SHALL be specified in companion documents.
+
+5.3 Link-Local Addresses
+
+   The IPv6 link-local address is formed by appending the interface
+   token, as defined above, to the prefix FE80::/64.
+
+          10 bits            54 bits                  64 bits
+      +----------+-----------------------+----------------------------+
+      |1111111010|         (zeros)       |      Interface Token       |
+      +----------+-----------------------+----------------------------+
+
+6. Conclusion and Open Issues
+
+   This document describes a general architecture for IPv6 over NBMA
+   networks. It forms the basis for subsidiary companion documents that
+   provide details for various specific NBMA technologies (such as ATM
+   or Frame Relay). The IPv6 over NBMA architecture allows conventional
+   host-side operation of the IPv6 Neighbor Discovery protocol, while
+   also supporting the establishment of 'shortcut' NBMA forwarding paths
+   (when dynamically signaled NBMA links are available).
+
+   The IPv6 "Link" is generalized to "Logical Link" in an analagous
+   manner to the IPv4 "Logical IP Subnet".  The MARS protocol is
+   augmented and used to provide relatively efficient intra Logical Link
+   multicasting of IPv6 packets, and distribution of Discovery messages.
+   Shortcut NBMA level paths are supported either through router based
+   flow detection, or host originated explicit requests.  Neighbor
+   Discovery is used without modification for all intra-LL control
+   (including the initiation of NBMA shortcut discovery).  Router to
+   router NHRP is used to obtain the IPv6/NBMA address mappings for
+   shortcut targets outside a source's Logical Link.
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 23]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+7. Security Considerations
+
+   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: gja@lucent.com
+
+
+   Peter Schulter
+   Bright Tiger Technologies
+   125 Nagog Park
+   Acton, MA 01720
+
+   EMail: paschulter@acm.org
+
+
+   Markus Jork
+   European Applied Research Center
+   Digital Equipment GmbH
+   CEC Karlsruhe
+   Vincenz-Priessnitz-Str. 1
+   D-76131 Karlsruhe
+   Germany
+
+   EMail: jork@kar.dec.com
+
+
+   Geraldine Harter
+   Digital UNIX Networking
+   Compaq Computer Corporation
+   110 Spit Brook Road
+   Nashua, NH 03062
+
+   EMail: harter@zk3.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 Advertisements
+   announcing their availability on the LL.  When an IPv6 router sends
+   an unsolicited Router Advertisement, it sends a data packet addressed
+   to the IPv6 all-nodes multicast address. When the local node
+   IPv6/NBMA driver gets the Router Advertisement message from the IPv6
+   network layer, it transmits the message by following steps described
+   in section 4.4.2.  The MARS will transmit the packet on the LL's
+
+
+
+Armitage, et. al.           Standards Track                    [Page 29]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   ClusterControlVC, which sends the packets to all nodes on the LL.
+   Each node on the LL will then process the incoming packet as
+   described in section 4.5 and pass the received packet to the IPv6
+   Network layer for processing as appropriate.
+
+   To perform Router Discovery, an IPv6 host sends a Router Solicitation
+   message to the all-routers multicast address. When the local node
+   IPv6/NBMA driver gets the request from the IPv6 Network Layer to send
+   the packet, it follows the steps described in section 4.4.2.  The RS
+   message will be sent to either those nodes which have joined the
+   all-routers multicast group or to all nodes.  The nodes which receive
+   the RA message will process the message as described in section 4.5
+   and pass the RA message up to the IPv6 layer for processing.  Only
+   those nodes which are routers will process the message and respond to
+   it.
+
+   An IPv6 router responds to a Router Solicitation by sending a Router
+   Advertisement addressed to the IPv6 all-nodes multicast address if
+   the source address of the Router Solicitation was the unspecified
+   address.  If the source address in the Router Solicitation is not the
+   unspecified address, the the router will unicast the Router
+   Advertisement to the soliciting node.  If the router sends the Router
+   Advertisement to the all-nodes multicast address then it follows the
+   steps described above for unsolicited Router Advertisements.
+
+   If the Router Advertisement is to be unicast to the soliciting node,
+   the IPv6 network layer will give the node's IPv6/NBMA driver the
+   Router Advertisement and link-layer address of the soliciting node
+   (obtained through Address Resolution if necessary) which will send
+   the packet according to the steps described in section 4.4.1 This
+   will result in a new pt-pt VC being created between the router and
+   the soliciting node if one did not already exist.
+
+   The soliciting node will receive and process the Router Advertisement
+   as described in section 4.5 and will pass the RA message to the IPv6
+   network layer.  The IPv6 network layer may, depending on the state of
+   the Neighbor cache entry, update the Neighbor cache with the router's
+   NBMA address, contained in the Router Advertisement message's Source
+   Link-Layer Address Option.
+
+   If a pt-pt VC is set up during Router Discovery, subsequent IPv6 best
+   effort unicast data between the soliciting node and the router will
+   be transmitted over the new PtP VC.
+
+
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 30]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+A.1.3 Performing Neighbor Unreachability Detection (NUD)
+
+   Neighbor Unreachability Detection (NUD) is the process by which an
+   IPv6 host determines that a neighbor is no longer reachable, as
+   described in [7]. Each Neighbor cache entry contains information used
+   by the NUD algorithm to detect reachability failures.  Confirmation
+   of a neighbor's reachability comes either from upper-layer protocol
+   indications that data recently sent to the neighbor was received, or
+   from the receipt of a Neighbor Advertisement message in response to a
+   Neighbor Solicitation probe.
+
+   Connectivity failures at the node's IPv6/NBMA driver, such as
+   released VCs (see section 4.6) and the inability to create a VC to a
+   neighbor (see section 4.4.1), are detected and handled at the IPv6
+   network layer, through Neighbor Unreachability Detection.  The node's
+   IPv6/NBMA driver does not attempt to detect or recover from these
+   conditions.
+
+   A persistent failure to create a VC from the IPv6 host to one of its
+   IPv6 neighbors will be detected and handled through NUD. On each
+   attempt to send data from the IPv6 host to its neighbor, the node's
+   IPv6/NBMA driver will attempt to set up a VC to the neighbor, and
+   failing to do so, will drop the packet. IPv6 reachability
+   confirmation timers will eventually expire, and the neighbor's
+   Neighbor cache entry will enter the PROBE state. The PROBE state will
+   cause the IPv6 host to unicast Neighbor Solicitations to the
+   neighbor, which will be dropped by the local node's IPv6/NBMA driver
+   after again failing to setup the VC. The IPv6 host will therefore
+   never receive the solicited Neighbor Advertisements needed for
+   reachability confirmation, causing the neighbor's entry to be deleted
+   from the Neighbor cache. The next time the IPv6 host tries to send
+   data to that neighbor, address resolution will be performed.
+   Depending on the reason for the previous failure, connectivity to the
+   neighbor could be re-established (for example, if the previous VC
+   setup failure was caused by an obsolete link-layer address in the
+   Neighbor cache).
+
+   In the event that a VC from an IPv6 neighbor is released, the next
+   time a packet is sent from the IPv6 host to the neighbor, the node's
+   IPv6/NBMA driver will recognize that it no longer has a VC to that
+   neighbor and attempt to setup a new VC to the neighbor.  If, on the
+   first and on subsequent transmissions, the node is unable to create a
+   VC to the neighbor, NUD will detect and handle the failure as
+   described earlier (handling the persistent failure to create a VC
+   from the IPv6 host to one of its IPv6 neighbors). Depending on the
+   reason for the previous failure, connectivity to the neighbor may or
+   may not be re-established.
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 31]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+A.1.4 Performing Duplicate Address Detection (DAD)
+
+   An IPv6 host performs Duplicate Address Detection (DAD) to determine
+   that the address it wishes to use on the LL (i.e. a tentative
+   address) is not already in use, as described in [9] and [7].
+   Duplicate Address Detection is performed on all addresses the host
+   wishes to use, regardless of the configuration mechanism used to
+   obtain the address.
+
+   Prior to performing Duplicate Address Detection, a host will join the
+   all-nodes multicast address and the solicited-node multicast address
+   corresponding to the host's tentative address (see 4.2.  Joining a
+   Multicast Group). The IPv6 host initiates Duplicate Address Detection
+   by sending a Neighbor Solicitation to solicited-node multicast
+   address corresponding to the host's tentative address, with the
+   tentative address as the target.  When the local node's IPv6/NBMA
+   driver gets the Neighbor Solicitation message from the IPv6 network
+   layer, it follows the steps outlined in section 4.4.2.  The NS
+   message will be sent to those nodes which joined the target
+   solicited-node multicast group or to all nodes.  The DAD NS message
+   will be received by one or more nodes on the LL and processed by each
+   as described in section 4.5.  Note that the MARS client of the
+   sending node will filter out the message so that the sending node's
+   IPv6 network layer will not see the message.  The IPv6 network layer
+   of any node which is not a member of the target solicited-node
+   multicast group will discard the Neighbor Solicitation message.
+
+   If no other hosts have joined the solicited-node multicast address
+   corresponding to the tentative address, then the host will not
+   receive a Neighbor Advertisement containing its tentative address as
+   the target.  The host will perform the retransmission logic described
+   in [9], terminate Duplicate Address Detection, and assign the
+   tentative address to the NBMA interface.
+
+   Otherwise, other hosts on the LL that have joined the solicited-node
+   multicast address corresponding to the tentative address will process
+   the Neighbor Solicitation. The processing will depend on whether or
+   not receiving IPv6 host considers the target address to be tentative.
+
+   If the receiving IPv6 host's address is not tentative, the host will
+   respond with a Neighbor Advertisement containing the target address.
+   Because the source of the Neighbor Solicitation is the unspecified
+   address, the host sends the Neighbor Advertisement to the all-nodes
+   multicast address following the steps outlined in section 4.4.2.  The
+   DAD NA message will be received and processed by the MARS clients on
+   all nodes in the LL as described in section 4.5.  Note that the
+   sending node will filter the incoming message since the CMI in the
+   message header will match that of the receiving node.  All other
+
+
+
+Armitage, et. al.           Standards Track                    [Page 32]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   nodes will de-encapsulate the message and pass it to the IPv6 network
+   layer.  The host performing DAD will detect that its tentative
+   address is the target of the Neighbor Advertisement, and determine
+   that the tentative address is not unique and cannot be assigned to
+   its NBMA interface.
+
+   If the receiving IPv6 host's address is tentative, then both hosts
+   are performing DAD using the same tentative address. The receiving
+   host will determine that the tentative address is not unique and
+   cannot be assigned to its NBMA interface.
+
+A.1.5 Processing Redirects
+
+   An IPv6 router uses a Redirect Message to inform an IPv6 host of a
+   better first-hop for reaching a particular destination, as described
+   in [7].  This can be used to direct hosts to a better first hop
+   router, another host on the same LL, or to a transient neighbor on
+   another LL.  The IPv6 router will unicast the Redirect to the IPv6
+   source address that triggered the Redirect. The router's IPv6/NBMA
+   driver will transmit the Redirect message using the procedure
+   described in section 4.4.1.  This will create a VC between the router
+   and the redirected host if one did not previously exist.
+
+   The IPv6/NBMA driver of the IPv6 host that triggered the Redirect
+   will receive the encapsulated Redirect over one of it's pt-pt VCs.
+   It will the de-encapsulate the packet, and pass the Redirect message
+   to the IPv6 Network Layer, as described section 4.5.
+
+   Subsequent data sent from the IPv6 host to the destination will be
+   sent to the next-hop address specified in the Redirect Message.  For
+   NBMA networks, the Redirect Message should contain the link-layer
+   address option as described in [7] and section 5.2, thus the
+   redirected node will not have to perform a Neighbor Solicitation to
+   learn the link-layer address of the node to which it has been
+   redirected.  Thus, the redirect can be to any node on the NBMA
+   network, regardless of the LL membership of the new target node.
+   This allows NBMA hosts to be redirected off their LL to achieve
+   shortcut by using standard IPv6 protocols.
+
+   Once redirected, the IPv6 network layer will give the node's
+   IPv6/NBMA driver the IPv6 packet and the link-layer address of the
+   next-hop node when it sends data to the redirected destination. The
+   node's IPv6/NBMA driver will determine if a VC to the next-hop
+   destination exists.  If a pt-pt VC does not exist, then the IPv6/NBMA
+   driver will queue the data packet and initiate a setup of a VC to the
+   destination.  When the VC is created, or if one already exists, then
+   the node will encapsulate the outgoing data packet and send it on the
+   VC.
+
+
+
+Armitage, et. al.           Standards Track                    [Page 33]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   Note that Redirects are unidirectional.  The redirected host will
+   create a VC to the next-hop destination as specified in the Redirect
+   message, but the next-hop will not be redirected to the source host.
+   Because no Neighbor Discovery takes place, the next-hop destination
+   has no way of determining the identity of the caller when it receives
+   the new VC.  Also, since ND does not take place on redirects, the
+   next-hop receives no event that would cause it to update it's
+   neighbor or destination caches.  However, it will continue to
+   transmit data back to the redirected host on the former path to the
+   redirected host.  The next-hop node should be able to use the new VC
+   from the redirected destination if it too receives a redirect
+   redirecting it to the redirected node.  This behavior is consistent
+   with [7].
+
+A.2 Address Configuration
+
+   IPv6 addresses are auto-configured using the stateless or stateful
+   address auto-configuration mechanisms, as described in [9] and [18].
+   The IPv6 auto-configuration process involves creating and verifying
+   the uniqueness of a link-local address on an LL, determining whether
+   to use stateless and/or stateful configurationmechanisms to obtain
+   addresses, and determining if other (non- address) information is to
+   be autoconfigured. IPv6 addresses can also be manually configured, if
+   for example, auto-configuration fails because the autoconfigured
+   link-local address is not unique.  An LL administrator specifies the
+   type of autoconfiguration to use; the hosts on an LL receive this
+   autoconfiguration information through Router Advertisement messages.
+
+   The following sections describe how stateless, stateful and manual
+   address configuration will work in an IPv6/NBMA environment.
+
+A.2.1 Stateless Address Configuration
+
+   IPv6 stateless address configuration is the process by which an IPv6
+   host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
+
+   When an IPv6 host first starts up, it generates a link-local address
+   for the interface attached to the Logical Link.  It then verifies the
+   uniqueness of the link-local address using Duplicate Address
+   Detection (DAD).  If the IPv6 host detects that the link-local
+   address is not unique, the autoconfiguration process terminates.  The
+   IPv6 host must then be manually configured.
+
+   After the IPv6 host determines that the link-local address is unique
+   and has assigned it to the interface on the Logical Link, the IPv6
+   host will perform Router Discovery to obtain auto-configuration
+   information.  The IPv6 host will send out a Router Solicitation and
+   will receive a Router Advertisement, or it will wait for an
+
+
+
+Armitage, et. al.           Standards Track                    [Page 34]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   unsolicited Router Advertisement.  The IPv6 host will process the M
+   and O bits of the Router Advertisement, as described in [9] and as a
+   result may invoke stateful address auto- configuration.
+
+   If there are no routers on the Logical Link, the IPv6 host will be
+   able to communicate with other IPv6 hosts on the Logical Link using
+   link-local addresses. The IPv6 host will obtain a neighbor's link-
+   layer address using Address Resolution. The IPv6 host will also
+   attempt to invoke stateful auto-configuration, unless it has been
+   explicitly configured not to do so.
+
+A.2.2 Stateful  Address Configuration (DHCP)
+
+   IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to
+   perform stateful address auto-configuration, as described in [18].
+
+   A DHCPv6 server or relay agent is present on a Logical Link that has
+   been configured with manual or stateful auto-configuration. The
+   DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay-
+   Agent multicast group on the Logical Link. When the node's IPv6/NBMA
+   driver gets the JoinLocalGroup request from the IPv6 network layer,
+   it follows the process described in section 4.2.
+
+   An IPv6 host will invoke stateful auto-configuration if M and O bits
+   of Router Advertisements indicate it should do so, and may invoke
+   stateful auto-configuration if it detects that no routers are present
+   on the Logical Link. An IPv6 host that is obtaining configuration
+   information through the stateful mechanism will hereafter be referred
+   to as a DHCPv6 client.
+
+   A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv6
+   Server/Relay-Agent multicast address to locate a DHCPv6 Agent. When
+   the soliciting node's IPv6/NBMA driver gets the request from the IPv6
+   Network Layer to send the packet, it follows the steps described in
+   section 4.4.2.  This will result in one or more nodes on the LL
+   receiving the message.  Each node that receives the solicitation
+   packet will process it as described in section section 4.5. Only the
+   IPv6 network layer of the DHCPv6 server/relay-agent will accept the
+   packet and process it.
+
+   A DHCPv6 Server or Relay Agent on the Logical Link will unicast a
+   DHCPv6 Advertisement to the DHCPv6 client. The IPv6 network layer
+   will give the node's IPv6/NBMA driver the packet and link-layer
+   address of the DHCPv6 client (obtained through Neighbor Discovery if
+   necessary).  The node IPv6/NBMA driver will then transmit the packet
+   as described in section 4.4.1.  This will result in a new pt-pt VC
+   being created between the server and the client if one did not
+   previously exist.
+
+
+
+Armitage, et. al.           Standards Track                    [Page 35]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   The DHCP client's IPv6/NBMA driver will receive the encapsulated
+   packet from the DHCP Server or Relay Agent, as described in section
+   4.5. The node will de-encapsulate the multicast packet and then pass
+   it up to the IPv6 Network Layer for processing. The IPv6 network
+   layer will deliver the DHCPv6 Advertise message to the DHCPv6 client.
+
+   Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are
+   unicast between the DHCPv6 client and the DHCPv6 Server.  Depending
+   on the reachability of the DHCPv6 client's address, messages
+   exchanged between a DHCPv6 client and a DHCPv6 Server on another LL
+   are sent either via a router or DHCPv6 Relay-Agent.  Prior to sending
+   the DHCPv6 message, the IPv6 network layer will perform Neighbor
+   Discovery (if necessary) to obtain the link-layer address
+   corresponding to the packet's next-hop. A pt-pt VC will be set up
+   between the sender and the next hop, and the encapsulated packet
+   transmitted over it, as described in 4.4. Sending Data.
+
+A.2.3 Manual Address Configuration
+
+   An IPv6 host will be manually configured if it discovers through DAD
+   that its link-local address is not unique. Once the IPv6 host is
+   configured with a unique interface token, the auto-configuration
+   mechanisms can then be invoked.
+
+A.3 Internet Group Management Protocol (IGMP)
+
+   IPv6 multicast routers will use the IGMPv6 protocol to periodically
+   determine group memberships of local hosts.  In the framework
+   described here, the IGMPv6 protocols can be used without any special
+   modifications for NBMA.  While these protocols might not be the most
+   efficient in this environment, they will still work as described
+   below.  However, IPv6 multicast routers connected to an NBMA LL could
+   optionally optimize the IGMP functions by sending
+   MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and
+   determining group memberships by the MARS_GROUPLIST_REPLY messages.
+   Querying the MARS for multicast group membership is an optional
+   enchancement and is not required for routers to determine IPv6
+   multicast group membership on a LL.
+
+   There are three ICMPv6 message types that carry multicast group
+   membership information: the Group Membership Query, Group Membership
+   Report and Group Membership Reduction messages.  IGMPv6 will continue
+   to work unmodified over the IPv6/NBMA architecture described in this
+   document.
+
+   An IPv6 multicast router receives all IPv6 multicast packets on the
+   LL by joining all multicast groups in promiscuous mode [5].  The MARS
+   server will then cause the multicast router to be added to all
+
+
+
+Armitage, et. al.           Standards Track                    [Page 36]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   existing and future multicast VCs.  The IPv6 multicast router will
+   thereafter be the recipient of all IPv6 multicast packets sent within
+   the Logical Link.
+
+   An IPv6 multicast router discovers which multicast groups have
+   members in the Logical Link by periodically sending Group Membership
+   Query messages to the IPv6 all-nodes multicast address.  When the
+   local node's IPv6/NBMA driver gets the request from the IPv6 network
+   layer to send the Group Membership Query packet, it follows the steps
+   described in 4.4.2. The node determines that the destination address
+   of the packet is the all-nodes multicast address and passes the
+   packet to the node's MARS client where the packet is encapsulated and
+   directly transmitted to the MARS. The MARS then relays the packet to
+   all nodes in the LL. Each node's IPv6/NBMA drivers will receive the
+   packet, de-encapsulate it, and passed it up to the IPv6 Network
+   layer.  If the originating node receives the encapsulated packet, the
+   packet will be filtered out by the MARS client since the Cluster
+   Member ID of the receiving node will match the CMI in the packet's
+   MARS encapsulation header.
+
+   IPv6 hosts in the Logical Link will respond to a Group Membership
+   Query with a Group Membership Report for each IPv6 multicast group
+   joined by the host.  IPv6 hosts can also transmit a Group Membership
+   Report when the host joins a new IPv6 multicast group.  The Group
+   Membership Report is sent to the multicast group whose address is
+   being reported. When the local node IPv6/NBMA driver gets the request
+   from the IPv6 network layer to send the packet, it follows the steps
+   described in 4.4.2.  The node determines that the packet is being
+   sent to a multicast address so forwards it to the node's MARS client
+   for sending on the appropriate VC.
+
+   The Group Membership Report packets will arrive at every node which
+   is a member of the group being reported through one of the VC
+   attached to each node's MARS client.  The MARS client will de-
+   encapsulate the incoming packet and the packet will be passed to the
+   IPv6 network layer for processing.  The MARS client of the sending
+   node will filter out the packet when it receives it.
+
+   An IPv6 host sends a Group Membership Reduction message when the host
+   leaves an IPv6 multicast group.  The Group Membership Reduction is
+   sent to the multicast group the IPv6 host is leaving.  The
+   transmission and receipt of Group Membership Reduction messages are
+   handled in the same manner as Group Membership Reports.
+
+
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 37]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+Appendix B. Alternative models of MARS support for Intra-LL ND
+
+B.1 Simplistic approach - Use MARS 'as is'.
+
+   The IPv6/NBMA driver utilizes the standard MARS protocol to establish
+   a VC forwarding path out of the interface on which it can transmit
+   all multicast IPv6 packets, including ICMPv6 packets. The IPv6
+   packets are then transmitted, and received by the intended
+   destination set, using separate pt-mpt VCs per destination group.
+
+   In this approach all the protocol elements in [5] are used 'as is'.
+   However, SVC resource consumption must be taken into consideration.
+   Unfortunately, ND assumes that link level multicast resources are
+   best conserved by generating a sparsely distributed set of Solicited
+   Node multicast addresses (to which discovery queries are initially
+   sent).  The original goal was to minimize the number of innocent
+   nodes that simultaneously received discovery messages really intended
+   for someone else.
+
+   However, in connection oriented NBMA environments it becomes equally
+   (or more) important to minimize the number of independent VCs that a
+   given NBMA interface is required to originate or terminate. If we
+   treat the MARS service as a 'black box' the sparse Solicited Node
+   address space can lead to a large number of short-use, but longer
+   lived, pt-mpt VCs (generated whenever the node is transmitting
+   Neighbor Solicitations). Even more annoying, these VCs are only
+   useful for additional packets being sent to their associated
+   Solicited Node multicast address.  A new pt-pt VC is required to
+   actually carry the unicast IPv6 traffic that prompted the Neighbor
+   Solicitation.
+
+   The axis of inefficiency brought about by the sparse Solicited Nodes
+   address space is orthogonal to the VC mesh vs Multicast Server
+   tradeoff. Typically a multicast server aggregates traffic flow to a
+   common multicast group onto a single VC. To reduce the VC consumption
+   for ND, we need to aggregate across the Solicited Node address space
+   - performing aggregation on the basis of a packet's function rather
+   than its explicit IPv6 destination.  The trade-off here is that the
+   aggregation removes the original value of scattering nodes sparsely
+   across the Solicited Nodes space. This is a price of the mismatch
+   between ND and connection oriented networks.
+
+B.2 MARS as a Link (Multicast) Server.
+
+   One possible aggregation mechanism is for every node's IPv6/NBMA
+   driver to trap multicast ICMPv6 packets carrying multicast ND or RD
+   messages, and logically remap their destinations to the All Nodes
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 38]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   group (link local scope). By ensuring that the All Nodes group is
+   supported by an MCS, the resultant VC load within the LL will be
+   significantly reduced.
+
+   A further optimization is for every node's IPv6/NBMA driver to trap
+   multicast ICMPv6 packets carrying multicast ND or RD messages, and
+   send them to the MARS itself for retransmission on ClusterControlVC
+   (involving a trivial extension to the MARS itself.) This approach
+   recognizes that in any LL where IPv6 multicasting is supported:
+
+      - Nodes already have a pt-pt VC to their MARS.
+
+      - The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster
+        members (LL members registered for multicast support).
+
+   Because the VCs between a MARS and its MARS clients carry LLC/SNAP
+   encapsulated packets, ICMP packets can be multiplexed along with
+   normal MARS control messages. In essence the MARS behaves as a
+   multicast server for non-MARS packets that it receives from around
+   the LL.
+
+   As there is no requirement that a MARS client accepts only MARS
+   control messages on ClusterControlVC, ICMP packets received in this
+   fashion may be passed to every node's IP layer without further
+   comment.  Within the IP layer, filtering will occur based on the
+   packet's actual destination IP address, and only the targeted node
+   will end up responding.
+
+   Regrettably this approach does result in the entire Cluster's
+   membership having to receive a variety of ICMPv6 messages that they
+   will always throw away.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 39]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+Appendix C. Flow detection
+
+   The relationship between IPv6 packet flows, Quality of Service
+   guarantees, and optimal use of underlying IP and NBMA network
+   resources are still subjects of ongoing research in the IETF
+   (specifically the ISSLL, RSVP, IPNG, and ION working groups). This
+   document currently only describes the use of flow detection as a
+   means to optimize the use of NBMA network resources through the
+   establishment of inter-LL shortcuts.
+
+C.1. The use of non-zero FlowID to suppress flow detection
+
+   For the purposes of this IPv6/NBMA architecture, a flow is:
+
+      A related sequence of IPv6 packets that the first hop router is
+      allowed to perform flow-detection on for the purposes of
+      triggering shortcut discovery.
+
+   How these packets are considered to be related to each other (e.g.
+   through common header fields such as IPv6 destination addresses) is a
+   local configuration issue.
+
+   The flow-detection rule specifies that only packets with a zero
+   FlowID can be considered as flows for which shortcut discovery may be
+   triggered. The rationale behind this decision is:
+
+      NBMA shortcuts are for the benefit of 'the network' optimizing its
+      forwarding of IPv6 packets in the absence of any other guidance
+      from the host.
+
+      It is desirable for an IPv6/NBMA host to have some mechanism for
+      overriding attempts by 'the network' to optimize its internal
+      forwarding path.
+
+      A zero FlowID has IPv6 semantics of "the source allows the network
+      to utilize its own discretion in providing best-effort forwarding
+      service for packets with zero FlowID"
+
+      The IPv6 semantics of zero FlowID are consistent with the flow-
+      detection rule in this document of "if the FlowID is zero, we are
+      free to optimize the forwarding path using shortcuts"
+
+      A non-zero FlowID has IPv6 semantics of "the source has previously
+      established some preferred, end to end hop by hop forwarding
+      behaviour for packets with this FlowID"
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 40]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+      The IPv6 semantics of non-zero FlowID are consistent with the
+      flow-detection rule in this document of "if the FlowID is non-
+      zero, do not attempt to impose a shortcut".
+
+   A non-zero FlowID might be assigned by the source host after
+   negotiating a preferred forwarding mechanism with 'the network' (e.g.
+   through dynamic means such as RSVP, or administrative means).
+   Alternatively it can simply be assigned randomly by the source host,
+   and the network will provide default best effort forwarding (an IPv6
+   router defaults to providing best-effort forwarding for packets whose
+   FlowID/source-address pair is not recognized).
+
+   Thus, the modes of operation supported by this document becomes:
+
+      Zero FlowID
+        Best effort forwarding, with optional shortcut discovery
+        triggered through flow-detection.
+
+      Non-zero FlowID
+        Best effort forwarding if the routers along the path have not
+        been otherwise configured with alternative processing rules for
+        this FlowID/source-address pair. Flow detection relating to
+        shortcut discovery is suspended.
+
+        If the routers along the path have been configured with
+        particular processing rules for this FlowID/source-address pair,
+        the flow is handled according to those rules. Flow detection
+        relating to shortcut discovery is suspended.
+
+   Mechanisms for establishing particular per-hop processing rules for
+   packets with non-zero FlowID are neither constrained by, nor implied
+   by, this document.
+
+C.2. Future directions for Flow Detection
+
+   In the future, accurate mapping of IPv6 flows onto NBMA VCs may
+   require more information to be exchanged during the Neighbor
+   Discovery process than is currently available in Neighbor Discovery
+   packets. In these cases, the IPv6 Neighbor Discover protocols can be
+   extended to include new TLV options (see section 4.6 of RFC 1970
+   [7]). However, if new options are required, the specification of
+   these options must be co-ordinated with the IPNG working group.
+   Since RFC 1970 specifies that nodes must silently ignore options they
+   do not understand, new options can be added at any time without
+   breaking backward compatibility with existing implementations.
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 41]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+   NHRP also provides mechanisms for adding optional TLVs to NHRP
+   Requests and NHRP Replies. Future developments of this document's
+   architecture will require consistent QoS extensions to both ND and
+   NHRP in order to ensure they are semantically equivalent (syntactic
+   differences are undesirable, but can be tolerated).
+
+   Support for QoS on IPv6 unicast flows will not require further
+   extensions to the existing MARS protocol. However, future support for
+   QoS on IPv6 multicast flows may require extensions. MARS control
+   messages share the same TLV extension mechanism as NHRP, allowing QoS
+   extensions to be developed as needed.
+
+Appendix D. Shortcut Limit Option
+
+   For NS messages sent as a shortcut trigger, a new type of ND option
+   is needed to pass on the information about the data flow hop limit
+   from the host to the router. The use of this ND option is defined in
+   section 3.2.2 of this specification. Its binary representation
+   follows the rules of section 4.6 of RFC 1970:
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        |     Type      |    Length     | Shortcut Limit|   Reserved1   |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        |                           Reserved2                           |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+
+         Type            6
+
+         Length          1
+
+         Shortcut Limit  8-bit unsigned integer. Hop limit for shortcut
+                         attempt.
+
+         Reserved1       This field is unused. It MUST be initialized to
+                         zero by the sender and MUST be ignored by the
+                         receiver.
+
+         Reserved2       This field is unused. It MUST be initialized to
+                         zero by the sender and MUST be ignored by the
+                         receiver.
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 42]
+
+RFC 2491                IPv6 over NBMA networks             January 1999
+
+
+      Description
+
+         The shortcut limit option is used by a host in a Neighbor
+         Solicitation message sent as a shortcut trigger to a default
+         router. It restricts the router's shortcut query to targets
+         reachable via the specified number of hops. The shortcut limit is
+         given relative to the host requesting the shortcut. NS messages
+         with shortcut limit values of 0 or 1 MUST be silently ignored.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 43]
+
+RFC 2491                IPv6 over NBMA networks             January 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Armitage, et. al.           Standards Track                    [Page 44]
+