home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2491.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  100.8 KB  |  2,468 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Armitage
  8. Request for Comments: 2491                          Lucent Technologies
  9. Category: Standards Track                                   P. Schulter
  10.                                               Bright Tiger Technologies
  11.                                                                 M. Jork
  12.                                                  Digital Equipment GmbH
  13.                                                               G. Harter
  14.                                                                  Compaq
  15.                                                            January 1999
  16.  
  17.  
  18.         IPv6 over Non-Broadcast Multiple Access (NBMA) networks
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28. Copyright Notice
  29.  
  30.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  31.  
  32. Abstract
  33.  
  34.    This document describes a general architecture for IPv6 over NBMA
  35.    networks. It forms the basis for subsidiary companion documents that
  36.    describe details for various specific NBMA technologies (such as ATM
  37.    or Frame Relay). The IPv6 over NBMA architecture allows conventional
  38.    host-side operation of the IPv6 Neighbor Discovery protocol, while
  39.    also supporting the establishment of 'shortcut' NBMA forwarding paths
  40.    when dynamically signaled NBMA links are available. Operations over
  41.    administratively configured Point to Point NBMA links are also
  42.    described.
  43.  
  44.    Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor
  45.    Discovery protocol operation within Logical Links, and inter-router
  46.    NHRP for the discovery of off-Link NBMA destinations. Both flow-
  47.    triggered and explicitly source-triggered shortcuts are supported.
  48.  
  49. 1. Introduction.
  50.  
  51.    Non Broadcast Multiple Access (NBMA) networks may be utilized in a
  52.    variety of ways. At one extreme, they can be used to simply provide
  53.    administratively configurable point to point service, sufficient to
  54.    interconnect IPv6 routers (and even IPv6 hosts, in certain
  55.  
  56.  
  57.  
  58. Armitage, et. al.           Standards Track                     [Page 1]
  59.  
  60. RFC 2491                IPv6 over NBMA networks             January 1999
  61.  
  62.  
  63.    situations). At the other extreme, NBMA networks that support dynamic
  64.    establishment and teardown of Virtual Circuits (or functional
  65.    equivalents) may be used to emulate the service provided to the IPv6
  66.    layer by conventional broadcast media such as Ethernet.  Typically
  67.    this emulation requires complex convergence protocols, particularly
  68.    to support IPv6 multicast.
  69.  
  70.    This document describes a general architecture for IPv6 over NBMA
  71.    networks. It forms the basis for companion documents that provide
  72.    details specific to various NBMA technologies (for example, ATM [17]
  73.    or Frame Relay). The IPv6 over NBMA architecture allows conventional
  74.    host-side operation of the IPv6 Neighbor Discovery protocol, while
  75.    also supporting the establishment of 'shortcut' NBMA forwarding paths
  76.    (when dynamically signaled NBMA links are available).
  77.  
  78.    The majority of this document focuses on the use of dynamically
  79.    managed point to point and point to multipoint calls between
  80.    interfaces on an NBMA network. These will be generically referred to
  81.    as "SVCs" in the rest of the document. The use of administratively
  82.    configured point to point calls will also be discussed. Such calls
  83.    will be generically referred to as "PVCs". Depending on context,
  84.    either may be shortened to "VC".
  85.  
  86.    Certain NBMA networks may provide a form of connectionless service
  87.    (e.g. SMDS). In these cases, a "call" or "VC" shall be considered to
  88.    implicitly exist if the sender has an NBMA destination address to
  89.    which it can transmit packets whenever it desires.
  90.  
  91. 1.1 Neighbor Discovery.
  92.  
  93.    A key difference between this architecture and previous IP over NBMA
  94.    protocols is its mechanism for supporting IPv6 Neighbor Discovery.
  95.  
  96.    The IPv4 world evolved an approach to address resolution that
  97.    depended on the operation of an auxiliary protocol operating at the
  98.    'link layer' - starting with Ethernet ARP (RFC 826 [14]). In the
  99.    world of NBMA (Non Broadcast, Multiple Access) networks ARP has been
  100.    applied to IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC 1577
  101.    [3]). More recently the ION working group has developed NHRP (Next
  102.    Hop Resolution Protocol [8]), a general protocol for performing
  103.    intra-subnet and inter-subnet address resolution applicable to a
  104.    range of NBMA network technologies.
  105.  
  106.    IPv6 developers opted to migrate away from a link layer specific
  107.    approach, chosing to combine a number of tasks into a protocol known
  108.    as Neighbor Discovery [7], intended to be non-specific across a
  109.    number of link layer technologies.  A key assumption made by Neighbor
  110.    Discovery's actual protocol is that the link technology underlying a
  111.  
  112.  
  113.  
  114. Armitage, et. al.           Standards Track                     [Page 2]
  115.  
  116. RFC 2491                IPv6 over NBMA networks             January 1999
  117.  
  118.  
  119.    given IP interface is capable of native multicasting.  This is not
  120.    particularly true of most NBMA network services, and usually requires
  121.    convergence protocols to emulate the desired service.  (The MARS
  122.    protocol, RFC 2022 [5], is an example of such a convergence
  123.    protocol.) This document augments and optimizes the MARS protocol for
  124.    use in support of IPv6 Neighbor Discovery, generalizing the
  125.    applicability of RFC 2022 beyond ATM networks.
  126.  
  127. 1.2 NBMA Shortcuts.
  128.  
  129.    A shortcut is an NBMA level call (VC) directly connecting two IP
  130.    endpoints that are logically separated by one or more routers at the
  131.    IP level. IPv6 packets traversing this VC are said to 'shortcut' the
  132.    routers that are in the logical IPv6 path between the VC's endpoints.
  133.  
  134.    NBMA shortcuts are a mechanism for minimizing the consumption of
  135.    resources within an IP over NBMA cloud (e.g. router hops and NBMA
  136.    VCs).
  137.  
  138.    It is important that NBMA shortcuts are supported whenever IP is
  139.    deployed across NBMA networks capable of supporting dynamic
  140.    establishment of calls (SVCs or functional equivalent).  For IPv6
  141.    over NBMA, shortcut discovery and management is achieved through a
  142.    mixture of Neighbor Discovery and NHRP.
  143.  
  144. 1.3 Key components of the IPv6 over NBMA architecture.
  145.  
  146. 1.3.1 NBMA networks providing PVC support.
  147.  
  148.    When the NBMA network is used in PVC mode, each PVC will connect
  149.    exactly two nodes and the use of Neighbor Discovery and other IPv6
  150.    features is limited.  IPv6/NBMA interfaces have only one neighbor on
  151.    each Link. The MARS and NHRP protocols are NOT necessary, since
  152.    multicast and broadcast operations collapse down to an NBMA level
  153.    unicast operation. Dynamically discovered shortcuts are not
  154.    supported.
  155.  
  156.    The actual details of encapsulations and link token generation SHALL
  157.    be covered by companion documents covering specific NBMA technology.
  158.    They SHALL conform to the following guidelines:
  159.  
  160.       Both unicast and multicast IPv6 packets SHALL be transmitted over
  161.       PVC links using the encapsulation described in section 4.4.1.
  162.  
  163.       Interface tokens for PVC links SHALL be constructed as described
  164.       in section 5. Interface tokens need only be unique between the two
  165.       nodes on the PVC link.
  166.  
  167.  
  168.  
  169.  
  170. Armitage, et. al.           Standards Track                     [Page 3]
  171.  
  172. RFC 2491                IPv6 over NBMA networks             January 1999
  173.  
  174.  
  175.       This use of PVC links does not mandate, nor does it prohibit the
  176.       use of extensions to the Neighbor Discovery protocol which may be
  177.       developed for either general use of for use in PVC connections
  178.       (for example, Inverse Neighbor Discovery).
  179.  
  180.    NBMA-specific companion documents MAY additionally specify the
  181.    concatenation of IPv6 over PPP and PPP over NBMA mechanisms as an
  182.    OPTIONAL approach to point to point IPv6.
  183.  
  184.    Except where noted above, the remainder of this document focuses on
  185.    the SVC case.
  186.  
  187. 1.3.2 NBMA networks providing SVC support.
  188.  
  189.    When the NBMA network is used in SVC mode, the key components are:
  190.  
  191.       - The IPv6 Neighbor model, where neighbors are discovered through
  192.         the use of messages multicast to members of an IPv6 interface's
  193.         local IPv6 Link.
  194.       - The MARS model, allowing emulation of general multicast using
  195.         multipoint calls provided by the underlying NBMA network.
  196.       - The NHRP service for seeking out the NBMA identities of IP
  197.         interfaces who are logically distant in an IP topological sense.
  198.       - The modeling of IP traffic as 'flows', and optionally using the
  199.         existence of a flow as the basis for attempting to set up a
  200.         shortcut link level connection.
  201.  
  202.    In summary:
  203.  
  204.       The IPv6 "Link" is generalized to "Logical Link" (LL) in NBMA
  205.       environments (analogous to the generalization of IPv4 IP Subnet to
  206.       Logical IP Subnet in RFC 1209 and subsequently RFC 1577).
  207.  
  208.       IPv6/NBMA interfaces utilize RFC 2022 (MARS) for general intra-
  209.       Logical Link multicasting. The MARS itself is used to optimally
  210.       distribute discovery messages within the Logical Link.
  211.  
  212.       For destinations not currently considered to be Neighbors, a host
  213.       sends the packets to one of its default routers.
  214.  
  215.       When appropriately configured, the egress router from a Logical
  216.       Link is responsible for detecting the existence of an IP packet
  217.       flow through it that might benefit from a shortcut connection.
  218.  
  219.          While continuing to conventionally forward the flow's packets,
  220.          the router initiates an NHRP query for the flow's destination
  221.          IP address.
  222.  
  223.  
  224.  
  225.  
  226. Armitage, et. al.           Standards Track                     [Page 4]
  227.  
  228. RFC 2491                IPv6 over NBMA networks             January 1999
  229.  
  230.  
  231.          The last router/NHS before the target of the NHRP query
  232.          ascertains the target interface's preferred NBMA address.
  233.  
  234.          The originally querying router then issues a Redirect to the IP
  235.          source, identifying the flow's destination as a transient
  236.          Neighbor.
  237.  
  238.       Host-initiated triggering of shortcut discovery, regardless of the
  239.       existence of a packet flow, is also supported through specific
  240.       Neighbor Solicitations sent to a source host's default router.
  241.  
  242.    A number of key advantages are claimed for this approach. These are:
  243.  
  244.       The IPv6 stacks on hosts do not implement separate ND protocols
  245.       for each link layer technology.
  246.  
  247.       When the destination of a flow is solicited as a transient
  248.       neighbor, the returned NBMA address will be the one chosen by the
  249.       destination when the flow was originally established through hop-
  250.       by-hop processing. This supports the existing ND ability for IPv6
  251.       destinations to perform their own dynamic interface load sharing.
  252.  
  253. 1.4 Terminology.
  254.  
  255.    The bit-pattern or numeric value used to identify a particular NBMA
  256.    interface at the NBMA level will be referred to as an "NBMA address".
  257.    (An example would be an ATM End System Address, AESA, when applying
  258.    this architecture to ATM networks, or an E.164 number when applying
  259.    this architecture to SMDS networks.)
  260.  
  261.    The call that, once established, is used to transfer IP packets from
  262.    one NBMA interface to another will be referred to as an SVC or PVC
  263.    depending on whether the call is dynamically established through some
  264.    signaling mechanism, or administratively established. The specific
  265.    signaling mechanisms used to establish or tear down an SVC will be
  266.    defined in the NBMA-specific companion specifications.  Certain NBMA
  267.    networks may provide a form of connectionless service (e.g. SMDS). In
  268.    these cases, a "call" or "SVC" shall be considered to implicitly
  269.    exist if the sender has an NBMA destination address to which it can
  270.    transmit packets whenever it desires.
  271.  
  272.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  273.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  274.    document are to be interpreted as described in RFC 2119 [16].
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Armitage, et. al.           Standards Track                     [Page 5]
  283.  
  284. RFC 2491                IPv6 over NBMA networks             January 1999
  285.  
  286.  
  287. 1.5 Document Structure.
  288.  
  289.    The remainder of this document is structured as follows: Section 2
  290.    explains the generalization of IPv6 Link to "Logical Link" when used
  291.    over NBMA networks, and introduces the notion of the Transient
  292.    Neighbor.  Section 3 describes the modifications to the MARS protocol
  293.    for efficient distribution of ND messages within a Logical Link, and
  294.    the rules and mechanisms for discovering Transient Neighbors.
  295.    Section 4 covers the basic rules governing IPv6/NBMA interface
  296.    initialization, packet and control message encapsulations, and rules
  297.    for SVC management. Section 5 describes the general rules for
  298.    constructing Interface Tokens, the Link Layer Address Option, and
  299.    Link Local addresses.  Section 6 concludes the normative sections of
  300.    the document.  Appendix A provides some non-normative descriptive
  301.    text regarding the operation of Ipv6 Neighbor Discovery.  Appendix B
  302.    describes some sub-optimal solutions for emulating the multicasting
  303.    of Neighbor Discovery messages around a Logical Link.  Appendix C
  304.    discusses shortcut suppression and briefly reviews the future
  305.    relationships between flow detection and mapping of flows onto SVCs
  306.    of differing qualities of service.
  307.  
  308. 2. Logical Links, and Transient Neighbors.
  309.  
  310.  
  311.    IPv6 contains a concept of on-link and off-link. Neighbors are those
  312.    nodes that are considered on-link and whose link-layer addresses may
  313.    therefore be located using Neighbor Discovery.  Borrowing from the
  314.    terminology definitions in the ND text:
  315.  
  316.    on-link   - an address that is assigned to a neighbor's interface on
  317.                a shared link.  A host considers an address to be on-
  318.                link if:
  319.                  - it is covered by one of the link's prefixes, or
  320.                  - a neighboring router specifies the address as the
  321.                    target of a Redirect message, or
  322.                  - a Neighbor Advertisement message is received for the
  323.                    target address, or
  324.                  - a Neighbor Discovery message is received from the
  325.                    address.
  326.  
  327.    off-link  - the opposite of "on-link"; an address that is not
  328.                assigned to any interfaces attached to a shared link.
  329.  
  330.    Off-link nodes are considered to only be accessible through one of
  331.    the routers directly attached to the link.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Armitage, et. al.           Standards Track                     [Page 6]
  339.  
  340. RFC 2491                IPv6 over NBMA networks             January 1999
  341.  
  342.  
  343.    The NBMA environment complicates the sense of the word 'link' in much
  344.    the same way as it complicated the sense of 'subnet' in the IPv4
  345.    case. For IPv4 this required the definition of the Logical IP Subnet
  346.    (LIS) - an administratively constructed set of hosts that would share
  347.    the same routing prefixes (network and subnetwork masks).
  348.  
  349.    This document considers the IPv6 analog to be a Logical Link (LL).
  350.  
  351.       An LL consists of nodes administratively configured to be 'on
  352.       link' with respect to each other.
  353.  
  354.       The members of an LL are an IPv6 interface's initial set of
  355.       neighbors, and each interface's Link Local address only needs to
  356.       be unique amongst this set.
  357.  
  358.    It should be noted that whilst members of an LL are IPv6 Neighbors,
  359.    it is possible for Neighbors to exist that are not, administratively,
  360.    members of the same LL.
  361.  
  362.    Neighbor Discovery events can result in the expansion of an IPv6
  363.    interface's set of Neighbors. However, this does not change the set
  364.    of interfaces that make up its LL. This leads to three possible
  365.    relationships between any two IPv6 interfaces:
  366.  
  367.       - On LL, Neighbor.
  368.       - Off LL, Neighbor.
  369.       - Off LL, not Neighbor.
  370.  
  371.    Off LL Neighbors represent the 'shortcut' connections, where it has
  372.    been ascertained that direct connectivity at the NBMA level is
  373.    possible to a target that is not a member of the source's LL.
  374.  
  375.    Neighbors discovered through the operation of unsolicited messages,
  376.    such as Redirects, are termed 'Transient Neighbors'.
  377.  
  378. 3. Intra-LL and Inter-LL Discovery.
  379.  
  380.    This document makes a distinction between the discovery of neighbors
  381.    within a Logical Link (intra-LL) and neighbors beyond the LL (inter-
  382.    LL). The goal is to allow both inter- and intra-LL neighbor discovery
  383.    to involve no changes to the host-side IPv6 stack for NBMA
  384.    interfaces.
  385.  
  386.    Note that section 1.3.1 applies when the NBMA network is being used
  387.    to provide only configured point to point (PVC) service.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Armitage, et. al.           Standards Track                     [Page 7]
  395.  
  396. RFC 2491                IPv6 over NBMA networks             January 1999
  397.  
  398.  
  399. 3.1 Intra-LL - ND over emulated multicast.
  400.  
  401.    The basic model of ND assumes that a link layer interface will do
  402.    something meaningful with an ICMPv6 packet sent to a multicast IP
  403.    destination address. (IPv6 assumes that multicasting is an integral
  404.    part of the Internet service.) This document assumes multicast
  405.    support will be provided using the RFC 2022 (MARS) [5] service
  406.    (generalized for use over other NBMA technologies in addition to
  407.    ATM).  An IPv6 LL maps directly onto an IPv6 MARS Cluster in the same
  408.    way an IPv4 LIS maps directly onto an IPv4 MARS Cluster.
  409.  
  410.    The goal of intra-LL operation is that the IPv6 layer must be able to
  411.    simply pass multicast ICMPv6 packets down to the IPv6/NBMA driver
  412.    without any special, NBMA specific processing. The underlying
  413.    mechanism for distributing Neighbor Discovery and Router Discovery
  414.    messages then works as expected.
  415.  
  416.    Sections 3.1.1 describes the additional functionality that SHALL be
  417.    required of any MARS used in conformance with this document.
  418.    Background discussion of these additions is provided in Appendix B.
  419.  
  420. 3.1.1 Mandatory augmented MARS and MARS Client behavior.
  421.  
  422.    IPv6/NBMA interfaces SHALL register as MARS Cluster members as
  423.    described in section 4.1, and SHALL send certain classes of outgoing
  424.    IPv6 packets directly to their local MARS as described in section
  425.    4.4.2.
  426.  
  427.    The MARS itself SHALL then re-transmit these packets according to the
  428.    following rules:
  429.  
  430.       - When the MARS receives an IPv6 packet, it scans the group
  431.         membership database to find the NBMA addresses of the IPv6
  432.         destination group's members.
  433.  
  434.       - The MARS then checks to see if every group member currently has
  435.         its pt-pt control VC open to the MARS. If so, the MARS sends a
  436.         copy of the data packet directly to each group member over the
  437.         existing pt-pt VCs.
  438.  
  439.       - If one or more of the discovered group members do not have an
  440.         open pt-pt VC to the MARS, or if there are no group members
  441.         listed, the packet is sent out ClusterControlVC instead. No
  442.         copies of the packet are sent over the existing (if any) pt-pt
  443.         VCs.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Armitage, et. al.           Standards Track                     [Page 8]
  451.  
  452. RFC 2491                IPv6 over NBMA networks             January 1999
  453.  
  454.  
  455. 3.2 Inter-LL - Redirects, and their generation.
  456.  
  457.    Shortcut connections are justified on the grounds that demanding
  458.    flows of IP packets may exist between source/destination pairs that
  459.    are separated by IP routing boundaries. Shortcuts are created between
  460.    Transient Neighbors.
  461.  
  462.    The key to creating transient neighbors is the Redirect message
  463.    (section 8 [7]).  IPv6 allows a router to inform the members of an LL
  464.    that there is a better 'first hop' to a given destination (section
  465.    8.2 [7]).  The advertisement itself is achieved through a Router
  466.    Redirect message, which may carry the link layer address of this
  467.    better hop.
  468.  
  469.    A transmitting host only listens to Router Redirects from the router
  470.    that is currently acting as the default router for the IP destination
  471.    that the Redirect refers to. If a Redirect arrives that indicates a
  472.    better first hop for a given destination, and supplies a link layer
  473.    (NBMA) address to use as the better first hop, the associated
  474.    Neighbor Cache entry in the source host is updated and its
  475.    reachability set to STALE. Updating the cache in this context
  476.    involves building a new VC to the new NBMA address. If this is
  477.    successful, the old VC is torn down only if it no longer required
  478.    (since the old VC was to the router, it may still be required by
  479.    other packets from the host that are heading to the router).
  480.  
  481.    Two mechanisms are provided for triggering the discovery of a better
  482.    first hop:
  483.  
  484.       Router-based flow identification/detection.
  485.  
  486.       Host-initiated shortcut request.
  487.  
  488.    Section 3.2.1 discusses flow-based triggers, section 3.2.2 discusses
  489.    the host initiated trigger, and section 3.2.3 discusses the use of
  490.    NHRP to discover mappings for IPv6 targets in remote LLs.
  491.  
  492. 3.2.1 Flow Triggered Redirection.
  493.  
  494.    The modification of forwarding paths based on the dynamic detection
  495.    of IP packet flows is at the core of models such as the Cell Switch
  496.    Router [11] and the IP Switch [12]. Responsibility for detecting
  497.    flows is placed into the routers, where packets cross the edges of IP
  498.    routing boundaries.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Armitage, et. al.           Standards Track                     [Page 9]
  507.  
  508. RFC 2491                IPv6 over NBMA networks             January 1999
  509.  
  510.  
  511.    For the purpose of conformance with this document, a router MAY
  512.    choose to initiate the discovery of a better first-hop when it
  513.    determines that an identifiable flow of IP packets are passing
  514.    through it.
  515.  
  516.       Such a router:
  517.  
  518.          SHALL only track flows that originate from a directly attached
  519.          host (a host that is within the LL-local scope of one of the
  520.          router's interfaces).
  521.  
  522.          SHALL NOT use IP packets arriving from another router to
  523.          trigger the generation of a Router Redirect.
  524.  
  525.          SHALL only consider IPv6 packets with FlowID of zero for the
  526.          purposes of flow detection as defined in this section.
  527.  
  528.          SHALL utilize NHRP as described in section 3.2.3 to ascertain a
  529.          better first-hop when a suitable flow is detected, and
  530.          advertise the information in a Router Redirect.
  531.  
  532.    IPv6 routers that support the OPTIONAL flow detection behavior
  533.    described above SHALL support administrative mechanisms to switch off
  534.    flow-detection. They MAY provide mechanisms for adding additional
  535.    constraints to the categories of IPv6 packets that constitute a
  536.    'flow'.
  537.  
  538.    The actual algorithm(s) for determining what sequence of IPv6 packets
  539.    constitute a 'flow' are outside the scope of this document.  Appendix
  540.    C discusses the rationale behind the use of non-zero FlowID to
  541.    suppress flow detection.
  542.  
  543. 3.2.2 Host Triggered Redirection
  544.  
  545.    A source host MAY also trigger a redirection to a transient neighbor.
  546.    To support host-triggered redirects, routers conforming to this
  547.    document SHALL recognize specific Neighbor Solicitation messages sent
  548.    by hosts as requests for the resolution of off-link addresses.
  549.  
  550.    To perform a host-triggered redirect, a source host SHALL:
  551.  
  552.       Create a Neighbor Solicitation message referring to the off-LL
  553.       destination (target) for which a shortcut is desired
  554.  
  555.       Address the NS message to the router that would be the next hop
  556.       for traffic sent towards the off-LL target (rather than the
  557.       target's solicited node multicast address).
  558.  
  559.  
  560.  
  561.  
  562. Armitage, et. al.           Standards Track                    [Page 10]
  563.  
  564. RFC 2491                IPv6 over NBMA networks             January 1999
  565.  
  566.  
  567.       Use the standard ND hop limit of 255 to ensure the NS won't be
  568.       discarded by the router.
  569.  
  570.       Include the shortcut limit option defined in appendix D. The value
  571.       of this option should be equal to the hop limit of the data flow
  572.       for which this trigger is being sent. This ensures that the router
  573.       is able to restrict the shortcut attempt to not exceed the reach
  574.       of the data flow.
  575.  
  576.       Forward the NS packet to the router that would be the next hop for
  577.       traffic sent towards the off-LL target.
  578.  
  579.    Routers SHALL consider a unicast NS with shortcut limit option as a
  580.    request for a host-triggered redirect. However, actual shortcut
  581.    discovery is OPTIONAL for IPv6 routers.
  582.  
  583.    When shortcut discovery is not supported, the router SHALL construct
  584.    a Redirect message identifying the router itself as the best
  585.    'shortcut', and return it to the soliciting host.
  586.  
  587.    If shortcut discovery is to be supported, the router's response SHALL
  588.    be:
  589.  
  590.       A suitable NHRP Request is constructed and sent as described in
  591.       section 3.2.3.  The original NS message SHOULD be discarded.
  592.  
  593.       Once the NHRP Reply is received by the originating router, the
  594.       router SHALL construct a Redirect message containing the IPv6
  595.       address of the transient neighbor, and the NBMA link layer address
  596.       returned by the NHRP resolution process.
  597.  
  598.       The resulting Redirect message SHALL then be transmitted back to
  599.       the source host. When the Redirect message is received, the source
  600.       host SHALL update its Neighbor and Destination caches.
  601.  
  602.       The off-LL target is now considered a Transient Neighbor.  The
  603.       next packet sent to the Transient Neighbor will result in the
  604.       creation of the direct, shortcut VC (to the off-LL target itself,
  605.       or to the best egress router towards that neighbor as determined
  606.       by NHRP).
  607.  
  608.       If a NHRP NAK or error indication is received for a host-triggered
  609.       shortcut attempt, the requesting router SHALL construct a Redirect
  610.       message identifying the router itself as the best 'shortcut', and
  611.       return it to the soliciting host.
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Armitage, et. al.           Standards Track                    [Page 11]
  619.  
  620. RFC 2491                IPv6 over NBMA networks             January 1999
  621.  
  622.  
  623. 3.2.3 Use of NHRP between routers.
  624.  
  625.    Once flow detection has occurred, or a host trigger has been
  626.    detected, routers SHALL use NHRP in an NHS to NHS mode to establish
  627.    the IPv6 to link level address mapping of a better first hop.
  628.  
  629.    IPv6/NBMA routers supporting shortcut discovery will need to perform
  630.    some or all of the following functions:
  631.  
  632.       - Construct NHRP Requests and Replies.
  633.  
  634.    - Parse incoming NHRP Requests and Replies from other NHSes
  635.         (routers).
  636.  
  637.       - Forward NHRP Requests towards an NHS that is topologically
  638.         closer to the IPv6 target.
  639.  
  640.       - Forward NHRP Replies towards an NHS that is topologically closer
  641.         to the requester.
  642.  
  643.       - Perform syntax translation between Neighbor Solicitations and
  644.         outbound NHRP Requests.
  645.  
  646.       - Perform syntax translation between inbound NHRP Replies and
  647.         Redirects.
  648.  
  649.    The destination of the flow that caused the trigger (or the target of
  650.    the host initiated trigger) is used as the target for resolution in a
  651.    NHRP Request. The router then forwards this NHRP Request to the next
  652.    closest NHS. The process continues (as it would for normal NHRP)
  653.    until the Request reaches an NHS that believes the IP target is
  654.    within link-local scope of one of its interfaces.  (This may
  655.    potentially occur within a single router.)
  656.  
  657.    As NHRP resolution requests always follow the routed path for a given
  658.    target protocol address, the scope of a shortcut request will be
  659.    automatically bounded to the scope of the IPv6 target address.  (e.g.
  660.    resolution requests for site-local addresses will not be forwarded
  661.    across site boundaries.)
  662.  
  663.    The last hop router SHALL resolve the NHRP Request from mapping
  664.    information contained in its neighbor cache for the interface on
  665.    which the specified target is reachable. If there is no appropriate
  666.    entry in the Neighbor cache, or the destination is currently
  667.    considered unreachable, the last hop router SHALL perform Neighbor
  668.    Discovery on the local interface, and build the NHRP Reply from the
  669.    resulting answer. (Note, in the case where the NHRP Request
  670.    originated due to flow detection, there must already be a hop-by-hop
  671.  
  672.  
  673.  
  674. Armitage, et. al.           Standards Track                    [Page 12]
  675.  
  676. RFC 2491                IPv6 over NBMA networks             January 1999
  677.  
  678.  
  679.    flow of packets going through the last hop router towards the target.
  680.    In this typical case the Neighbor cache will already have the desired
  681.    information.)
  682.  
  683.    The NHRP Reply is propagated back to the source of the NHRP Request,
  684.    using a hop-by-hop path as it would for normal NHRP.
  685.  
  686.    If the discovery process was triggered through flow detection at the
  687.    originating router, the return of the NHRP Reply results in the
  688.    following events:
  689.  
  690.       A Redirect is constructed using the IPv6/NBMA mapping carried in
  691.       the NHRP Reply.
  692.  
  693.       The Redirect is unicast to the IP packet flow's source (using the
  694.       VC on which the flow is arriving at the router, if it is a bi-
  695.       directional pt-pt VC).
  696.  
  697.       Any Redirect message sent by a router MUST conform to all the
  698.       rules described in [7] so that the packet is properly validated by
  699.       the receiving host.  Specifically, if the target of the resulting
  700.       short-cut is the destination host then the ICMP Target Address
  701.       MUST be the same as the ICMP Destination Address in the original
  702.       message.  If the target of the short-cut is an egress router then
  703.       the ICMP Target Address MUST be a Link Local address of the egress
  704.       router that is unique to the NBMA cloud to which the router's NBMA
  705.       interface is attached.
  706.  
  707.       Also note that egress routers may subsequently redirect the source
  708.       host. To do so, the Link Local ICMP Source Address of the Redirect
  709.       message MUST be the same as the Link Local ICMP Target Address of
  710.       the original Redirect message.
  711.  
  712.    Note that the router constructing the NHRP Reply does so using the
  713.    NBMA address returned by the target host when the target host first
  714.    accepted the flow of IP traffic. This retains a useful feature of
  715.    Neighbor Discovery - destination interface load sharing.
  716.  
  717.    Upon receipt of a NHRP NAK reply or error indication for a flow-
  718.    triggered shortcut attempt, no indication is sent to the source of
  719.    the flow.
  720.  
  721. 3.2.3.1  NHRP/ND packet translation rules.
  722.  
  723.    The following translation rules are meant to augment the packet
  724.    format specification in section 5 of the NHRP specification [8],
  725.    covering those packet fields specifically utilized by the IPv6/NBMA
  726.    architecture.
  727.  
  728.  
  729.  
  730. Armitage, et. al.           Standards Track                    [Page 13]
  731.  
  732. RFC 2491                IPv6 over NBMA networks             January 1999
  733.  
  734.  
  735.    NHRP messages are constructed and sent according to the rules in [8].
  736.    The value of the NBMA technology specific fields such as ar$afn,
  737.    ar$pro.type, ar$pro.snap and link layer address format are defined in
  738.    NBMA-specific companion documents. Source, destination or client
  739.    protocol addresses in the common header or CIE of a NHRP message are
  740.    always IPv6 addresses of length 16.
  741.  
  742.    When constructing an host-triggered NHRP resolution request in
  743.    response to a Neighbor Solicitation:
  744.  
  745.       The ar$hopcnt field MUST be smaller than the shortcut limit value
  746.       specified in the shortcut limit option included in the triggering
  747.       NS message. This ensures that hosts have control over the reach of
  748.       their shortcut request. Note that the shortcut limit given in the
  749.       option is relative to the requesting host, thus the requirement of
  750.       ar$hopcnt being smaller than the given shortcut limit.
  751.  
  752.       The Flags field in the common header of the NHRP resolution
  753.       request SHOULD have the Q and S bits set.
  754.  
  755.       The U bit SHOULD be set.  NBMA and protocol source addresses are
  756.       those of the router constructing the request.
  757.  
  758.       The target address from the NS message is used as the NHRP
  759.       destination protocol address.  A CIE SHALL NOT be specified.
  760.  
  761.    When constructing a NHRP resolution request as a result of flow
  762.    detection, the choice of values is configuration dependent.
  763.  
  764.    A NHRP resolution reply is build according to the rules in [8].
  765.  
  766.       For each CIE returned, the holding time is 10 minutes.
  767.  
  768.       The MTU may be 0 or a value specified in the NBMA-specific
  769.       companion document.
  770.  
  771.    A successful NHRP resolution reply for a host-triggered shortcut
  772.    attempt is translated into an IPv6 Redirect message as follows:
  773.  
  774.    IP Fields:
  775.       Source Address
  776.             The link-local address assigned to the router's interface
  777.             from which this message is sent.
  778.       Destination Address
  779.             IPv6 Source Address of the triggering NS
  780.       Hop Limit
  781.             255
  782.  
  783.  
  784.  
  785.  
  786. Armitage, et. al.           Standards Track                    [Page 14]
  787.  
  788. RFC 2491                IPv6 over NBMA networks             January 1999
  789.  
  790.  
  791.    ICMP Fields:
  792.       Target Address
  793.             NHRP Client Protocol Address
  794.       Destination Address
  795.             Target of triggering NS (this is equivalent to the NHRP
  796.             Destination Protocol Address)
  797.       Target link-layer address
  798.             NHRP Client NBMA Address
  799.  
  800.    All NHRP extensions currently defined in [8] have no effect on
  801.    NHRP/ND translation and MAY be used in NHRP messages for IPv6.
  802.  
  803. 3.2.3.2  NHRP Purge rules.
  804.  
  805.    Purges are generated by NHRP when changes are detected that
  806.    invalidate a previously issued NHRP Reply (this may include topology
  807.    changes, or a target host going down or changing identity). Any IPv6
  808.    shortcut previously established on the basis of newly purged
  809.    information SHOULD be torn down.
  810.  
  811.    Routers SHALL keep track of NHRP cache entries for which they have
  812.    issued Neighbor Advertisements or Router Redirects. If a NHRP Purge
  813.    is received that invalidates information previously issued to local
  814.    host, the router SHALL issue a Router Redirect specifying the router
  815.    itself as the new best next-hop for the affected IPv6 target.
  816.  
  817.    Routers SHALL keep track of Neighbor cache entries that have
  818.    previously been used to generate an NHRP Reply. The expiry of any
  819.    such Neighbor cache entry SHALL result in a NHRP Purge being sent
  820.    towards the router that originally requested the NHRP Reply.
  821.  
  822. 3.3. Neighbor Unreachability Detection.
  823.  
  824.    Neighbor Solicitations sent for the purposes of Neighbor
  825.    Unreachability Detection (NUD) are unicast to the Neighbor in
  826.    question, using the VC that is already open to that Neighbor. This
  827.    suggests that as far as NUD is concerned, the Transient Neighbor is
  828.    indistinguishable from an On-LL Neighbor.
  829.  
  830. 3.4. Duplicate Address Detection.
  831.  
  832.    Duplicate Address Detection is only required within the link-local
  833.    scope, which in this case is the LL-local scope. Transient Neighbors
  834.    are outside the scope of the LL. No particular interaction is
  835.    required between the mechanism for establishing shortcuts and the
  836.    mechanism for detection of duplicate link local addresses.
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Armitage, et. al.           Standards Track                    [Page 15]
  843.  
  844. RFC 2491                IPv6 over NBMA networks             January 1999
  845.  
  846.  
  847. 4 Node Operation Concepts.
  848.  
  849.    This section describes node operations for performing basic functions
  850.    (such as sending and receiving data) on a Logical Link.  The
  851.    application of these basic functions to the operation of the various
  852.    IPv6 protocols such as Neighbor Discovery is described in Appendix A.
  853.  
  854.    The majority of this section applies only to NBMA networks when used
  855.    to provide point to point and point to multipoint SVCs.  Section 7
  856.    discusses the case where the NBMA network is being used to supply
  857.    only point to point PVCs.
  858.  
  859. 4.1.Connecting to a Logical Link.
  860.  
  861.    Before a node can send or receive IPv6 datagrams its underlying
  862.    IPv6/NBMA interface(s) must first join a Logical Link.
  863.  
  864.    An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated
  865.    with its Logical Link, and register as a Cluster Member [5].  The
  866.    node's IPv6/NBMA interface will then be a member of the LL, have a
  867.    Cluster Member ID (CMI) assigned, and can begin supporting IPv6 and
  868.    IPv6 ND operations.
  869.  
  870.    If the node is a host or router starting up it SHALL issue a single
  871.    group MARS_JOIN for the following groups:
  872.  
  873.       - Its derived Solicited-node address(es) with link-local scope.
  874.       - The All-nodes address with link-local scope.
  875.       - Other configured multicast groups with at least link-local
  876.         scope.
  877.  
  878.    If the node is a router it SHALL additionally issue:
  879.  
  880.       - A single group MARS_JOIN for the All-routers address with
  881.         link-local scope.
  882.       - A block MARS_JOIN for the range(s) of IPv6 multicast addresses
  883.         (with greater than link-local scope) for which promiscuous
  884.         reception is required.
  885.  
  886.    The encapsulation mechanism for, and key field values of, MARS
  887.    control messages SHALL be defined in companion documents specific to
  888.    particular NBMA network technologies.
  889.  
  890. 4.2 Joining a Multicast Group.
  891.  
  892.    This section describes the node's behavior when it gets a
  893.    JoinLocalGroup request from the IPv6 Layer. The details of how this
  894.    behavior is achieved are going to be implementation specific.
  895.  
  896.  
  897.  
  898. Armitage, et. al.           Standards Track                    [Page 16]
  899.  
  900. RFC 2491                IPv6 over NBMA networks             January 1999
  901.  
  902.  
  903.    If a JoinLocalGroup for a node-local address is received, the
  904.    IPv6/NBMA driver SHALL return success indication to the caller and
  905.    take no additional action. (Packets sent to node-local addresses
  906.    never reach the IPv6/NBMA driver.)
  907.  
  908.    If a JoinLocalGroup is received for an address with greater than
  909.    node-local scope, the IPv6/NBMA driver SHALL send an appropriate
  910.    single group MARS_JOIN request to register this address with the
  911.    MARS.
  912.  
  913. 4.3. Leaving a Multicast Group.
  914.  
  915.    This section describes the node's behavior when it gets a
  916.    LeaveLocalGroup request from the IPv6 Layer. The details of how this
  917.    behavior is achieved are going to be implementation specific.
  918.  
  919.    If a LeaveLocalGroup for a node-local address is received, the
  920.    IPv6/NBMA driver SHALL return success indication to the caller and
  921.    take no additional action. (Packets sent to node-local addresses
  922.    never reach the IPv6/NBMA driver.)
  923.  
  924.    If a LeaveLocalGroup is received for an address with greater than
  925.    node-local scope, the IPv6/NBMA driver SHALL send an appropriate
  926.    single group MARS_LEAVE request to deregister this address with the
  927.    MARS.
  928.  
  929. 4.4.  Sending Data.
  930.  
  931.    Separate processing and encapsulation rules apply for outbound
  932.    unicast and multicast packets.
  933.  
  934. 4.4.1. Sending Unicast Data.
  935.  
  936.    The IP level 'next hop' for each outbound unicast IPv6 packet is used
  937.    to identify a pt-pt VC on which to forward the packet.
  938.  
  939.       For NBMA networks where LLC/SNAP encapsulation is typically used
  940.       (e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with the
  941.       following LLC/SNAP header and sent over the VC.
  942.  
  943.          [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
  944.              (LLC)       (OUI)     (PID)
  945.  
  946.       For NBMA networks that do not use LLC/SNAP encapsulation, an
  947.       alternative rule SHALL be specified in the NBMA-specific companion
  948.       document.
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Armitage, et. al.           Standards Track                    [Page 17]
  955.  
  956. RFC 2491                IPv6 over NBMA networks             January 1999
  957.  
  958.  
  959.    If no pt-pt VC exists for the next hop address for the packet, the
  960.    node SHALL place a call to set up a VC to the next hop destination.
  961.    Any time the IPv6/NBMA driver receives a unicast packet for
  962.    transmission the IPv6 layer will already have determined the link-
  963.    layer (NBMA) address of the next hop.  Thus, the information needed
  964.    to place the NBMA call to the next hop will be available.
  965.  
  966.    The sending node SHOULD queue the packet that triggered the call
  967.    request, and send it when the call is established.
  968.  
  969.    If the call to the next hop destination node fails the sending node
  970.    SHALL discard the packet that triggered the call setup.  Persistent
  971.    failure to create a VC to the next hop destination will be detected
  972.    and handled at the IPv6 Network Layer through NUD.
  973.  
  974.    At this time no rules are specified for mapping outbound packets to
  975.    VCs using anything more than the packet's destination address.
  976.  
  977. 4.4.2. Sending Multicast Data.
  978.  
  979.    The IP level 'next hop' for each outbound multicast IPv6 packet is
  980.    used to identify a pt-pt or pt-mpt VC on which to forward the packet.
  981.  
  982.       For NBMA networks where LLC/SNAP encapsulation is typically used
  983.       (e.g. ATM or SMDS), multicast packets SHALL be encapsulated in the
  984.       following manner:
  985.  
  986.          [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
  987.          packet]
  988.              (LLC)       (OUI)     (PID)    (mars encaps)
  989.  
  990.          The IPv6/NBMA driver's Cluster Member ID SHALL be copied into
  991.          the 2 octet pkt$cmi field prior to transmission.
  992.  
  993.       For NBMA networks that do not use LLC/SNAP encapsulation, an
  994.       alternative rule SHALL be specified in the NBMA-specific companion
  995.       document. Some mechanism for carrying the IPv6/NBMA driver's
  996.       Cluster Member ID SHALL be provided.
  997.  
  998.    If the packet's destination is one of the following multicast
  999.    addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt
  1000.    VC to the MARS:
  1001.  
  1002.       - A Solicited-node address with link-local scope.
  1003.       - The All-nodes address with link-local scope.
  1004.       - The All-routers address with link-local scope.
  1005.       - A DHCP-v6 relay or server multicast address.
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Armitage, et. al.           Standards Track                    [Page 18]
  1011.  
  1012. RFC 2491                IPv6 over NBMA networks             January 1999
  1013.  
  1014.  
  1015.    The MARS SHALL then redistribute the IPv6 packet as described in
  1016.    section 3.1.1.  (If the VC to the MARS has been idle timed out for
  1017.    some reason, it MUST be re-established before forwarding the packet
  1018.    to the MARS.)
  1019.  
  1020.    If packet's destination is any other address, then the usual MARS
  1021.    client mechanisms are used by the IPv6/NBMA driver to select and/or
  1022.    establish a pt-mpt VC on which the packet is to be sent.
  1023.  
  1024.    At this time no rules are specified for mapping outbound packets to
  1025.    VCs using anything more than the packet's destination address.
  1026.  
  1027. 4.5. Receiving Data.
  1028.  
  1029.    Packets received using the encapsulation shown in section 4.4.1 SHALL
  1030.    be de-encapsulated and passed up to the IPv6 layer.  The IPv6 layer
  1031.    then determines how the incoming packet is to be handled.
  1032.  
  1033.    Packets received using the encapsulation specified in section 4.4.2
  1034.    SHALL have their pkt$cmi field compared to the local IPv6/NBMA
  1035.    driver's own CMI.  If the pkt$cmi in the header matches the local CMI
  1036.    the packet SHALL be silently dropped.  Otherwise, the packet SHALL be
  1037.    de-encapsulated and passed to the IPv6 layer.  The IPv6 layer then
  1038.    determines how the incoming packet is to be handled.
  1039.  
  1040.    For NBMA networks that do not use LLC/SNAP encapsulation, alternative
  1041.    rules SHALL be specified in the NBMA-specific companion document.
  1042.  
  1043.    The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6
  1044.    packets arriving with encapsulation defined for unicast packets, nor
  1045.    attempt to filter out unicast IPv6 packets arriving with
  1046.    encapsulation defined for multicast packets.
  1047.  
  1048. 4.6. VC Setup and release for unicast data.
  1049.  
  1050.    Unicast VCs are maintained separately from multicast VCs.  The setup
  1051.    and maintenance of multicast VCs are handled by the MARS client in
  1052.    each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-pt
  1053.    VCs for unicast IPv6 traffic will be described here.  Only best
  1054.    effort unicast VCs are considered.  The creation of VCs for other
  1055.    classes of service is outside the scope of this document.
  1056.  
  1057.    Before sending a packet to a new destination within the same LL a
  1058.    node will first perform a Neighbor Discovery on the intra-LL target.
  1059.    This is done to resolve the IPv6 destination address into a link-
  1060.    layer address which the sender can then use to send unicast packets.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Armitage, et. al.           Standards Track                    [Page 19]
  1067.  
  1068. RFC 2491                IPv6 over NBMA networks             January 1999
  1069.  
  1070.  
  1071.    Appendix A.1.1 contains non-normative, descriptive text covering the
  1072.    Neighbor Solicitation/Advertisement exchange and eventual
  1073.    establishment of a new SVC.
  1074.  
  1075.    A Redirect message (either a redirect to a node on the same LL, or a
  1076.    shortcut redirect to a node outside the LL) results in the sending
  1077.    (redirected) node creating a new pt-pt VC to a new receiving node.
  1078.    the Redirect message SHALL contain the link layer (NBMA) address of
  1079.    the new receiving IPv6/NBMA interface.  The redirected node does not
  1080.    concern itself where the new receiving node is located on the NBMA
  1081.    network.  The redirected node will set up a pt-pt VC to the new node
  1082.    if one does not previously exist.  The redirected node will then use
  1083.    the new VC to send data rather than whatever VC it had previously
  1084.    been using.
  1085.  
  1086.    Redirects are unidirectional.  Even after the source has reacted to a
  1087.    redirect, the destination will continue to send IPv6 packets back to
  1088.    the redirected node on the old path.  This happens because the
  1089.    destination node has no way of determining the IPv6 address of the
  1090.    other end of a new VC in the absence of Neighbor Discovery. Thus,
  1091.    redirects will not result in both ends of a connection using the new
  1092.    VC. IPv6 redirects are not intended to provide symmetrical
  1093.    redirection.  If the non-redirected node eventually receives a
  1094.    redirect it MAY discover the existing VC to the target node and use
  1095.    that rather than creating a new VC.
  1096.  
  1097.    It is desirable that VCs are released when no longer needed.
  1098.  
  1099.       An IPv6/NBMA driver SHALL release any VC that has been idle for 20
  1100.       minutes.
  1101.  
  1102.    This time limit MAY be reduced through configuration or as specified
  1103.    in companion documents for specific NBMA networks.
  1104.  
  1105.    If a Neighbor or Destination cache entry is purged then any VCs
  1106.    associated with the purged entry SHOULD be released.
  1107.  
  1108.    If the state of an entry in the Neighbor cache is set to STALE, then
  1109.    any VCs associated with the stale entry SHOULD be released.
  1110.  
  1111. 4.7 NBMA SVC Signaling Support and MTU issues.
  1112.  
  1113.    Mechanisms for signaling the establishment and teardown of pt-pt and
  1114.    pt-mpt SVCs for different NBMA networks SHALL be specified in
  1115.    companion documents.
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Armitage, et. al.           Standards Track                    [Page 20]
  1123.  
  1124. RFC 2491                IPv6 over NBMA networks             January 1999
  1125.  
  1126.  
  1127.    Since any given IPv6/NBMA driver will not know if the remote end of a
  1128.    VC is in the same LL, drivers SHALL implement NBMA-specific
  1129.    mechanisms to negotiate acceptable MTUs at the VC level. These
  1130.    mechanisms SHALL be specified in companion documents.
  1131.  
  1132.    However, IPv6/NBMA drivers can assume that they will always be
  1133.    talking to another driver attached to the same type of NBMA network.
  1134.    (For example, an IPv6/NBMA driver does not need to consider the
  1135.    possibility of establishing a shortcut VC directly to an IPv6/FR
  1136.    driver.)
  1137.  
  1138. 5. Interface Tokens, Link Layer Address Options, Link-Local Addresses
  1139.  
  1140. 5.1 Interface Tokens
  1141.  
  1142.    Each IPv6 interface must have an interface token from which to form
  1143.    IPv6 autoconfigured addresses. This interface token must be unique
  1144.    within a Logical Link to prevent the creation of duplicate addresses
  1145.    when stateless address configuration is used.
  1146.  
  1147.    In cases where two nodes on the same LL produce the same interface
  1148.    token then one interface MUST choose another host-token.  All
  1149.    implementations MUST support manual configuration of interface tokens
  1150.    to allow operators to manually change a interface token on a per-LL
  1151.    basis.  Operators may choose to manually set interface tokens for
  1152.    reasons other than eliminating duplicate addresses.
  1153.  
  1154.    All interface tokens MUST be 64 bits in length and formatted as
  1155.    described in the following sections.  The hosts tokens will be based
  1156.    on the format of an EUI-64 identifier [10]. Refer to [19 - Appendix
  1157.    A] for a description of creating IPv6 EUI-64 based interface
  1158.    identifiers.
  1159.  
  1160. 5.1.1 Single Logical Links on a Single NBMA Interface
  1161.  
  1162.    Physical NBMA interfaces will generally have some local identifier
  1163.    that may be used to generate a unique IPv6/NBMA interface token. The
  1164.    exact mechanism for generating interface tokens SHALL be specified in
  1165.    companion documents specific to each NBMA network.
  1166.  
  1167. 5.1.2 Multiple Logical Links on a Single NBMA Interface
  1168.  
  1169.    Physical NBMA interfaces MAY be used to provide multiple logical NBMA
  1170.    interfaces. Since each logical NBMA interface MAY support an
  1171.    independent IPv6 interface, two separate scenarios are possible:
  1172.  
  1173.       - A single host with separate IPv6/NBMA interfaces onto a number
  1174.         of independent Logical Links.
  1175.  
  1176.  
  1177.  
  1178. Armitage, et. al.           Standards Track                    [Page 21]
  1179.  
  1180. RFC 2491                IPv6 over NBMA networks             January 1999
  1181.  
  1182.  
  1183.       - A set of 2 or more 'virtual hosts' (vhosts) sharing a common
  1184.         NBMA driver. Each vhost is free to establish IPv6/NBMA
  1185.         interfaces associated with different or common LLs. However,
  1186.         vhosts are bound by the same requirement as normal hosts - no
  1187.         two interfaces to the same LL can share the same interface
  1188.         token.
  1189.  
  1190.    In the first scenario, since each IPv6/NBMA interface is associated
  1191.    with a different LL, each interface's external identity can be
  1192.    differentiated by the LL's routing prefix.  Thus, the host can re-use
  1193.    a single unique interface token across all its IPv6/NBMA interfaces.
  1194.    (Internally the host will tag received packets in some locally
  1195.    specific manner to identify what IPv6/NBMA interface they arrived on.
  1196.    However, this is an issue generic to IPv6, and does not required
  1197.    clarification in this document.)
  1198.  
  1199.    The second scenario is more complex, but likely to be rarer.
  1200.  
  1201.    When supporting multiple logical NBMA interfaces over a single
  1202.    physical NBMA interface, independent and unique identifiers SHALL be
  1203.    generated for each virtual NBMA interface to enable the construction
  1204.    of unique IPv6/NBMA interface tokens.  The exact mechanism for
  1205.    generating interface tokens SHALL be specified in companion documents
  1206.    specific to each NBMA network.
  1207.  
  1208. 5.2 Link Layer Address Options
  1209.  
  1210.    Neighbor Discovery defines two option fields for carrying link-layer
  1211.    specific source and target addresses.
  1212.  
  1213.    Between IPv6/NBMA interfaces, the format for these two options is
  1214.    adapted from the MARS [5] and NHRP [8] specs. It SHALL be:
  1215.  
  1216.           [Type][Length][NTL][STL][..NBMA Number..][..NBMA
  1217.           Subaddress..]
  1218.           |   Fixed    ||            Link layer address
  1219.           |
  1220.  
  1221.    [Type] is a one octet field.
  1222.  
  1223.           1 for Source link-layer address.
  1224.           2 for Target link-layer address.
  1225.  
  1226.    [Length] is a one octet field.
  1227.  
  1228.    The total length of the option in multiples of 8 octets. Zeroed bytes
  1229.    are added to the end of the option to ensure its length is a multiple
  1230.    of 8 octets.
  1231.  
  1232.  
  1233.  
  1234. Armitage, et. al.           Standards Track                    [Page 22]
  1235.  
  1236. RFC 2491                IPv6 over NBMA networks             January 1999
  1237.  
  1238.  
  1239.    [NTL] is a one octet 'Number Type & Length' field.
  1240.  
  1241.    [STL] is a one octet 'SubAddress Type & Length' field.
  1242.  
  1243.    [NBMA Number] is a variable length field. It is always present. This
  1244.    contains the primary NBMA address.
  1245.  
  1246.    [NBMA Subaddress] is a variable length field. It may or may not be
  1247.    present. This contains any NBMA subaddress that may be required.
  1248.  
  1249.    If the [NBMA Subaddress] is not present, the option ends after the
  1250.    [NBMA Number] ( and any additional padding for 8 byte alignment).
  1251.  
  1252.    The contents and interpretation of the [NTL], [STL], [NBMA Number],
  1253.    and [NBMA Subaddress] fields are specific to each NBMA network, and
  1254.    SHALL be specified in companion documents.
  1255.  
  1256. 5.3 Link-Local Addresses
  1257.  
  1258.    The IPv6 link-local address is formed by appending the interface
  1259.    token, as defined above, to the prefix FE80::/64.
  1260.  
  1261.           10 bits            54 bits                  64 bits
  1262.       +----------+-----------------------+----------------------------+
  1263.       |1111111010|         (zeros)       |      Interface Token       |
  1264.       +----------+-----------------------+----------------------------+
  1265.  
  1266. 6. Conclusion and Open Issues
  1267.  
  1268.    This document describes a general architecture for IPv6 over NBMA
  1269.    networks. It forms the basis for subsidiary companion documents that
  1270.    provide details for various specific NBMA technologies (such as ATM
  1271.    or Frame Relay). The IPv6 over NBMA architecture allows conventional
  1272.    host-side operation of the IPv6 Neighbor Discovery protocol, while
  1273.    also supporting the establishment of 'shortcut' NBMA forwarding paths
  1274.    (when dynamically signaled NBMA links are available).
  1275.  
  1276.    The IPv6 "Link" is generalized to "Logical Link" in an analagous
  1277.    manner to the IPv4 "Logical IP Subnet".  The MARS protocol is
  1278.    augmented and used to provide relatively efficient intra Logical Link
  1279.    multicasting of IPv6 packets, and distribution of Discovery messages.
  1280.    Shortcut NBMA level paths are supported either through router based
  1281.    flow detection, or host originated explicit requests.  Neighbor
  1282.    Discovery is used without modification for all intra-LL control
  1283.    (including the initiation of NBMA shortcut discovery).  Router to
  1284.    router NHRP is used to obtain the IPv6/NBMA address mappings for
  1285.    shortcut targets outside a source's Logical Link.
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Armitage, et. al.           Standards Track                    [Page 23]
  1291.  
  1292. RFC 2491                IPv6 over NBMA networks             January 1999
  1293.  
  1294.  
  1295. 7. Security Considerations
  1296.  
  1297.    This architecture introduces no new protocols, but depends on
  1298.    existing protocols (NHRP, IPv6, ND, MARS) and is therefore subject to
  1299.    all the security threats inherent in these protocols. This
  1300.    architecture should not be used in a domain where any of the base
  1301.    protocols are considered unacceptably insecure. However, this
  1302.    protocol itself does not introduce additional security threats.
  1303.  
  1304.    While this proposal does not introduce any new security mechanisms
  1305.    all current IPv6 security mechanisms will work without modification
  1306.    for NBMA.  This includes both authentication and encryption for both
  1307.    Neighbor Discovery protocols as well as the exchange of IPv6 data
  1308.    packets. The MARS protocol is modified in a manner that does not
  1309.    affect or augment the security offered by RFC 2022.
  1310.  
  1311. Acknowledgments
  1312.  
  1313.    Eric Nordmark confirmed the usefulness of ND Redirect messages in
  1314.    private email during the March 1996 IETF. The discussions with
  1315.    various ION WG members during the June and December 1996 IETF helped
  1316.    solidify the architecture described here. Grenville Armitage's
  1317.    original work on IPv6/NBMA occurred while employed at Bellcore.
  1318.    Elements of section 5 were borrowed from Matt Crawford's memo on IPv6
  1319.    over Ethernet.
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Armitage, et. al.           Standards Track                    [Page 24]
  1347.  
  1348. RFC 2491                IPv6 over NBMA networks             January 1999
  1349.  
  1350.  
  1351. Authors' Addresses
  1352.  
  1353.    Grenville Armitage
  1354.    Bell Laboratories, Lucent Technologies
  1355.    101 Crawfords Corner Road
  1356.    Holmdel, NJ 07733
  1357.    USA
  1358.  
  1359.    EMail: gja@lucent.com
  1360.  
  1361.  
  1362.    Peter Schulter
  1363.    Bright Tiger Technologies
  1364.    125 Nagog Park
  1365.    Acton, MA 01720
  1366.  
  1367.    EMail: paschulter@acm.org
  1368.  
  1369.  
  1370.    Markus Jork
  1371.    European Applied Research Center
  1372.    Digital Equipment GmbH
  1373.    CEC Karlsruhe
  1374.    Vincenz-Priessnitz-Str. 1
  1375.    D-76131 Karlsruhe
  1376.    Germany
  1377.  
  1378.    EMail: jork@kar.dec.com
  1379.  
  1380.  
  1381.    Geraldine Harter
  1382.    Digital UNIX Networking
  1383.    Compaq Computer Corporation
  1384.    110 Spit Brook Road
  1385.    Nashua, NH 03062
  1386.  
  1387.    EMail: harter@zk3.dec.com
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Armitage, et. al.           Standards Track                    [Page 25]
  1403.  
  1404. RFC 2491                IPv6 over NBMA networks             January 1999
  1405.  
  1406.  
  1407. References
  1408.  
  1409.    [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
  1410.        Specification", RFC 2460, December 1998.
  1411.  
  1412.    [2] ATM Forum, "ATM User Network Interface (UNI) Specification
  1413.        Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood
  1414.        Cliffs, NJ, June 1995.
  1415.  
  1416.    [3] Crawford, M., "A Method for the Transmission of IPv6 Packets over
  1417.        Ethernet Networks", RFC 1972, August 1996.
  1418.  
  1419.    [4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
  1420.        Layer 5", RFC 1483, July 1993.
  1421.  
  1422.    [5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
  1423.        Networks", RFC 2022, November 1996.
  1424.  
  1425.    [6] Hinden, R. and S. Deering, "IP Version 6 Addressing
  1426.        Architecture", RFC 2373, July 1998.
  1427.  
  1428.    [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
  1429.        IP Version 6 (IPv6)", RFC 2461, December 1998.
  1430.  
  1431.    [8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy,
  1432.        "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
  1433.  
  1434.    [9] Thomson, S. and T. Narten, "IPv6 Stateless Address
  1435.        Autoconfiguration", RFC 2462, December 1998.
  1436.  
  1437.    [10] "64-Bit Global Identifier Format Tutorial",
  1438.         http://standards.ieee.org/db/oui/tutorials/EUI64.html.
  1439.  
  1440.    [11] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router
  1441.         Architecture Extensions for ATM : Overview", RFC 2098, February
  1442.         1997.
  1443.  
  1444.    [12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under
  1445.         IP", Proceedings of INFOCOM'96, San Francisco, March 1996,
  1446.         pp.1251-1260
  1447.  
  1448.    [13] Piscitello, D. and J. Lawrence, "The Transmission of IP
  1449.         Datagrams over the SMDS Service", RFC 1209, March 1991.
  1450.  
  1451.    [14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  1452.         Converting Network Protocol Addresses to 48.bit Ethernet Address
  1453.         for Transmission on Ethernet Hardware", STD 37, RFC 826,
  1454.         November 1982.
  1455.  
  1456.  
  1457.  
  1458. Armitage, et. al.           Standards Track                    [Page 26]
  1459.  
  1460. RFC 2491                IPv6 over NBMA networks             January 1999
  1461.  
  1462.  
  1463.    [15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
  1464.         version 6", RFC 1981, August 1996.
  1465.  
  1466.    [16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  1467.         Levels", BCP 14, RFC 2119, March 1997.
  1468.  
  1469.    [17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
  1470.         Networks", RFC 2492, January 1999.
  1471.  
  1472.    [18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol for
  1473.         IPv6 (DHCPv6)", Work in Progress.
  1474.  
  1475.    [19] Hinden, R. and S. Deering, "IP Version 6 Addressing
  1476.         Architecture", RFC 2373, July 1998.
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Armitage, et. al.           Standards Track                    [Page 27]
  1515.  
  1516. RFC 2491                IPv6 over NBMA networks             January 1999
  1517.  
  1518.  
  1519. Appendix A.  IPv6 Protocol Operation Description
  1520.  
  1521.    The IPv6 over NBMA model described in this document maintains the
  1522.    complete semantics of the IPv6 protocols. No changes need to be made
  1523.    to the IPv6 Network Layer. Since the concept of the security
  1524.    association is not being changed for NBMA, this framework maintains
  1525.    complete IPv6 security semantics and features. This allows IPv6 nodes
  1526.    to choose their responses to solicitations based on security
  1527.    information as is done with other datalinks, thereby maintaining the
  1528.    semantics of Neighbor Discovery since it is always the solicited node
  1529.    that chooses what (and even if) to reply to the solicitation. Thus,
  1530.    NBMA will be transparent to the network layer except in cases where
  1531.    extra services (such as QoS VCs) are offered.
  1532.  
  1533.    The remainder of this Appendix describes how the core IPv6 protocols
  1534.    will operate within the model described here.
  1535.  
  1536. A.1 Neighbor Discovery Operations
  1537.  
  1538.    Before performing any sort of Neighbor discover operation, each node
  1539.    must first join the all-node multicast group, and it's solicited node
  1540.    multicast address (the use of this address in relation to DAD is
  1541.    described in A.1.4).  The IPv6 network layer will join these
  1542.    multicast groups as described in 4.2.
  1543.  
  1544. A.1.1 Performing Address Resolution
  1545.  
  1546.    An IPv6 host performs address resolution by sending a Neighbor
  1547.    Solicitation to the solicited-node multicast address of the target
  1548.    host, as described in [7]. The Neighbor Solicitation message will
  1549.    contain a Source Link-Layer Address Option set to the soliciting
  1550.    node's NBMA address on the LL.
  1551.  
  1552.    When the local node's IPv6/NBMA driver is passed the Neighbor
  1553.    Solicitation message from the IPv6 network layer, it follows the
  1554.    steps described in section 4.4.2 Sending Multicast Data.
  1555.  
  1556.    One or more nodes will receive the Neighbor Solicitation message.
  1557.    The nodes will process the data as described in section 4.5 and pass
  1558.    the de-encapsulated packets to the IPv6 network layer.
  1559.  
  1560.    If the receiving node is the target of the Neighbor Solicitation it
  1561.    will update its Neighbor cache with the soliciting node's NBMA
  1562.    address, contained in the Neighbor Solicitation message's Source
  1563.    Link-Layer Address Option as described in [7].
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Armitage, et. al.           Standards Track                    [Page 28]
  1571.  
  1572. RFC 2491                IPv6 over NBMA networks             January 1999
  1573.  
  1574.  
  1575.    The solicited IPv6 host will respond to the Neighbor Solicitation
  1576.    with a Neighbor Advertisement message sent to the IPv6 unicast
  1577.    address of the soliciting node.  The Neighbor Advertisement message
  1578.    will contain a Target Link-Layer Address Option set to the solicited
  1579.    node's NBMA address on the LL.
  1580.  
  1581.    The solicited node's IPv6/NBMA driver will be passed the Neighbor
  1582.    Advertisement and the soliciting node's link-layer address from the
  1583.    IPv6 network layer.  It will then follow the steps described in
  1584.    section section 4.4.1 to send the NA message to the soliciting node.
  1585.    This will create a pt-pt VC between the solicited node and soliciting
  1586.    node if one did not already exist.
  1587.  
  1588.    The soliciting node will then receive the Neighbor Advertisement
  1589.    message over the new PtP VC, de-encapsulate the message, and pass it
  1590.    to the IPv6 Network layer for processing as described in section 4.5.
  1591.    The soliciting node will then make the appropriate entries in it's
  1592.    Neighbor cache, including caching the NBMA link-layer address of the
  1593.    solicited node as described in [7].
  1594.  
  1595.    At this point each system has a complete Neighbor cache entry for the
  1596.    other system. They can exchange data over the pt-pt VC newly created
  1597.    by the solicited node when it returned the Neighbor Advertisement, or
  1598.    create a new VC.
  1599.  
  1600.    An IPv6 host can also send an Unsolicited Neighbor Advertisemnent to
  1601.    the all-nodes multicast address. When the local node IPv6/NBMA driver
  1602.    is passed the Neighbor Advertisement from the IPv6 network layer, it
  1603.    follows the steps described in section 4.4.2 to send the NA message
  1604.    to the all-nodes multicast address.  Each node will process the
  1605.    incoming packet as described in section 4.5 and then pass the packet
  1606.    to the IPv6 network layer where it will be processed as described in
  1607.    [7].
  1608.  
  1609. A.1.2 Performing Router Discovery
  1610.  
  1611.    Router Discovery is described in [7]. To support Router Discovery an
  1612.    IPv6 router will join the IPv6 all-routers multicast group address.
  1613.    When the IPv6/NBMA driver gets the JoinLocalGroup request from the
  1614.    IPv6 Network Layer, it follows the process described in section 4.2.
  1615.  
  1616.    IPv6 routers periodically send unsolicited Router Advertisements
  1617.    announcing their availability on the LL.  When an IPv6 router sends
  1618.    an unsolicited Router Advertisement, it sends a data packet addressed
  1619.    to the IPv6 all-nodes multicast address. When the local node
  1620.    IPv6/NBMA driver gets the Router Advertisement message from the IPv6
  1621.    network layer, it transmits the message by following steps described
  1622.    in section 4.4.2.  The MARS will transmit the packet on the LL's
  1623.  
  1624.  
  1625.  
  1626. Armitage, et. al.           Standards Track                    [Page 29]
  1627.  
  1628. RFC 2491                IPv6 over NBMA networks             January 1999
  1629.  
  1630.  
  1631.    ClusterControlVC, which sends the packets to all nodes on the LL.
  1632.    Each node on the LL will then process the incoming packet as
  1633.    described in section 4.5 and pass the received packet to the IPv6
  1634.    Network layer for processing as appropriate.
  1635.  
  1636.    To perform Router Discovery, an IPv6 host sends a Router Solicitation
  1637.    message to the all-routers multicast address. When the local node
  1638.    IPv6/NBMA driver gets the request from the IPv6 Network Layer to send
  1639.    the packet, it follows the steps described in section 4.4.2.  The RS
  1640.    message will be sent to either those nodes which have joined the
  1641.    all-routers multicast group or to all nodes.  The nodes which receive
  1642.    the RA message will process the message as described in section 4.5
  1643.    and pass the RA message up to the IPv6 layer for processing.  Only
  1644.    those nodes which are routers will process the message and respond to
  1645.    it.
  1646.  
  1647.    An IPv6 router responds to a Router Solicitation by sending a Router
  1648.    Advertisement addressed to the IPv6 all-nodes multicast address if
  1649.    the source address of the Router Solicitation was the unspecified
  1650.    address.  If the source address in the Router Solicitation is not the
  1651.    unspecified address, the the router will unicast the Router
  1652.    Advertisement to the soliciting node.  If the router sends the Router
  1653.    Advertisement to the all-nodes multicast address then it follows the
  1654.    steps described above for unsolicited Router Advertisements.
  1655.  
  1656.    If the Router Advertisement is to be unicast to the soliciting node,
  1657.    the IPv6 network layer will give the node's IPv6/NBMA driver the
  1658.    Router Advertisement and link-layer address of the soliciting node
  1659.    (obtained through Address Resolution if necessary) which will send
  1660.    the packet according to the steps described in section 4.4.1 This
  1661.    will result in a new pt-pt VC being created between the router and
  1662.    the soliciting node if one did not already exist.
  1663.  
  1664.    The soliciting node will receive and process the Router Advertisement
  1665.    as described in section 4.5 and will pass the RA message to the IPv6
  1666.    network layer.  The IPv6 network layer may, depending on the state of
  1667.    the Neighbor cache entry, update the Neighbor cache with the router's
  1668.    NBMA address, contained in the Router Advertisement message's Source
  1669.    Link-Layer Address Option.
  1670.  
  1671.    If a pt-pt VC is set up during Router Discovery, subsequent IPv6 best
  1672.    effort unicast data between the soliciting node and the router will
  1673.    be transmitted over the new PtP VC.
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Armitage, et. al.           Standards Track                    [Page 30]
  1683.  
  1684. RFC 2491                IPv6 over NBMA networks             January 1999
  1685.  
  1686.  
  1687. A.1.3 Performing Neighbor Unreachability Detection (NUD)
  1688.  
  1689.    Neighbor Unreachability Detection (NUD) is the process by which an
  1690.    IPv6 host determines that a neighbor is no longer reachable, as
  1691.    described in [7]. Each Neighbor cache entry contains information used
  1692.    by the NUD algorithm to detect reachability failures.  Confirmation
  1693.    of a neighbor's reachability comes either from upper-layer protocol
  1694.    indications that data recently sent to the neighbor was received, or
  1695.    from the receipt of a Neighbor Advertisement message in response to a
  1696.    Neighbor Solicitation probe.
  1697.  
  1698.    Connectivity failures at the node's IPv6/NBMA driver, such as
  1699.    released VCs (see section 4.6) and the inability to create a VC to a
  1700.    neighbor (see section 4.4.1), are detected and handled at the IPv6
  1701.    network layer, through Neighbor Unreachability Detection.  The node's
  1702.    IPv6/NBMA driver does not attempt to detect or recover from these
  1703.    conditions.
  1704.  
  1705.    A persistent failure to create a VC from the IPv6 host to one of its
  1706.    IPv6 neighbors will be detected and handled through NUD. On each
  1707.    attempt to send data from the IPv6 host to its neighbor, the node's
  1708.    IPv6/NBMA driver will attempt to set up a VC to the neighbor, and
  1709.    failing to do so, will drop the packet. IPv6 reachability
  1710.    confirmation timers will eventually expire, and the neighbor's
  1711.    Neighbor cache entry will enter the PROBE state. The PROBE state will
  1712.    cause the IPv6 host to unicast Neighbor Solicitations to the
  1713.    neighbor, which will be dropped by the local node's IPv6/NBMA driver
  1714.    after again failing to setup the VC. The IPv6 host will therefore
  1715.    never receive the solicited Neighbor Advertisements needed for
  1716.    reachability confirmation, causing the neighbor's entry to be deleted
  1717.    from the Neighbor cache. The next time the IPv6 host tries to send
  1718.    data to that neighbor, address resolution will be performed.
  1719.    Depending on the reason for the previous failure, connectivity to the
  1720.    neighbor could be re-established (for example, if the previous VC
  1721.    setup failure was caused by an obsolete link-layer address in the
  1722.    Neighbor cache).
  1723.  
  1724.    In the event that a VC from an IPv6 neighbor is released, the next
  1725.    time a packet is sent from the IPv6 host to the neighbor, the node's
  1726.    IPv6/NBMA driver will recognize that it no longer has a VC to that
  1727.    neighbor and attempt to setup a new VC to the neighbor.  If, on the
  1728.    first and on subsequent transmissions, the node is unable to create a
  1729.    VC to the neighbor, NUD will detect and handle the failure as
  1730.    described earlier (handling the persistent failure to create a VC
  1731.    from the IPv6 host to one of its IPv6 neighbors). Depending on the
  1732.    reason for the previous failure, connectivity to the neighbor may or
  1733.    may not be re-established.
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Armitage, et. al.           Standards Track                    [Page 31]
  1739.  
  1740. RFC 2491                IPv6 over NBMA networks             January 1999
  1741.  
  1742.  
  1743. A.1.4 Performing Duplicate Address Detection (DAD)
  1744.  
  1745.    An IPv6 host performs Duplicate Address Detection (DAD) to determine
  1746.    that the address it wishes to use on the LL (i.e. a tentative
  1747.    address) is not already in use, as described in [9] and [7].
  1748.    Duplicate Address Detection is performed on all addresses the host
  1749.    wishes to use, regardless of the configuration mechanism used to
  1750.    obtain the address.
  1751.  
  1752.    Prior to performing Duplicate Address Detection, a host will join the
  1753.    all-nodes multicast address and the solicited-node multicast address
  1754.    corresponding to the host's tentative address (see 4.2.  Joining a
  1755.    Multicast Group). The IPv6 host initiates Duplicate Address Detection
  1756.    by sending a Neighbor Solicitation to solicited-node multicast
  1757.    address corresponding to the host's tentative address, with the
  1758.    tentative address as the target.  When the local node's IPv6/NBMA
  1759.    driver gets the Neighbor Solicitation message from the IPv6 network
  1760.    layer, it follows the steps outlined in section 4.4.2.  The NS
  1761.    message will be sent to those nodes which joined the target
  1762.    solicited-node multicast group or to all nodes.  The DAD NS message
  1763.    will be received by one or more nodes on the LL and processed by each
  1764.    as described in section 4.5.  Note that the MARS client of the
  1765.    sending node will filter out the message so that the sending node's
  1766.    IPv6 network layer will not see the message.  The IPv6 network layer
  1767.    of any node which is not a member of the target solicited-node
  1768.    multicast group will discard the Neighbor Solicitation message.
  1769.  
  1770.    If no other hosts have joined the solicited-node multicast address
  1771.    corresponding to the tentative address, then the host will not
  1772.    receive a Neighbor Advertisement containing its tentative address as
  1773.    the target.  The host will perform the retransmission logic described
  1774.    in [9], terminate Duplicate Address Detection, and assign the
  1775.    tentative address to the NBMA interface.
  1776.  
  1777.    Otherwise, other hosts on the LL that have joined the solicited-node
  1778.    multicast address corresponding to the tentative address will process
  1779.    the Neighbor Solicitation. The processing will depend on whether or
  1780.    not receiving IPv6 host considers the target address to be tentative.
  1781.  
  1782.    If the receiving IPv6 host's address is not tentative, the host will
  1783.    respond with a Neighbor Advertisement containing the target address.
  1784.    Because the source of the Neighbor Solicitation is the unspecified
  1785.    address, the host sends the Neighbor Advertisement to the all-nodes
  1786.    multicast address following the steps outlined in section 4.4.2.  The
  1787.    DAD NA message will be received and processed by the MARS clients on
  1788.    all nodes in the LL as described in section 4.5.  Note that the
  1789.    sending node will filter the incoming message since the CMI in the
  1790.    message header will match that of the receiving node.  All other
  1791.  
  1792.  
  1793.  
  1794. Armitage, et. al.           Standards Track                    [Page 32]
  1795.  
  1796. RFC 2491                IPv6 over NBMA networks             January 1999
  1797.  
  1798.  
  1799.    nodes will de-encapsulate the message and pass it to the IPv6 network
  1800.    layer.  The host performing DAD will detect that its tentative
  1801.    address is the target of the Neighbor Advertisement, and determine
  1802.    that the tentative address is not unique and cannot be assigned to
  1803.    its NBMA interface.
  1804.  
  1805.    If the receiving IPv6 host's address is tentative, then both hosts
  1806.    are performing DAD using the same tentative address. The receiving
  1807.    host will determine that the tentative address is not unique and
  1808.    cannot be assigned to its NBMA interface.
  1809.  
  1810. A.1.5 Processing Redirects
  1811.  
  1812.    An IPv6 router uses a Redirect Message to inform an IPv6 host of a
  1813.    better first-hop for reaching a particular destination, as described
  1814.    in [7].  This can be used to direct hosts to a better first hop
  1815.    router, another host on the same LL, or to a transient neighbor on
  1816.    another LL.  The IPv6 router will unicast the Redirect to the IPv6
  1817.    source address that triggered the Redirect. The router's IPv6/NBMA
  1818.    driver will transmit the Redirect message using the procedure
  1819.    described in section 4.4.1.  This will create a VC between the router
  1820.    and the redirected host if one did not previously exist.
  1821.  
  1822.    The IPv6/NBMA driver of the IPv6 host that triggered the Redirect
  1823.    will receive the encapsulated Redirect over one of it's pt-pt VCs.
  1824.    It will the de-encapsulate the packet, and pass the Redirect message
  1825.    to the IPv6 Network Layer, as described section 4.5.
  1826.  
  1827.    Subsequent data sent from the IPv6 host to the destination will be
  1828.    sent to the next-hop address specified in the Redirect Message.  For
  1829.    NBMA networks, the Redirect Message should contain the link-layer
  1830.    address option as described in [7] and section 5.2, thus the
  1831.    redirected node will not have to perform a Neighbor Solicitation to
  1832.    learn the link-layer address of the node to which it has been
  1833.    redirected.  Thus, the redirect can be to any node on the NBMA
  1834.    network, regardless of the LL membership of the new target node.
  1835.    This allows NBMA hosts to be redirected off their LL to achieve
  1836.    shortcut by using standard IPv6 protocols.
  1837.  
  1838.    Once redirected, the IPv6 network layer will give the node's
  1839.    IPv6/NBMA driver the IPv6 packet and the link-layer address of the
  1840.    next-hop node when it sends data to the redirected destination. The
  1841.    node's IPv6/NBMA driver will determine if a VC to the next-hop
  1842.    destination exists.  If a pt-pt VC does not exist, then the IPv6/NBMA
  1843.    driver will queue the data packet and initiate a setup of a VC to the
  1844.    destination.  When the VC is created, or if one already exists, then
  1845.    the node will encapsulate the outgoing data packet and send it on the
  1846.    VC.
  1847.  
  1848.  
  1849.  
  1850. Armitage, et. al.           Standards Track                    [Page 33]
  1851.  
  1852. RFC 2491                IPv6 over NBMA networks             January 1999
  1853.  
  1854.  
  1855.    Note that Redirects are unidirectional.  The redirected host will
  1856.    create a VC to the next-hop destination as specified in the Redirect
  1857.    message, but the next-hop will not be redirected to the source host.
  1858.    Because no Neighbor Discovery takes place, the next-hop destination
  1859.    has no way of determining the identity of the caller when it receives
  1860.    the new VC.  Also, since ND does not take place on redirects, the
  1861.    next-hop receives no event that would cause it to update it's
  1862.    neighbor or destination caches.  However, it will continue to
  1863.    transmit data back to the redirected host on the former path to the
  1864.    redirected host.  The next-hop node should be able to use the new VC
  1865.    from the redirected destination if it too receives a redirect
  1866.    redirecting it to the redirected node.  This behavior is consistent
  1867.    with [7].
  1868.  
  1869. A.2 Address Configuration
  1870.  
  1871.    IPv6 addresses are auto-configured using the stateless or stateful
  1872.    address auto-configuration mechanisms, as described in [9] and [18].
  1873.    The IPv6 auto-configuration process involves creating and verifying
  1874.    the uniqueness of a link-local address on an LL, determining whether
  1875.    to use stateless and/or stateful configurationmechanisms to obtain
  1876.    addresses, and determining if other (non- address) information is to
  1877.    be autoconfigured. IPv6 addresses can also be manually configured, if
  1878.    for example, auto-configuration fails because the autoconfigured
  1879.    link-local address is not unique.  An LL administrator specifies the
  1880.    type of autoconfiguration to use; the hosts on an LL receive this
  1881.    autoconfiguration information through Router Advertisement messages.
  1882.  
  1883.    The following sections describe how stateless, stateful and manual
  1884.    address configuration will work in an IPv6/NBMA environment.
  1885.  
  1886. A.2.1 Stateless Address Configuration
  1887.  
  1888.    IPv6 stateless address configuration is the process by which an IPv6
  1889.    host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
  1890.  
  1891.    When an IPv6 host first starts up, it generates a link-local address
  1892.    for the interface attached to the Logical Link.  It then verifies the
  1893.    uniqueness of the link-local address using Duplicate Address
  1894.    Detection (DAD).  If the IPv6 host detects that the link-local
  1895.    address is not unique, the autoconfiguration process terminates.  The
  1896.    IPv6 host must then be manually configured.
  1897.  
  1898.    After the IPv6 host determines that the link-local address is unique
  1899.    and has assigned it to the interface on the Logical Link, the IPv6
  1900.    host will perform Router Discovery to obtain auto-configuration
  1901.    information.  The IPv6 host will send out a Router Solicitation and
  1902.    will receive a Router Advertisement, or it will wait for an
  1903.  
  1904.  
  1905.  
  1906. Armitage, et. al.           Standards Track                    [Page 34]
  1907.  
  1908. RFC 2491                IPv6 over NBMA networks             January 1999
  1909.  
  1910.  
  1911.    unsolicited Router Advertisement.  The IPv6 host will process the M
  1912.    and O bits of the Router Advertisement, as described in [9] and as a
  1913.    result may invoke stateful address auto- configuration.
  1914.  
  1915.    If there are no routers on the Logical Link, the IPv6 host will be
  1916.    able to communicate with other IPv6 hosts on the Logical Link using
  1917.    link-local addresses. The IPv6 host will obtain a neighbor's link-
  1918.    layer address using Address Resolution. The IPv6 host will also
  1919.    attempt to invoke stateful auto-configuration, unless it has been
  1920.    explicitly configured not to do so.
  1921.  
  1922. A.2.2 Stateful  Address Configuration (DHCP)
  1923.  
  1924.    IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to
  1925.    perform stateful address auto-configuration, as described in [18].
  1926.  
  1927.    A DHCPv6 server or relay agent is present on a Logical Link that has
  1928.    been configured with manual or stateful auto-configuration. The
  1929.    DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay-
  1930.    Agent multicast group on the Logical Link. When the node's IPv6/NBMA
  1931.    driver gets the JoinLocalGroup request from the IPv6 network layer,
  1932.    it follows the process described in section 4.2.
  1933.  
  1934.    An IPv6 host will invoke stateful auto-configuration if M and O bits
  1935.    of Router Advertisements indicate it should do so, and may invoke
  1936.    stateful auto-configuration if it detects that no routers are present
  1937.    on the Logical Link. An IPv6 host that is obtaining configuration
  1938.    information through the stateful mechanism will hereafter be referred
  1939.    to as a DHCPv6 client.
  1940.  
  1941.    A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv6
  1942.    Server/Relay-Agent multicast address to locate a DHCPv6 Agent. When
  1943.    the soliciting node's IPv6/NBMA driver gets the request from the IPv6
  1944.    Network Layer to send the packet, it follows the steps described in
  1945.    section 4.4.2.  This will result in one or more nodes on the LL
  1946.    receiving the message.  Each node that receives the solicitation
  1947.    packet will process it as described in section section 4.5. Only the
  1948.    IPv6 network layer of the DHCPv6 server/relay-agent will accept the
  1949.    packet and process it.
  1950.  
  1951.    A DHCPv6 Server or Relay Agent on the Logical Link will unicast a
  1952.    DHCPv6 Advertisement to the DHCPv6 client. The IPv6 network layer
  1953.    will give the node's IPv6/NBMA driver the packet and link-layer
  1954.    address of the DHCPv6 client (obtained through Neighbor Discovery if
  1955.    necessary).  The node IPv6/NBMA driver will then transmit the packet
  1956.    as described in section 4.4.1.  This will result in a new pt-pt VC
  1957.    being created between the server and the client if one did not
  1958.    previously exist.
  1959.  
  1960.  
  1961.  
  1962. Armitage, et. al.           Standards Track                    [Page 35]
  1963.  
  1964. RFC 2491                IPv6 over NBMA networks             January 1999
  1965.  
  1966.  
  1967.    The DHCP client's IPv6/NBMA driver will receive the encapsulated
  1968.    packet from the DHCP Server or Relay Agent, as described in section
  1969.    4.5. The node will de-encapsulate the multicast packet and then pass
  1970.    it up to the IPv6 Network Layer for processing. The IPv6 network
  1971.    layer will deliver the DHCPv6 Advertise message to the DHCPv6 client.
  1972.  
  1973.    Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are
  1974.    unicast between the DHCPv6 client and the DHCPv6 Server.  Depending
  1975.    on the reachability of the DHCPv6 client's address, messages
  1976.    exchanged between a DHCPv6 client and a DHCPv6 Server on another LL
  1977.    are sent either via a router or DHCPv6 Relay-Agent.  Prior to sending
  1978.    the DHCPv6 message, the IPv6 network layer will perform Neighbor
  1979.    Discovery (if necessary) to obtain the link-layer address
  1980.    corresponding to the packet's next-hop. A pt-pt VC will be set up
  1981.    between the sender and the next hop, and the encapsulated packet
  1982.    transmitted over it, as described in 4.4. Sending Data.
  1983.  
  1984. A.2.3 Manual Address Configuration
  1985.  
  1986.    An IPv6 host will be manually configured if it discovers through DAD
  1987.    that its link-local address is not unique. Once the IPv6 host is
  1988.    configured with a unique interface token, the auto-configuration
  1989.    mechanisms can then be invoked.
  1990.  
  1991. A.3 Internet Group Management Protocol (IGMP)
  1992.  
  1993.    IPv6 multicast routers will use the IGMPv6 protocol to periodically
  1994.    determine group memberships of local hosts.  In the framework
  1995.    described here, the IGMPv6 protocols can be used without any special
  1996.    modifications for NBMA.  While these protocols might not be the most
  1997.    efficient in this environment, they will still work as described
  1998.    below.  However, IPv6 multicast routers connected to an NBMA LL could
  1999.    optionally optimize the IGMP functions by sending
  2000.    MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and
  2001.    determining group memberships by the MARS_GROUPLIST_REPLY messages.
  2002.    Querying the MARS for multicast group membership is an optional
  2003.    enchancement and is not required for routers to determine IPv6
  2004.    multicast group membership on a LL.
  2005.  
  2006.    There are three ICMPv6 message types that carry multicast group
  2007.    membership information: the Group Membership Query, Group Membership
  2008.    Report and Group Membership Reduction messages.  IGMPv6 will continue
  2009.    to work unmodified over the IPv6/NBMA architecture described in this
  2010.    document.
  2011.  
  2012.    An IPv6 multicast router receives all IPv6 multicast packets on the
  2013.    LL by joining all multicast groups in promiscuous mode [5].  The MARS
  2014.    server will then cause the multicast router to be added to all
  2015.  
  2016.  
  2017.  
  2018. Armitage, et. al.           Standards Track                    [Page 36]
  2019.  
  2020. RFC 2491                IPv6 over NBMA networks             January 1999
  2021.  
  2022.  
  2023.    existing and future multicast VCs.  The IPv6 multicast router will
  2024.    thereafter be the recipient of all IPv6 multicast packets sent within
  2025.    the Logical Link.
  2026.  
  2027.    An IPv6 multicast router discovers which multicast groups have
  2028.    members in the Logical Link by periodically sending Group Membership
  2029.    Query messages to the IPv6 all-nodes multicast address.  When the
  2030.    local node's IPv6/NBMA driver gets the request from the IPv6 network
  2031.    layer to send the Group Membership Query packet, it follows the steps
  2032.    described in 4.4.2. The node determines that the destination address
  2033.    of the packet is the all-nodes multicast address and passes the
  2034.    packet to the node's MARS client where the packet is encapsulated and
  2035.    directly transmitted to the MARS. The MARS then relays the packet to
  2036.    all nodes in the LL. Each node's IPv6/NBMA drivers will receive the
  2037.    packet, de-encapsulate it, and passed it up to the IPv6 Network
  2038.    layer.  If the originating node receives the encapsulated packet, the
  2039.    packet will be filtered out by the MARS client since the Cluster
  2040.    Member ID of the receiving node will match the CMI in the packet's
  2041.    MARS encapsulation header.
  2042.  
  2043.    IPv6 hosts in the Logical Link will respond to a Group Membership
  2044.    Query with a Group Membership Report for each IPv6 multicast group
  2045.    joined by the host.  IPv6 hosts can also transmit a Group Membership
  2046.    Report when the host joins a new IPv6 multicast group.  The Group
  2047.    Membership Report is sent to the multicast group whose address is
  2048.    being reported. When the local node IPv6/NBMA driver gets the request
  2049.    from the IPv6 network layer to send the packet, it follows the steps
  2050.    described in 4.4.2.  The node determines that the packet is being
  2051.    sent to a multicast address so forwards it to the node's MARS client
  2052.    for sending on the appropriate VC.
  2053.  
  2054.    The Group Membership Report packets will arrive at every node which
  2055.    is a member of the group being reported through one of the VC
  2056.    attached to each node's MARS client.  The MARS client will de-
  2057.    encapsulate the incoming packet and the packet will be passed to the
  2058.    IPv6 network layer for processing.  The MARS client of the sending
  2059.    node will filter out the packet when it receives it.
  2060.  
  2061.    An IPv6 host sends a Group Membership Reduction message when the host
  2062.    leaves an IPv6 multicast group.  The Group Membership Reduction is
  2063.    sent to the multicast group the IPv6 host is leaving.  The
  2064.    transmission and receipt of Group Membership Reduction messages are
  2065.    handled in the same manner as Group Membership Reports.
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Armitage, et. al.           Standards Track                    [Page 37]
  2075.  
  2076. RFC 2491                IPv6 over NBMA networks             January 1999
  2077.  
  2078.  
  2079. Appendix B. Alternative models of MARS support for Intra-LL ND
  2080.  
  2081. B.1 Simplistic approach - Use MARS 'as is'.
  2082.  
  2083.    The IPv6/NBMA driver utilizes the standard MARS protocol to establish
  2084.    a VC forwarding path out of the interface on which it can transmit
  2085.    all multicast IPv6 packets, including ICMPv6 packets. The IPv6
  2086.    packets are then transmitted, and received by the intended
  2087.    destination set, using separate pt-mpt VCs per destination group.
  2088.  
  2089.    In this approach all the protocol elements in [5] are used 'as is'.
  2090.    However, SVC resource consumption must be taken into consideration.
  2091.    Unfortunately, ND assumes that link level multicast resources are
  2092.    best conserved by generating a sparsely distributed set of Solicited
  2093.    Node multicast addresses (to which discovery queries are initially
  2094.    sent).  The original goal was to minimize the number of innocent
  2095.    nodes that simultaneously received discovery messages really intended
  2096.    for someone else.
  2097.  
  2098.    However, in connection oriented NBMA environments it becomes equally
  2099.    (or more) important to minimize the number of independent VCs that a
  2100.    given NBMA interface is required to originate or terminate. If we
  2101.    treat the MARS service as a 'black box' the sparse Solicited Node
  2102.    address space can lead to a large number of short-use, but longer
  2103.    lived, pt-mpt VCs (generated whenever the node is transmitting
  2104.    Neighbor Solicitations). Even more annoying, these VCs are only
  2105.    useful for additional packets being sent to their associated
  2106.    Solicited Node multicast address.  A new pt-pt VC is required to
  2107.    actually carry the unicast IPv6 traffic that prompted the Neighbor
  2108.    Solicitation.
  2109.  
  2110.    The axis of inefficiency brought about by the sparse Solicited Nodes
  2111.    address space is orthogonal to the VC mesh vs Multicast Server
  2112.    tradeoff. Typically a multicast server aggregates traffic flow to a
  2113.    common multicast group onto a single VC. To reduce the VC consumption
  2114.    for ND, we need to aggregate across the Solicited Node address space
  2115.    - performing aggregation on the basis of a packet's function rather
  2116.    than its explicit IPv6 destination.  The trade-off here is that the
  2117.    aggregation removes the original value of scattering nodes sparsely
  2118.    across the Solicited Nodes space. This is a price of the mismatch
  2119.    between ND and connection oriented networks.
  2120.  
  2121. B.2 MARS as a Link (Multicast) Server.
  2122.  
  2123.    One possible aggregation mechanism is for every node's IPv6/NBMA
  2124.    driver to trap multicast ICMPv6 packets carrying multicast ND or RD
  2125.    messages, and logically remap their destinations to the All Nodes
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Armitage, et. al.           Standards Track                    [Page 38]
  2131.  
  2132. RFC 2491                IPv6 over NBMA networks             January 1999
  2133.  
  2134.  
  2135.    group (link local scope). By ensuring that the All Nodes group is
  2136.    supported by an MCS, the resultant VC load within the LL will be
  2137.    significantly reduced.
  2138.  
  2139.    A further optimization is for every node's IPv6/NBMA driver to trap
  2140.    multicast ICMPv6 packets carrying multicast ND or RD messages, and
  2141.    send them to the MARS itself for retransmission on ClusterControlVC
  2142.    (involving a trivial extension to the MARS itself.) This approach
  2143.    recognizes that in any LL where IPv6 multicasting is supported:
  2144.  
  2145.       - Nodes already have a pt-pt VC to their MARS.
  2146.  
  2147.       - The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster
  2148.         members (LL members registered for multicast support).
  2149.  
  2150.    Because the VCs between a MARS and its MARS clients carry LLC/SNAP
  2151.    encapsulated packets, ICMP packets can be multiplexed along with
  2152.    normal MARS control messages. In essence the MARS behaves as a
  2153.    multicast server for non-MARS packets that it receives from around
  2154.    the LL.
  2155.  
  2156.    As there is no requirement that a MARS client accepts only MARS
  2157.    control messages on ClusterControlVC, ICMP packets received in this
  2158.    fashion may be passed to every node's IP layer without further
  2159.    comment.  Within the IP layer, filtering will occur based on the
  2160.    packet's actual destination IP address, and only the targeted node
  2161.    will end up responding.
  2162.  
  2163.    Regrettably this approach does result in the entire Cluster's
  2164.    membership having to receive a variety of ICMPv6 messages that they
  2165.    will always throw away.
  2166.  
  2167.  
  2168.  
  2169.  
  2170.  
  2171.  
  2172.  
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Armitage, et. al.           Standards Track                    [Page 39]
  2187.  
  2188. RFC 2491                IPv6 over NBMA networks             January 1999
  2189.  
  2190.  
  2191. Appendix C. Flow detection
  2192.  
  2193.    The relationship between IPv6 packet flows, Quality of Service
  2194.    guarantees, and optimal use of underlying IP and NBMA network
  2195.    resources are still subjects of ongoing research in the IETF
  2196.    (specifically the ISSLL, RSVP, IPNG, and ION working groups). This
  2197.    document currently only describes the use of flow detection as a
  2198.    means to optimize the use of NBMA network resources through the
  2199.    establishment of inter-LL shortcuts.
  2200.  
  2201. C.1. The use of non-zero FlowID to suppress flow detection
  2202.  
  2203.    For the purposes of this IPv6/NBMA architecture, a flow is:
  2204.  
  2205.       A related sequence of IPv6 packets that the first hop router is
  2206.       allowed to perform flow-detection on for the purposes of
  2207.       triggering shortcut discovery.
  2208.  
  2209.    How these packets are considered to be related to each other (e.g.
  2210.    through common header fields such as IPv6 destination addresses) is a
  2211.    local configuration issue.
  2212.  
  2213.    The flow-detection rule specifies that only packets with a zero
  2214.    FlowID can be considered as flows for which shortcut discovery may be
  2215.    triggered. The rationale behind this decision is:
  2216.  
  2217.       NBMA shortcuts are for the benefit of 'the network' optimizing its
  2218.       forwarding of IPv6 packets in the absence of any other guidance
  2219.       from the host.
  2220.  
  2221.       It is desirable for an IPv6/NBMA host to have some mechanism for
  2222.       overriding attempts by 'the network' to optimize its internal
  2223.       forwarding path.
  2224.  
  2225.       A zero FlowID has IPv6 semantics of "the source allows the network
  2226.       to utilize its own discretion in providing best-effort forwarding
  2227.       service for packets with zero FlowID"
  2228.  
  2229.       The IPv6 semantics of zero FlowID are consistent with the flow-
  2230.       detection rule in this document of "if the FlowID is zero, we are
  2231.       free to optimize the forwarding path using shortcuts"
  2232.  
  2233.       A non-zero FlowID has IPv6 semantics of "the source has previously
  2234.       established some preferred, end to end hop by hop forwarding
  2235.       behaviour for packets with this FlowID"
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Armitage, et. al.           Standards Track                    [Page 40]
  2243.  
  2244. RFC 2491                IPv6 over NBMA networks             January 1999
  2245.  
  2246.  
  2247.       The IPv6 semantics of non-zero FlowID are consistent with the
  2248.       flow-detection rule in this document of "if the FlowID is non-
  2249.       zero, do not attempt to impose a shortcut".
  2250.  
  2251.    A non-zero FlowID might be assigned by the source host after
  2252.    negotiating a preferred forwarding mechanism with 'the network' (e.g.
  2253.    through dynamic means such as RSVP, or administrative means).
  2254.    Alternatively it can simply be assigned randomly by the source host,
  2255.    and the network will provide default best effort forwarding (an IPv6
  2256.    router defaults to providing best-effort forwarding for packets whose
  2257.    FlowID/source-address pair is not recognized).
  2258.  
  2259.    Thus, the modes of operation supported by this document becomes:
  2260.  
  2261.       Zero FlowID
  2262.         Best effort forwarding, with optional shortcut discovery
  2263.         triggered through flow-detection.
  2264.  
  2265.       Non-zero FlowID
  2266.         Best effort forwarding if the routers along the path have not
  2267.         been otherwise configured with alternative processing rules for
  2268.         this FlowID/source-address pair. Flow detection relating to
  2269.         shortcut discovery is suspended.
  2270.  
  2271.         If the routers along the path have been configured with
  2272.         particular processing rules for this FlowID/source-address pair,
  2273.         the flow is handled according to those rules. Flow detection
  2274.         relating to shortcut discovery is suspended.
  2275.  
  2276.    Mechanisms for establishing particular per-hop processing rules for
  2277.    packets with non-zero FlowID are neither constrained by, nor implied
  2278.    by, this document.
  2279.  
  2280. C.2. Future directions for Flow Detection
  2281.  
  2282.    In the future, accurate mapping of IPv6 flows onto NBMA VCs may
  2283.    require more information to be exchanged during the Neighbor
  2284.    Discovery process than is currently available in Neighbor Discovery
  2285.    packets. In these cases, the IPv6 Neighbor Discover protocols can be
  2286.    extended to include new TLV options (see section 4.6 of RFC 1970
  2287.    [7]). However, if new options are required, the specification of
  2288.    these options must be co-ordinated with the IPNG working group.
  2289.    Since RFC 1970 specifies that nodes must silently ignore options they
  2290.    do not understand, new options can be added at any time without
  2291.    breaking backward compatibility with existing implementations.
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Armitage, et. al.           Standards Track                    [Page 41]
  2299.  
  2300. RFC 2491                IPv6 over NBMA networks             January 1999
  2301.  
  2302.  
  2303.    NHRP also provides mechanisms for adding optional TLVs to NHRP
  2304.    Requests and NHRP Replies. Future developments of this document's
  2305.    architecture will require consistent QoS extensions to both ND and
  2306.    NHRP in order to ensure they are semantically equivalent (syntactic
  2307.    differences are undesirable, but can be tolerated).
  2308.  
  2309.    Support for QoS on IPv6 unicast flows will not require further
  2310.    extensions to the existing MARS protocol. However, future support for
  2311.    QoS on IPv6 multicast flows may require extensions. MARS control
  2312.    messages share the same TLV extension mechanism as NHRP, allowing QoS
  2313.    extensions to be developed as needed.
  2314.  
  2315. Appendix D. Shortcut Limit Option
  2316.  
  2317.    For NS messages sent as a shortcut trigger, a new type of ND option
  2318.    is needed to pass on the information about the data flow hop limit
  2319.    from the host to the router. The use of this ND option is defined in
  2320.    section 3.2.2 of this specification. Its binary representation
  2321.    follows the rules of section 4.6 of RFC 1970:
  2322.  
  2323.         0                   1                   2                   3
  2324.         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
  2325.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2326.         |     Type      |    Length     | Shortcut Limit|   Reserved1   |
  2327.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2328.         |                           Reserved2                           |
  2329.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2330.  
  2331.    Fields:
  2332.  
  2333.  
  2334.          Type            6
  2335.  
  2336.          Length          1
  2337.  
  2338.          Shortcut Limit  8-bit unsigned integer. Hop limit for shortcut
  2339.                          attempt.
  2340.  
  2341.          Reserved1       This field is unused. It MUST be initialized to
  2342.                          zero by the sender and MUST be ignored by the
  2343.                          receiver.
  2344.  
  2345.          Reserved2       This field is unused. It MUST be initialized to
  2346.                          zero by the sender and MUST be ignored by the
  2347.                          receiver.
  2348.  
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Armitage, et. al.           Standards Track                    [Page 42]
  2355.  
  2356. RFC 2491                IPv6 over NBMA networks             January 1999
  2357.  
  2358.  
  2359.       Description
  2360.  
  2361.          The shortcut limit option is used by a host in a Neighbor
  2362.          Solicitation message sent as a shortcut trigger to a default
  2363.          router. It restricts the router's shortcut query to targets
  2364.          reachable via the specified number of hops. The shortcut limit is
  2365.          given relative to the host requesting the shortcut. NS messages
  2366.          with shortcut limit values of 0 or 1 MUST be silently ignored.
  2367.  
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.  
  2381.  
  2382.  
  2383.  
  2384.  
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Armitage, et. al.           Standards Track                    [Page 43]
  2411.  
  2412. RFC 2491                IPv6 over NBMA networks             January 1999
  2413.  
  2414.  
  2415. Full Copyright Statement
  2416.  
  2417.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  2418.  
  2419.    This document and translations of it may be copied and furnished to
  2420.    others, and derivative works that comment on or otherwise explain it
  2421.    or assist in its implementation may be prepared, copied, published
  2422.    and distributed, in whole or in part, without restriction of any
  2423.    kind, provided that the above copyright notice and this paragraph are
  2424.    included on all such copies and derivative works.  However, this
  2425.    document itself may not be modified in any way, such as by removing
  2426.    the copyright notice or references to the Internet Society or other
  2427.    Internet organizations, except as needed for the purpose of
  2428.    developing Internet standards in which case the procedures for
  2429.    copyrights defined in the Internet Standards process must be
  2430.    followed, or as required to translate it into languages other than
  2431.    English.
  2432.  
  2433.    The limited permissions granted above are perpetual and will not be
  2434.    revoked by the Internet Society or its successors or assigns.
  2435.  
  2436.    This document and the information contained herein is provided on an
  2437.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  2438.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  2439.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  2440.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  2441.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2442.  
  2443.  
  2444.  
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Armitage, et. al.           Standards Track                    [Page 44]
  2467.  
  2468.