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