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