Internet-Draft Grenville Armitage Lucent Technologies Peter Schulter BrightTiger Technologies Markus Jork, Geraldine Harter Digital July 22nd, 1997 Transient Neighbors for IPv6 over ATM Status of this Memo This document was submitted to the IETF Internetworking over NBMA (ION) WG. Publication of this document does not imply acceptance by the ION WG of any ideas expressed within. Comments should be submitted to the ion@nexen.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the "lid-abstracts.txt" listing contained in the Internet-Drafts shadow directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes an architecture and protocols for IPv6 over ATM. It allows conventional host-side operation of the Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths. This is achieved through the use of Redirects to create Transient Neighbors, standard IPv6 protocol operation within the IPv6 Logical Link, and inter-router NHRP for location of off-Link destinations. Shortcuts are discovered by egress routers when triggered either by detection of suitable packet flows, or source host initiation. NHRP is used to locate a better link level first hop, and the result is announced to the source host using a Neighbor Discovery Redirect message. Armitage, et al. Expires January 22nd, 1998 [Page 1] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 Revision History June 1997, version 01 as an official ION working group work item. Host tokens now generated to look like EUI-64 addresses. Updated "on-link" definitions to match current ND spec. March 1997, version 00 (again) as an official ION working group work item. Augmented MARS now required, add SVC signalling procedures, host token, and other issues raised at December 1996 IETF and on the ION mailing list. Name changed to draft- ietf-ion-tn-00.txt. October 1996, version 01 under ION working group. Significantly expanded description of IPv6 Neighbor Discovery, DHCPv6, IGMPv6 protocol operation (based on IPv6 specific material from draft-ietf-ion-ipv6atm-framework-00.txt). New authors added. June 1996, version 00 (again) Reissued under the ION working group. No substantive changes. Prelude to June 1996 IETF. Name changed to draft-armitage- ion-tn-00.txt April 1996, version 00 under IP-ATM working group. Documents and expands on an informal presentation at the March 1996 IETF. 1. Introduction. The IPv4 world evolved an approach to address resolution that focussed on 'link layer' level protocol operation. ATMARP [3], and more currently NHRP [8], are the consequences of this model when applied to the IP over ATM world. IPv6 developers opted to migrate away from a link layer specific approach, chosing to combine a number of tasks into a protocol known as Neighbor Discovery [7], intended to be non-specific across a number of link layer technologies. A key assumption made by Neighbor Discovery's actual protocol is that the link technology underlying a given IP interface is capable of native multicasting. This is not particularly true of ATM interfaces (a point that lead to the development of the MARS protocol, RFC 2022 [5]). The IP/ATM community also considers it important to show how Neighbor Discovery can be applied to the location of 'shortcut' routes (where IP routing boundaries are 'shortcut' if they are found to be merely logical boundaries between nodes attached to the same physical link network). This document synthesizes a general solution of IPv6 and IPv6 ND over ATM that supports shortcut routing without requiring large scale Armitage, et al. Expires January 22nd, 1998 [Page 2] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 multicasting of ND messages around an ATM network. The salient components are: - The IPv6 Neighbor model, where neighbors are discovered through the use of messages multicast to members of an IP interface's local Logical Link. - The MARS model, allowing emulation of general multicast using multicast servers and point to multipoint calls provided by the underlying link network. - The NHRP service for seeking out the link layer identities of IP interfaces who are logically distant in an IP topological sense. - The modeling of IP traffic as 'flows', and using the existence of a flow as the basis for attempting to set up a shortcut link level connection. In summary, this document proposes that: The IPv6 "Link" is generalised to "Logical Link" (LL) in ATM environments, analogous to the generalisation of IPv4 IP Subnet to Logical IP Subnet (LIS) in RFC1577. IPv6 over ATM interfaces utilize RFC 2022 (MARS) for general intra-link multicasting, and use the MARS itself to distribute discovery messages within the Logical Link in an optimal fashion. For destinations not currently considered to be Neighbors (initially this will include just about any destination not in the Logical Link), a host sends the packets to its default router. The egress router from a Logical Link is responsible for detecting the existence of an IP packet flow through it that might benefit from a shortcut connection. While continuing to conventionally forward the flow's packets, the router initiates an NHRP query for the flow's destination IP address. The last router/NHS before the target of the NHRP query ascertains the target interface's preferred ATM address. The originally querying router then issues a Redirect to the IP source, identifying the flow's destination as a transient Neighbor. Host-initiated triggering of shortcut discovery, regardless of the existence of a packet flow, is also supported through specific Neighbor Solicitations sent to a source host's default router. A number of key advantages are claimed for this approach. These are: The IPv6 stacks on hosts do not implement separate ND protocols for each link layer technology. When the destination of a flow is solicited as a transient Armitage, et al. Expires January 22nd, 1998 [Page 3] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 neighbor, the returned ATM address will be the one chosen by the destination when the flow was originally established through hop- by-hop processing. This supports the existing ND ability for destinations to perform their own dynamic interface load sharing. 2. Logical Links, and Transient Neighbors. IPv6 contains a concept of on-link and off-link. Neighbors are those nodes that are considered on-link and whose link-layer addresses may therefore be located using Neighbor Discovery. Borrowing from the terminology definitions in the ND text: on-link - an address that is assigned to a neighbor's interface on a shared link. A host considers an address to be on-link if: - it is covered by one of the link's prefixes, or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the target address, or - a Neighbor Discovery message is received from the address. off-link - the opposite of "on-link"; an address that is not assigned to any interfaces attached to a shared link. Off-link nodes are considered to only be accessible through one of the routers directly attached to the link. The ATM environment complicates the sense of the word 'link' in much the same way as it complicated the sense of 'subnet' in the IPv4 case. For IPv4 this required the definition of the Logical IP Subnet (LIS) - an administratively constructed set of hosts that would share the same routing prefixes (network and subnetwork masks). This document considers the IPv6 analog to be a Logical Link (LL). An LL consists of nodes administratively configured to be 'on link' with respect to each other. The members of an LL are an IPv6 interface's initial set of neighbors, and each interface's Link Local address only needs to be unique amongst this set. It should be noted that whilst members of an LL are IPv6 Neighbors, it is possible for Neighbors to exist that are not, administratively, members of the same LL. Neighbor Discovery events can result in the expansion of an IPv6 interface's set of Neighbors. However, this does not change the set of interfaces that make up its LL. This leads to three possible relationships between any two IPv6 interfaces: Armitage, et al. Expires January 22nd, 1998 [Page 4] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 - On LL, Neighbor. - Off LL, Neighbor. - Off LL, not Neighbor. Off LL Neighbors represent the 'shortcut' connections, where it has been ascertained that direct connectivity at the ATM level is possible to a target that is not a member of the source's LL. Neighbors discovered through the operation of unsolicited messages, such as Redirects, are termed 'Transient Neighbors'. 3. Intra-LL and Inter-LL Discovery. This document makes a distinction between the discovery of neighbors within a Logical Link (intra-LL) and neighbors beyond the LL (inter- LL). The goal is to allow both inter- and intra-LL neighbor discovery to involve no changes to the host-side IPv6 stack for ATM. 3.1 Intra-LL - ND over emulated multicast. The basic model of ND assumes that a link layer interface will do something meaningful with an ICMPv6 packet sent to a multicast IP destination address. (IPv6 assumes that multicasting is an integral part of the Internet service.) This document assumes multicast support will be provided using the RFC 2022 (MARS) [5] service. In the same way as an IPv4 LIS is considered to map directly onto an IPv4 MARS Cluster, an IPv6 LL maps directly onto an IPv6 MARS Cluster. The goal of intra-LL operation is that the IPv6 layer must be able to simply pass multicast ICMPv6 packets down to the IPv6/ATM driver without any special, ATM specific processing. The underlying mechanism for distributing Neighbor Discovery and Router Discovery messages then works as expected. Sections 3.1.1 and 3.1.2 are informational, and describe the limitations of various mechanisms below the IPv6 layer for distributing ND and RD messages. Section 3.1.3 describes the additional functionality that SHALL be required of any MARS used in conformance with this document. 3.1.1 Simplistic approach - Use MARS 'as is'. The IPv6/ATM driver utilizes the standard MARS protocol to establish a VC forwarding path out of the interface on which it can transmit all multicast IPv6 packets, including ICMPv6 packets. The IPv6 packets are then transmitted, and received by the intended destination set, using separate pt-mpt VCs per destination group. In this approach all the protocol elements in [5] are used 'as is'. However, VC resource consumption must be taken into consideration. Unfortunately, ND assumes that link level multicast resources are best conserved by generating a sparsely distributed set of Solicited Armitage, et al. Expires January 22nd, 1998 [Page 5] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 Node multicast addresses (to which discovery queries are initially sent). The original goal was to minimize the number of innocent nodes that simultaneously received discovery messages really intended for someone else. However, in an ATM environment it becomes equally (or more) important to minimize the number of independent VCs that a given ATM interface is required to originate or terminate. If we treat the MARS service as a 'black box' the sparse Solicited Node address space can lead to a large number of short-use, but longer lived, pt-mpt VCs (generated whenever the node is transmitting Neighbor Solicitations). Even more annoying, these VCs are only useful for additional packets being sent to their associated Solicited Node multicast address. A new pt-pt VC is required to actually carry the unicast IPv6 traffic that prompted the Neighbor Solicitation. The axis of inefficiency brought about by the sparse Solicited Nodes address space is orthogonal to the VC mesh vs Multicast Server tradeoff. Typically a multicast server aggregates traffic flow to a common multicast group onto a single VC. To reduce the VC consumption for ND, we need to aggregate across the Solicited Node address space - performing aggregation on the basis of a packet's function rather than its explicit IPv6 destination. The trade-off here is that the aggregation removes the original value of scattering nodes sparsely across the Solicited Nodes space. This is a price of the mismatch between ND and connection oriented networks. 3.1.2 MARS as a Link (Multicast) Server. One possible aggregation mechanism is for every node's IPv6/ATM driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and logically remap their destinations to the All Nodes group (link local scope). By ensuring that the All Nodes group is supported by an MCS, the resultant VC load within the LL will be significantly reduced. A further optimization is for every node's IPv6/ATM driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and send them to the MARS itself for retransmission on ClusterControlVC (involving a trivial extension to the MARS itself.) This approach recognizes that in any LL where IPv6 multicasting is supported: - Nodes already have a pt-pt VC to their MARS. - The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster members (LL members registered for multicast support). Because the VCs between a MARS and its MARS clients carry LLC/SNAP encapsulated packets we can multiplex ICMP packets in addition to the original MARS control messages. In essence the MARS behaves as a multicast server for non-MARS packets that it receives from around the LL. As there is no requirement that a MARS client only accepts MARS Armitage, et al. Expires January 22nd, 1998 [Page 6] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 messages on ClusterControlVC, ICMP messages received in this fashion may be passed to every node's IP layer without further comment. Within the IP layer, filtering will occur based on the packet's actual destination IP address, and only the targeted node will end up responding. Regrettably this approach does result in the entire Cluster's membership having to receive a variety of ICMPv6 messages that they will always throw away. 3.1.3 Mandatory augmented MARS behavior. To minimise unwanted traffic delivery across ClusterControlVC, the following augmention to MARS functionality SHALL be employed for conformance with this document: - Clients register with the MARS as members of their Solicited Nodes multicast group. - When the MARS receives a data packet (identified by its LLC/SNAP encapsulation), it scans the group membership database to find the ATM addresses of the destination group's members. - The MARS then checks to see if every group member currently has its pt-pt control VC open to the MARS. If so, the MARS sends a copy of the data packet directly to each group member over the existing pt-pt VCs. - If one or more of the discovered group members do not have an open pt-pt VC to the MARS, or if there are no group members listed, the packet is sent out ClusterControlVC instead. No copies of the packet are sent over the existing (if any) pt-pt VCs. Section 4.4.2 describes the matching client-side behavior. 3.2 Inter-LL - Redirects, and their generation. The key to creating transient neighbors is the Redirect message (section 8 [7]). IPv6 allows a router to inform the members of an LL that there is a better 'first hop' to a given destination (section 8.2 [7]). The advertisement itself is achieved through a Router Redirect message, which may carry the link layer address of this better hop. A transmitting host only listens to Router Redirects from the router that is currently acting as the default router for the IP destination that the Redirect refers to. If a Redirect arrives that indicates a better first hop for a given destination, and supplies a link layer (ATM) address to use as the better first hop, the associated Neighbor Cache entry in the source host is updated and its reachability set to STALE. Updating the cache in this context involves building a new VC to the new ATM address. If this is successful, the old VC is torn down only if it no longer required (as this VC was to the router, it Armitage, et al. Expires January 22nd, 1998 [Page 7] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 may still be required by other packets from the host that are heading to the router). The manner by which a router determines a better first-hop is not specified or constrained in [7]. This document defines such a mechanism. 3.2.1 Redirect Triggers. Support for shortcut connections is justified on the grounds that demanding flows of IP packets may exist between source/destination pairs that are separated by IP routing boundaries. NHRP [8] is built on the premise that the source itself decides to seek a shortcut connection. The Cell Switch Router [11] and the IP Switch [12] models place the detection and management of IP packet flows into the routers (where flows cross the edges of IP routing boundaries). This document provides two mechanisms for triggering the discovery of a better first hop: Router-based flow identification/detection. Host-initiated shortcut request The host initiated trigger is discussed further in section 3.2.3. A router SHALL only track flows that originate from a directly attached host (a host that is within the LL-local scope of one of the router's interfaces). IP packets arriving from another router are never used to trigger the generation of a Router Redirect. The actual algorithm(s) for determining when a flow should trigger an attempt to resolve a better first hop are not defined in this document. 3.2.2 Use of NHRP between routers. Once flow detection has occurred, or a host trigger has been detected, routers SHALL use NHRP in an NHS to NHS mode to establish the IP to link level address mapping of a better first hop. The routers will perform the following functions: - Construct NHRP Requests and Replies. - Parse incoming NHRP Requests and Replies from other NHSes (routers). - Forward NHRP Requests towards an NHS that is topologically closer to the IPv6 target. - Forward NHRP Replies towards an NHS that is topologically closer to the requester. - Perform syntax translation between Neighbor Solicitations and Armitage, et al. Expires January 22nd, 1998 [Page 8] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 outbound NHRP Requests. - Perform syntax translation between inbound NHRP Replies and Neighbor Redirects or Neighbor Advertisements. The destination of the flow that caused the trigger (or the target of the host initiated trigger) is used as the target for resolution in a NHRP Request. The router then forwards this NHRP Request to the next closest NHS. The process continues (as it would for normal NHRP) until the Request reaches an NHS that believes the IP target is within link-local scope of one of its interfaces. (This may potentially occur within a single router.) The last hop router SHALL resolve the NHRP Request from mapping information contained in its neighbor cache for the interface on which the specified target is reachable. If there is no appropriate entry in the neighbor cache, or the destination is currently considered unreachable, the last hop router SHALL perform Neighbor Discovery on the local interface, and build the NHRP Reply from the resulting answer. (Note, in the case where the NHRP Request originated due to flow detection, there must already be a hop-by-hop flow of packets going through the last hop router towards the target. In this typical case the Neighbor cache will already have the desired information.) The NHRP Reply is propagated back to the source of the NHRP Request, using a hop-by-hop path as it would for normal NHRP. If the discovery process was triggered through flow detection at the originating router, the return of the NHRP Reply results in the following events: A Router Redirect is constructed using the IP/ATM mapping carried in the NHRP Reply. The Router Redirect is unicast to the IP packet flow's source (using the VC on which the flow is arriving at the router, if it is a pt-pt VC). (It is worth noting that the router constructing the NHRP Reply does so using the ATM address returned by the target host when the target host first accepted the flow of IP traffic. This retains a useful feature of ND - destination interface load sharing.) The behavior for host initiated shortcuts is covered in the next section. [The specific syntax translation rules between NHRP and ND messages are TBD.] 3.2.3 Host Triggered Redirection A source host may also want to trigger a redirection to a transient neighbor. To support host-triggered redirects, routers conforming to Armitage, et al. Expires January 22nd, 1998 [Page 9] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 this document SHALL recognize specific Neighbor Discovery messages sent by hosts to trigger resolutions of off-link addresses. To perform host-triggered redirects, a source host creates a Neighbor Solicitation message for the off-LL destination which is also destined to the off-LL target (rather than the off-LL target's solicited node multicast address). Because this NS packet is addressed to a unicast address, the sending host forwards it to the next hop router for traffic to the off-LL destination. A router SHALL consider a unicast NS to an off-LL address as a request for a host-triggered redirect. A suitable NHRP Request is constructed and sent as described in section 3.2.2. The original NS message is discarded. Once the NHRP Reply is received by the originating router, the router constructs a Neighbor Advertisement message containing the IPv6 address of the transient neighbor, the ATM datalink address returned by the NHRP resolution process, and the Overide bit set to 1. If the NHRP Reply returns the address of an egress router rather than of the destination node itself, then the Router bit MUST be set to 1 in the NA message and the egress router MUST behave as a proxy router as defined in [7]. When the soliciting node receives the NA message it will update its Neighbor and Destination caches. The next packet sent to the transient neighbor will create a direct VC to that neighbor (or to the best egress router towards that neighbor as determined by NHRP). 3.3. Neighbor Unreachability Detection. Neighbor Solicitations sent for the purposes of Neighbor Unreachability Detection (NUD) are unicast to the Neighbor in question, using the VC that is already open to that Neighbor. This suggests that as far as NUD is concerned, the Transient Neighbor is indistinguishable from an On-LL Neighbor. 3.4. Duplicate Address Detection. Duplicate Address Detection is only required within the link-local scope, which in this case is the LL-local scope. Transient Neighbors are outside the scope of the LL. No particular interaction is required between the mechanism for establishing shortcuts and the mechanism for detection of duplicate link local addresses. 4 Node Operation Concepts This section describes of node operations for performing basic functions (such as sending and receiving data) on an LL. The application of these basic functions to the operation of the various IPv6 protocols such as Neighbor Discovery is described in Appendix A. Armitage, et al. Expires January 22nd, 1998 [Page 10] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 4.1.Connecting to a LL Before a node can send or receive IPv6 datagrams it must first join a Logical Link. This is done by the node's MARS client establishing a pt-pt VC to the MARS and registering as a Cluster Member [5]. The MARS will then add the node's MARS client to ClusterControlVC. After this is done the node is a member of the LL, has been assigned a Cluster Member ID (CMI), and can begin supporting IPv6 and IPv6 ND operations. The encapsulation of MARS control messages (between MARS and MARS Clients) remains the same as shown in RFC 2022: [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message] (LLC) (OUI) (PID) Within actual MARS control messages: The mar$afn field in MARS messages remains 0x0F. The mar$pro field in MARS messages SHALL be 0x86DD. The mar$op.version field in MARS messages remains 0x00. The mar$spln and mar$tpln fields (where relevant) are either 0 (for null or non-existent information) or 16 (for the full IPv6 protocol address). When a host starts up it SHALL issue a single group MARS_JOIN for the following groups: - Its derived Solicited-node address(es) with link-local scope. - The All-nodes address with link-local scope. - Other configured multicast groups with at least link-local scope. When an IPv6/ATM router interface starts up, in addition to the operations required for a host, it SHALL issue: - A single group MARS_JOIN for the All-routers address with link- local scope. - A block MARS_JOIN for the range(s) of IPv6 multicast addresses (with greater than link-local scope) for which promiscuous reception is required. 4.2 Joining a Multicast Group This section describes the node's behavior when it gets a JoinLocalGroup request from the IPv6 Layer. The IPv6/ATM driver examines each group address to determine how the join request is to be handled. If a JoinLocalGroup for a node-local address is received then no Armitage, et al. Expires January 22nd, 1998 [Page 11] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 action is taken and the JoinLocalGroup function returns success to the caller. (Node-local addresses are not handled by the IPv6/ATM layer.) When the IPv6/ATM driver receives a request to join a non node-local multicast group, it sends an appropriate MARS_JOIN request to register its cluster-wide membership of the specified group. 4.3. Leaving a Multicast Group This section describes the node's behavior when it gets a LeaveLocalGroup request from the IPv6 Layer. The IPv6/ATM driver examines each group address to determine how the leave request is to be handled. If a LeaveLocalGroup for a node-local address is received then no action is taken and the LeaveLocalGroup function returns success to the caller. (Node-local addresses are not handled by the IPv6/ATM layer.) When the IPv6/ATM driver receives a request to leave a non node-local multicast group, it sends an appropriate MARS_LEAVE request to de- register its cluster-wide membership of the specified group. 4.4. Sending Data The processing of packets outbound from the local IPv6 layer depends on whether they have unicast or multicast destinations. 4.4.1. Sending Unicast Data When a node is given an IPv6 unicast packet to send, the node must map the next hop address to a PtP VC over which the packets are to be sent. (Minimally, the mapping may be based on the destination address, but may also include the flow label information to facilitate handling QoS based flows. How the flow labels are used is a topic still being discussed by the IPv6 community.) If a PtP VC for the next hop address exists, the packet SHALL be encapsulated in the following LLC/SNAP header, and sent over that VC. [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] If no PtP VC exists for the next hop address for the packet, then the node will have to place a call to set up a VC to the next hop destination. Any time the IPv6/ATM driver receives a unicast packet for transmission the IPv6 Network layer should already have performed Neighbor Discovery on the next hop to determine the link-layer address (e.g. ATM Address) of the next hop. Thus, the information needed to place the call to the next hop will already be available on the sending node. During call placement, the sending node will queue the packet that triggered the call request so that it can be sent when the circuit is Armitage, et al. Expires January 22nd, 1998 [Page 12] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 established. If the call to the next hop destination node fails the sending node will discard the packet that triggered the call setup. Persistent failure to create a VC to the next hop destination will be detected and handled at the IPv6 Network Layer through NUD. 4.4.2. Sending Multicast Data Multicast packets SHALL be transmitted using the following encapsulation: [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet] The driver's Cluster Member ID (CMI) is copied into the 2 octet pkt$cmi field prior to transmission. If the packet's destination is one of the following multicast addresses, it is sent over the MARS client's PtP VC to the MARS: - A Solicited-node address with link-local scope. - The All-nodes address with link-local scope. - The All-routers address with link-local scope. - A DHCP-v6 relay or server multicast address. The MARS will redistribute the IPv6 packet appropriately as described in section 3.1.3. (If the VC to the MARS has been idle timed out for some reason, it must be re-established before forwarding the packet to the MARS.) If packet's destination is any other address, then the usual MARS client mechanisms are used to select and/or establish a pt-mpt VC on which the packet is to be sent. 4.5. Receiving Data Packets received using the encapsulation shown in section 4.4.1 SHALL be de-encapsulated and passed up to the IPv6 layer. The IPv6 layer then determines how the incoming packet is to be handled. Packets received using the encapsulation shown in section 4.4.2 SHALL have their pkt$cmi field compared to the receiving client's CMI. If the pkt$cmi in the header matches the receiver's CMI the packet SHALL be silently dropped. Otherwise, the packet SHALL be de-encapsulated and passed to the IPv6 layer. The IPv6 layer then determines how the incoming packet is to be handled. 4.6. Unicast Data VC Setup and Release Unicast VCs are maintained separately from multicast VCs. Since the setup and maintenance of multicast VCs are handled by the MARS client on each IPv6 node, and this is described [5], only the setup and maintenance of unicast VCs will be described here. Currently, only Armitage, et al. Expires January 22nd, 1998 [Page 13] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 best effort unicast VCs are considered. The creation of VCs for other classes of service is outside the scope of this document. IPv4 over ATM mechanisms (RFC 1577 and NHRP) establish VCs from a sending node towards the receiving node (since until the address resolution mechanism provides the sender with a mapping, neither the sender nor the target node have the ability to set up a VC). IPv6 differs in that, in the most common situation, the receiving node will be the first to establish a direct ATM VC between itself and the nominal sender. This is a consequence of the Neighbor Solicitation/Advertisement exchange sequence. When one node in an LL has a packet to send to another node in the same LL it will first perform a Neighbor Discovery on the destination address. This is done to resolve the IPv6 destination address into a link-layer address which the sender can then use to send unicast packets. The Neighbor Discovery operation is performed by the sending node transmitting a Neighbor Solicitation packet to the appropriate solicited-node multicast address associated with the destination or next hop address for the outgoing packet. When the solicited node receives this packet it will respond with a Neighbor Advertisement packet which it will unicast to the soliciting node. Since the Neighbor Solicitation packet contains the data-link address of the soliciting node, the solicited node has all the information it requires to unicast the Neighbor Advertisement. Thus, since the solicited node is generally the first to send a unicast packet in any exchange between two nodes, it will be the one which will initiate the setup of the PtP VC between the two. The creation of a PtP VC is coupled with the Neighbor Discovery mechanism. Because IPv6 will not attempt to send a unicast data packet until it has completed the Neighbor Solicitation process and has a valid Neighbor cache entry for the next hop destination, there will be no need to try to create a PtP VC until IPv6 has resolved the next hop address to an ATM datalink address. Thus, if the IPv6/ATM driver receives a unicast packet for transmission, it can expect that the IPv6 layer will also provide the datalink address for the immediate destination (just as a MAC address is provided to Ethernet, for example). The IPv6/ATM driver can then use this information to either create a new VC, or to determine if there is already a suitable VC set up to the destination. Note that the datalink address supplied by IPv6 will be that of the next hop, which is not necessarily the same as that of the destination (e.g. the destination node is reachable only through a router). Creation of a new PtP VC as the result of a Redirect message (either a redirect to a node on the same LL, or a shortcut redirect to a node outside the LL) results in the sending (redirected) node creating a VC to a new receiving node. The redirected node does not know, or care if the new node to which it has been redirected is on it's LL or not since it has all the information necessary to set up the new PtP VC in the redirect message (this includes the link-layer address option). Since no further Neighbor Discovery operations are required after a redirect, the target does not need to be on the LL, but does Armitage, et al. Expires January 22nd, 1998 [Page 14] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 need to be reachable at the link layer (in fact, the target of the redirect may be an egress router, or a router closer to the destination). When redirected, the sending node will set up a PtP VC to the new node if one does not previously exist. The redirected node will then use the new VC to send data rather than whatever VC it had previously been using. Redirects are unidirectional. That is, the redirected node will create a new PtP VC over which it will send data previously sent on another VC (sending data to a different router for example), but the destination node will continue to send data back to the redirected node on the old path. This happens because the destination node has no way of determining the IPv6 address of the other end of a new VC in the absence of Neighbor Discovery. Thus, redirects will not result in both ends of a connection using the new VC. The non-redirected node will continue to send data to the redirected node over the old path. This is consistent with the way IPv6 redirects operate, in that they are not intended to provide symetrical redirection. If the non-redirected node eventually receives a redirect it should discover the existing VC to the target node and use that rather than creating a new VC. Once a PtP VC is established it is desirable that it be released when no longer needed to save both node and network resources. The simplest option would be to release the VC after some period of inactivity. Another would be to tie the VC to the IPv6 Destination or Neighbor cache entries so that the VC was released as the result of a state change in the caches. [This is TBD, and requires discussion in the WG and on the mailing list.] 4.7 UNI 3.0/3.1 SVC Signalling Support When an IPv6 node places a call to another IPv6 node, it should follow the procedures in [13] and [14] for signalling UNI 3.0/3.1 SVCs and negotiating MTU. The default MTU size on a LL is 9188 bytes as specified in [14]. Because of the nature of both IPv6 and transient neighbor discovery, the IPv6/ATM driver will not know if the called party is on the calling node's LL. The calling party cannot assume that called party will have the same default MTU as its LL. Thus, an appropriate MTU MUST be negotiated for each call placed using the procedures described in [14]. Note that while the procedures in [14] still apply to IPv6 over ATM, IPv6 Path MTU Discovery [15] is used by nodes and routers rather than IPv4 MTU discovery. Additionally, while IPv6 nodes are not required to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it. Also, since IPv6 nodes will negotiate an appropriate MTU for each VC, Path MTU should never be triggered since neither node should ever receive a Packet Too Big message to trigger Path MTU Discovery. When nodes are communicating via one or more routers Path MTU Discovery will be used just as it is for legacy networks. Armitage, et al. Expires January 22nd, 1998 [Page 15] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 5. Interface Tokens, Link Layer Address Options, Link-Local Addresses 5.1 Interface Tokens Each IPv6 interface must have a interface token which is used to form IPv6 autoconfigured addresses. This interface token must be unique within a Logical Link to prevent the creation of duplicate addresses when stateless address configuration is used. In cases where two nodes on the same LL produce the same interface token then one interface MUST choose another host-token. All implementations MUST support manual configuration of interface tokens to allow operators to manually change a interface token on a per-LL basis. Operators may choose to manually set interface tokens for reasons other than eliminating duplicate addresses. All interface tokens MUST be 64 bits in length and formatted as described in the following sections. The hosts tokens will be based on the format of an EUI-64 identifier [10]. For IPv6 use, the semantics of the EUI-64 Global/Local indicator bit has been inverted. (A universally administered EUI-64 is signified by a Global/Local indicator bit value of 0, while a globally unique IPv6 interface token is signified by a 1 in the corresponding position.) 5.1.1 Interface Tokens Based on MAC or ESI values When the underlying ATM interface is identified by an ATM End System Address (AESA, formerly known as an NSAPA), the interface token will be formed from the ESI and SEL values in the AESA as follows: [0x00][ESI][SEL] [0x00] is a one octet field which is always set to 0. Note that the bit corresponding to the EUI-64 Global/Local bit is always reset indicating that this address is not a globally unique IPv6 interface token. [ESI] is a six octet field. This field always contains the six octet ESI value for the AESA used to address the specific instance of the IPv6/ATM interface. [SEL] is a one octet field. This field always contains the SEL value from the AESA used to address the specific instance of the IPv6/ATM interface. 5.1.2 Interface Tokens Based on EUI-64 Values Where the underlying ATM NIC driver has access to a set of one or more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64 addresses configured into the NIC's ROM), the IPv6/ATM interface Armitage, et al. Expires January 22nd, 1998 [Page 16] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 SHOULD use one of these values to create a unique interface token. after inverting the Global/Local identifier bit. (Any relationship between these values and the ESI(s) registered with the local ATM switch by the ATM driver are outside the scope of this document.) When EUI-64 values are used for IPv6 interface tokens the only modification allowed to the octet string read from the NIC is inversion of the Global/Local identifier bit. 5.1.3 Interface Tokens Based on Native E.164 Addresses When an interface uses Native E.164 addresses then the E.164 values will be used to generate an interface token as follows: [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0] [D14] A single octet containing the semi-octet representing the most significant E.164 digit shifted left four bits to the most significant four bits of the octet. The lower four bits MUST be set to 0. Note that the EUI-64 Global/Local indicator is set to 0 indicating that this is not a globally unique IPv6 interface token. [D13D12] A single octet containing the semi-octet representing the second most significant E.164 digit [D13] shifted left four places to the most significant bits of the octet, and the third most significant semi-octet in the four least significant bits of the octet. [D11D10] - [D1D0] Octets each containing two E.164 digits, one in the most significant four bits, and one in the least significant four bits as indicated. 5.1.4 Multiple Logical Links on a Single Interface Physical ATM interfaces are commonly used to provide multiple logical ATM interfaces. Each logical ATM interface might be associated with a different SEL field of a common AESA prefix, or a set of entirely separate ESIs might have been registered with the local ATM switch to create a range of unique AESAs. In either case, the minimum information required to uniquely identify each logical ATM interface is (within the context of the local switch port) their ESI+SEL combination. Since each logical ATM interface can support an independent IPv6 interface, two separate scenarios are possible: - A single host with IPv6/ATM interfaces onto a number of independent Logical Links. - A set of 2 or more 'virtual hosts' (vhosts) might share a common ATM NIC and driver. Each vhost is free to establish IPv6/ATM interfaces associated with different or common LLs. However, vhosts are bound by the same requirement as normal hosts - no two interfaces to the same LL can share the same interface Armitage, et al. Expires January 22nd, 1998 [Page 17] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 token. In the first scenario, since each IPv6/ATM interface is associated with a different LL, each interface's external identity can be differentiated by the LL prefix. Thus, the host can re-use a single unique interface token across all such IPv6/ATM interfaces. This token SHALL be constructed using the rules in section 5.1.1 (ignoring the possible variations in SEL). (Internally the host will tag received packets in some locally specific manner to identify what IPv6/ATM interface they arrived on. However, this is an issue generic to all IPv6 interfaces, and does not required definition in this document.) The second scenario is more complex, but likely to be rarer. For the purpose of conformance with this document, each vhost SHALL select a different interface token from the range of 64 bit values available to the ATM NIC (as described in 5.1.1). Each vhost SHALL implement IPv6/ATM interfaces in such a way that no two or more vhosts end up advertising the same interface token onto the same LL. (Conformance with this requirement may be achieved by choosing different SEL values, ESI values, or both.) 5.2 Link Layer Address Options Neighbor Discovery defines two options for carrying link-layer specific source and target addresses. In this case these options must carry full ATM addresses. The source and target link-layer address options must carry any one of the three possibilities, and indicate which one it is. The format for these two options when in an ATM environment is adapted from the MARS [5] and NHRP [8] specs, and SHALL be: [Type][Length][NTL][STL][..ATM Number..][..ATM Subaddress..] | Fixed || Link layer address | [Type] is a one octet field. 1 for Source link-layer address. 2 for Target link-layer address. [Length] is a one octet field. The total length of the option in multiples of 8 octets. Zeroed bytes are added to the end of the option to ensure its length is a multiple of 8 octets. (For example, a single ATM address in AESA format would result in 24 bytes of real data, require no padding, and result in [Length] being set to 3.) [NTL] is a one octet 'Number Type & Length' field. Defines the type and length of the ATM number immediately following the [STL] field. The format is as follows: Armitage, et al. Expires January 22nd, 1998 [Page 18] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |0|x| length | +-+-+-+-+-+-+-+-+ The most significant bit is reserved and MUST be set to zero. The second most significant bit (x) is a flag indicating whether the ATM number is in: ATM Forum AESA format (x = 0). Native E.164 format (x = 1). The bottom 6 bits is an unsigned integer value indicating the length of the associated ATM address in octets. The [STL] is a one octet 'Subaddress Type & Length' field. Format is the same as the [NTL] field. Defines the length of the subaddress field, if it exists. If it does not exist this entire octet field MUST be zero. If the subaddress exists it will be in AESA format, so flag x SHALL be zero. [ATM Number] is a variable length field. It is always present. [ATM Subaddress] is a variable length field. It may or may not be present. When it is not, the option ends after the [ATM Number] (or any additional padding for 8 byte alignment). 5.3 Link-Local Addresses The IPv6 link-local address is formed by appending the interface token, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Token | +----------+-----------------------+----------------------------+ 6. Flow Detection The relationship between IPv6 packet flows, Quality of Service guarantees, and optimal use of underlying IP and ATM network resources are still subjects of ongoing research in the IETF (specifically the ISSLL, RSVP, IPNG, and ION working groups). This document currently only describes the use of flow detection as a means to optimize the use of ATM network resources through the establishment of inter-LL shortcuts. The definition of what constitutes a 'flow' is outside the scope of this document. In the future, accurate mapping of IPv6 flows onto ATM level VCs may require more information to be exchanged during the Neighbor Discovery process than is currently available in Neighbor Discovery packets. In these cases, the IPv6 Neighbor Discover protocols can be Armitage, et al. Expires January 22nd, 1998 [Page 19] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 extended to include new TLV options (see section 4.6 of RFC 1790 [7]). However, if new options are required, the specification of these options must be co-ordinated with the IPNG working group. Since RFC 1790 specifies that nodes must silently ignore options they do not understand, new options can be added at any time without breaking backward compatability with existing implementations. NHRP also provides mechanisms for adding optional TLVs to NHRP Requests and NHRP Replies. Future developments of this document's IPv6/ATM architecture will require consistent QoS extensions to both ND and NHRP in order to ensure they are semantically equivalent (syntactic differences are also undesirable, but can be tolerated). 7. Conclusion and Open Issues. This document provides an architecture and protocols for supporting IPv6 over ATM. The proposed solution requires no ATM-specific changes to the Neighbor Discovery and Router Discovery protocols within hosts (or routers if a shortcut mechanism is not implemented). No special protocol is required at all in the hosts to support the use of ATM level shortcuts. Some extensions to the functionality of a MARS are required to minimize the VC resource cost associated with distributing Discovery messages around a Logical Link. Router- identified IP flows or host indications trigger the discovery of shortcut paths. It is noted that the IPv6 Router Redirect message is designed to support the advertisement of new Neighbors in NBMA environments, and uses the Redirect message in exactly that role. Router to router NHRP is used to support the discovery of shortcut routes to Transient Neighbors. There are a number of open issues, both in general and specific senses: - Need to clarify further the conditions under which sources may ignore a Redirect. - Need to specify more clearly how a shortcut route may be invalidated or purged. - More detailed text is required to provide the specific syntax mapping between Neighbor Discovery messages and NHRP Request/Reply packets. As with all open issues, contributions to the ION mailing list are solicited (ion@nexen.com). 8. Security Consideration While this proposal does not introduce any new security mechanisms all current IPv6 security mechanisms will work without modification for ATM. This includes both authentication and encryption for both Neighbor Discovery protocols as well as the exchange of IPv6 data Armitage, et al. Expires January 22nd, 1998 [Page 20] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 packets. The MARS protocol is modified in a manner that does not affect or augment the security offered by RFC 2022 in any way. Acknowledgments Eric Nordmark confirmed the usefulness of ND Redirect messages in private email during the March 1996 IETF. The discussions with various ION WG members during the June and December 1996 IETF helped solidify the architecture described here. Grenville Armitage's original work on IPv6/ATM occurred while employed at Bellcore. Elements of section 5 were borrowed from Matt Crawford's draft on IPv6 over Ethernet. Author's address Grenville Armitage Bell Laboratories, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 USA Email: gja@lucent.com Peter Schulter BrightTiger Technologies 125 Nagog Park Acton, MA 01720 Email: paschulter@acm.org Markus Jork European Applied Research Center Digital Equipment Corporation CEC Karlsruhe Vincenz-Priessnitz-Str. 1 D-76131 Karlsruhe Germany email: jork@kar.dec.com Geraldine Harter Digital UNIX Networking Digital Equipment Corporation 110 Spit Brook Road Nashua, NH 03062 Email: harter@zk3.dec.com References. [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC-1883, December 1995. [2] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995. Armitage, et al. Expires January 22nd, 1998 [Page 21] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 [3] M. Crawford, "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996. [4] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, USC/Information Science Institute, July 1993. [5] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, Bellcore, November 1996. [6] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture", RFC-1884, December 1995. [7] T. Narten, E. Nordmark, W.A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. [8] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, March 1997. [9] S. Thomson, T. Nartin, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996. [10] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html. [11] Y. Katsube, K. Nagami, H. Esaki, "Toshiba's Router Architecture Extensions for ATM : Overview", RFC 2098, February 1997 [12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under IP", Proceedings of INFOCOM'96, San Francisco, March 1996, pp.1251- 1260 [13] M. Perez, et al, "ATM Signalling Support for IP over ATM", RFC 1755, February 1995 [14] R. Atkinson, "Default IP MTU for use over ATM AAL5", RFC 1626, May 1994 [15] J. McCann, et al, "Path MTU Discovery for IP version 6", RFC 1981, August 1996 Armitage, et al. Expires January 22nd, 1998 [Page 22] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 Appendix A. IPv6 Protocol Operation Description The IPv6 over ATM model described in this document maintains the complete semantics of the IPv6 protocols. No changes need to be made to the IPv6 Network Layer. Since the concept of the security association is not being changed for ATM, this framework maintains complete IPv6 security semantics and features. This allows IPv6 nodes to choose their responses to solicitations based on security information as is done with other datalinks, thereby maintaining the semantics of Neighbor Discovery since it is always the solicited node that chooses what (and even if) to reply to the solicitation. Thus, ATM will be transparent to the network layer except in cases where extra services (such as QoS VCs) are offered. The remainder of this Appendix describes how the core IPv6 protocols will operate within the model described here. A.1 Neighbor Discovery Operations Before performing any sort of Neighbor discover operation, each node must first join the all-node multicast group, and it's solicited node multicast address (the use of this address in relation to DAD is described in A.1.4). The IPv6 Network layer will join these multicast groups as described in 4.2. A.1.1 Performing Address Resolution An IPv6 host performs address resolution by sending a Neighbor Solicitation to the solicited-node multicast address of the target host, as described in [7]. The Neighbor Solicitation message will contain a Source Link-Layer Address Option set to the soliciting node's ATM address on the LL. When the local node IPv6/ATM driver is passed the Neighbor Solicitation message from the IPv6 network layer, it follows the steps described in section 4.4.2 Sending Multicast Data. One or more nodes will receive the Neighbor Solicitation message. The nodes will process the data as described in section 4.5 and pass the de-encapsulated packets to the IPv6 network layer. If the receiving node is the target of the Neighbor Solicitation it will update its Neighbor Cache with the soliciting node's ATM address, contained in the Neighbor Solicitation message's Source Link-Layer Address Option as described in [7]. The solicited IPv6 host will respond to the Neighbor Solicitation with a Neighbor Advertisement message sent to the IPv6 unicast address of the soliciting node. The Neighbor Advertisement message will contain a Target Link-Layer Address Option set to the solicited node's ATM address on the LL. Armitage, et al. Expires January 22nd, 1998 [Page 23] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 The solicited node's IPv6/ATM driver will be passed the Neighbor Advertisement and the soliciting node's link-layer address from the IPv6 network layer. It will then follow the steps described in section section 4.4.1 to send the NA message to the soliciting node. This will create a VC between the solicited and soliciting node if one did not already exist. The soliciting node will then receive the Neighbor Advertisement message over the new PtP VC, de-encapsulate the message, and pass it to the IPv6 Network layer for processing as described in section 4.5. The soliciting node will then make the appropriate entries in it's Neighbor cache, including caching the ATM link-layer address of the solicited node as described in [7]. At this point each system has a complete Neighbor cache entry for the other system so that they can exchange data over the newly created PtP VC. An IPv6 host can also send an Unsolicited Neighbor Advertisement to the all-nodes multicast address. When the local node IPv6/ATM driver is passed the Neighbor Advertisement from the IPv6 network layer, it follows the steps described in section 4.4.2 to send the NA message to the all-nodes multicast address. Each node wil process the incoming packet as described in section 4.5 and then pass the packet to the IPv6 Network layer where it will be processed as described in [7]. A.1.2 Performing Router Discovery Router Discovery is described in [7]. To support Router Discovery an IPv6 router will join the IPv6 all-routers multicast group address. When the IPv6/ATM driver gets the JoinLocalGroup request from the IPv6 Network Layer, it follows the process described in section 4.2. Joining a Multicast Group. IPv6 routers periodically send unsolicited Router Advertisements announcing their availability on the LL. When an IPv6 router sends an unsolicited Router Advertisement, it sends a data packet addressed to the IPv6 all-nodes multicast address. When the local node IPv6/ATM driver gets the Router Advertisement message from the IPv6 Network layer, it transmits the message by following steps described in section 4.4.2. The MARS server will transmit the packet on the LL's ClusterControlVC, which sends the packets to all nodes on the LL. Each node on the LL will then process the incoming packet as described in section 4.5 and pass the received packet to the IPv6 Network layer for processing as appropriate. To perform Router Discovery, an IPv6 host sends a Router Solicitation message to the all-routers multicast address. When the local node IPv6/ATM driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in section 4.4.2. The RS message will be sent to either those nodes which have joined the all-routers multicast group or to all nodes. The nodes Armitage, et al. Expires January 22nd, 1998 [Page 24] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 which receive the RA message will process the message as described in section 4.5 and pass the RA message up to the IPv6 datalink layer for processing. Only those nodes which are routers will process the message and respond to it. An IPv6 router responds to a Router Solicitation by sending a Router Advertisement addressed to the IPv6 all-nodes multicast address if the source address of the Router Solicitation was the unspecified address. If the source address in the Router Solicitation is not the unspecified address, the the router will unicast the Router Advertisement to the soliciting node. If the router sends the Router Advertisement to the all-nodes multicast address then it follows the steps described above for unsolicited Router Advertisements. If the Router Advertisement is to be unicast to the soliciting node, the IPv6 Network Layer will give the node IPv6/ATM driver the Router Advertisement and link-layer address of the soliciting node (obtained through Address Resolution if necessary) which will send the packet according to the steps described in section 4.4.1 This will result in a new PtP VC being created between the router and the soliciting node if one did not already exist. The soliciting node will receive and process the Router Advertisement as described in section 4.5 and will pass the RA message to the IPv6 Network layer. The IPv6 Network Layer may, depending on the state of the Neighbor Cache entry, update the Neighbor Cache with the router's ATM address, contained in the Router Advertisement message's Source Link-Layer Address Option. If a PtP VC is set up during Router Discovery, subsequent IPv6 best effort unicast data between the soliciting node and the router will be transmitted over the new PtP VC. A.1.3 Performing Neighbor Unreachability Detection (NUD) Neighbor Unreachability Detection (NUD) is the process by which an IPv6 host determines that a neighbor is no longer reachable, as described in [7]. Each Neighbor Cache entry contains information used by the NUD algorithm to detect reachability failures. Confirmation of a neighbor's reachability comes either from upper-layer protocol indications that data recently sent to the neighbor was received, or from the receipt of a Neighbor Advertisement message in response to a Neighbor Solicitation probe. Connectivity failures at the node IPv6/ATM driver, such as released VCs (see section 4.6. Unicast Data VC Setup and Release) and the inability to create a VC to a neighbor (see section 4.4.1. Sending Unicast Data), are detected and handled at the IPv6 Network Layer, through Neighbor Unreachability Detection. The node IPv6/ATM driver does not attempt to detect or recover from these conditions. A persistent failure to create a VC from the IPv6 host to one of Armitage, et al. Expires January 22nd, 1998 [Page 25] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 its IPv6 neighbors will be detected and handled through NUD. On each attempt to send data from the IPv6 host to its neighbor, the node IPv6/ATM driver will attempt to set up a VC to the neighbor, and failing to do so, will drop the packet. IPv6 reachability confirmation timers will eventually expire, and the neighbor's Neighbor Cache entry will enter the PROBE state. The PROBE state will cause the IPv6 host to unicast Neighbor Solicitations to the neighbor, which will be dropped by the local node IPv6/ATM driver after again failing to setup the VC. The IPv6 host will therefore never receive the solicited Neighbor Advertisements needed for reachability confirmation, causing the neighbor's entry to be deleted from the Neighbor Cache. The next time the IPv6 host tries to send data to that neighbor, address resolution will be performed. Depending on the reason for the previous failure, connectivity to the neighbor could be re-established (for example, if the previous VC setup failure was caused by an obsolete link- layer address in the Neighbor Cache). In the event that a VC from an IPv6 neighbor is released, the next time a packet is sent from the IPv6 host to the neighbor, the node IPv6/ATM driver will recognize that it no longer has a VC to that neighbor and attempt to setup a new VC to the neighbor. If, on the first and on subsequent transmissions, the node is unable to create a VC to the neighbor, NUD will detect and handle the failure as described earlier (handling the persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors). Depending on the reason for the previous failure, connectivity to the neighbor may or may not be re-established. A.1.4 Performing Duplicate Address Detection (DAD) An IPv6 host performs Duplicate Address Detection (DAD) to determine that the address it wishes to use on the LL (i.e. a tentative address) is not already in use, as described in [IPV6- ADDRCONF] and [7]. Duplicate Address Detection is performed on all addresses the host wishes to use, regardless of the configuration mechanism used to obtain the address. Prior to performing Duplicate Address Detection, a host will join the all-nodes multicast address and the solicited-node multicast address corresponding to the host's tentative address (see 4.2. Joining a Multicast Group). The IPv6 host initiates Duplicate Address Detection by sending a Neighbor Solicitation to solicited- node multicast address corresponding to the host's tentative address, with the tentative address as the target. When the local node IPv6/ATM driver gets the Neighbor Solicitation message from the IPv6 Network layer, it follows the steps outlined in section 4.4.2. The NS message will be sent to those nodes which joined the target solicited-node multicast group or to all nodes. The DAD NS message will be received by one or more nodes on the LL and processed by each as described in section 4.5. Note that the MARS client of the sending node will filter out the message so that the sending node's IPv6 Network layer will not be sent the message. The IPv6 Network Armitage, et al. Expires January 22nd, 1998 [Page 26] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 Layer of any node which is not a member of the target solicited-node multicast group will discard the Neighbor Solicitation message. If no other hosts have joined the solicited-node multicast address corresponding to the tentative address, then the host will not receive a Neighbor Advertisement containing its tentative address as the target. The host will perform the retransmission logic described in [IPV6-ADDRCONF], terminate Duplicate Address Detection, and assign the tentative address to the NBMA interface. Otherwise, other hosts on the LL that have joined the solicited- node multicast address corresponding to the tentative address will process the Neighbor Solicitation. The processing will depend on whether or not receiving IPv6 host considers the target address to be tentative. If the receiving IPv6 host's address is not tentative, the host will respond with a Neighbor Advertisement containing the target address. Because the source of the Neighbor Solicitation is the unspecified address, the host sends the Neighbor Advertisement to the all-nodes multicast address following the steps outlined in section 4.4.2. The DAD NA message will be received and processed by the MARS clients on all nodes in the LL as described in section 4.5. Note that the sending node will filter the incoming message since the CMI in the message header will match that of the receiving node. All other nodes will de-encapsulate the message and pass it to the IPv6 Network layer. The host performing DAD will detect that its tentative address is the target of the Neighbor Advertisement, and determine that the tentative address is not unique and cannot be assigned to its NBMA interface. If the receiving IPv6 host's address is tentative, then both hosts are performing DAD using the same tentative address. The receiving host will determine that the tentative address is not unique and cannot be assigned to its NBMA interface. A.1.5 Processing Redirects An IPv6 router uses a Redirect Message to inform an IPv6 host of a better first-hop for reaching a particular destination, as described in [7]. This can be used to direct hosts to a better first hop router, another host on the same LL, or to a transient neighbor on another LL. The IPv6 router will unicast the Redirect to the IPv6 source address that triggered the Redirect. The router's IPv6/ATM driver will transmit the Redirect message using the procedure described in section 4.4.1. This will create a VC between the router and the redirected host if one did not previously exist. The node's IPv6/ATM driver of the IPv6 host that triggered the Redirect will receive the encapsulated Redirect over one of it's PtP VCs. It will the de-encapsulate the packet, and pass the Redirect message to the IPv6 Network Layer, as described section 4.5. Armitage, et al. Expires January 22nd, 1998 [Page 27] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 Subsequent data sent from the IPv6 host to the destination will be sent to the next-hop address specified in the Redirect Message. For NBMA networks, the Redirect Message should contain the link-layer address option as described in [7], thus the redirected node will not have to perform a Neighbor Solicitation to learn the link-layer address of the node to which it has been redirected. Thus, the redirect can be to any node on the ATM network, regardless of the LL membership of the new target node. This allows NBMA hosts to be redirected off their LL to achieve shortcut by using standard IPv6 protocols. Once redirected, the IPv6 Network Layer will give the node's IPv6/ATM driver the IPv6 packet and the link-layer address of the next-hop node when it sends data to the redirected destination. The node IPv6/ATM driver will determine if a VC to the next-hop destination exists. If a PtP VC does not exist, then the IPv6/ATM driver will queue the data packet and initiate a setup of a VC to the destination. When the VC is created, or if one already exists, then the node will encapsulate the outgoing data packet and send it on the VC. Note that Redirects are unidirectional. The redirected host will create a VC to the next-hop destination as specified in the Redirect message, but the next-hop will not be redirected to the source host. Because no Neighbor Discovery takes place, the next-hop destination has no way of determining the identity of the caller when it receives the new VC. Also, since ND does not take place on redirects, the next-hop receives no event that would cause it to update it's neighbor or destination caches. However, it will continue to transmit data back to the redirected host on the former path to the redirected host. The next-hop node should be able to use the new VC from the redirected destination if it too receives a redirect redirecting it to the redirected node. This behavior is consistent with [7]. A.2 Address Configuration IPv6 addresses are auto-configured using the stateless or stateful address auto-configuration mechanisms, as described in [IPV6- ADDRCONF] and [IPV6-DHCP]. The IPv6 auto-configuration process involves creating and verifying the uniqueness of a link-local address on an LL, determining whether to use stateless and/or stateful configuration mechanisms to obtain addresses, and determining if other (non-address) information is to be autoconfigured. IPv6 addresses can also be manually configured, if for example, auto-configuration fails because the autoconfigured link-local address is not unique. An LL administrator specifies the type of autoconfiguration to use; the hosts on an LL receive this autoconfiguration information through Router Advertisement messages. The following sections describe how stateless, stateful and manual address configuration will work over the framework described in Armitage, et al. Expires January 22nd, 1998 [Page 28] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 this document. A.2.1 Stateless Address Configuration IPv6 stateless address configuration is the process by which an IPv6 host autoconfigures its interfaces, as described in [IPV6- ADDRCONF]. When an IPv6 host first starts up, it generates a link-local address for the interface attached to the Logical Link. It then verifies the uniqueness of the link-local address using Duplicate Address Detection (DAD). If the IPv6 host detects that the link- local address is not unique, the autoconfiguration process terminates. The IPv6 host must then be manually configured. After the IPv6 host determines that the link-local address is unique and has assigned it to the interface on the Logical Link, the IPv6 host will perform Router Discovery to obtain auto- configuration information. The IPv6 host will send out a Router Solicitation and will receive a Router Advertisement, or it will wait for an unsolicited Router Advertisement. The IPv6 host will process the M and O bits of the Router Advertisement, as described in [IPV6-ADDRCONF] and as a result may invoke stateful address auto-configuration. If there are no routers on the Logical Link, the IPv6 host will be able to communicate with other IPv6 hosts on the Logical Link using link-local addresses. The IPv6 host will obtain a neighbor's link-layer address using Address Resolution. The IPv6 host will also attempt to invoke stateful auto-configuration, unless it has been explicitly configured not to do so. A.2.2 Stateful Address Configuration (DHCP) IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to perform stateful address auto-configuration, as described in [IPV6- DHCP]. A DHCPv6 server or relay agent is present on a Logical Link that has been configured with manual or stateful auto-configuration. The DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay-Agent multicast group on the Logical Link. When the node ATM/IPv6 driver gets the JoinLocalGroup request from the IPv6 Network Layer, it follows the process described in section 4.2. An IPv6 host will invoke stateful auto-configuration if M and O bits of Router Advertisements indicate it should do so, and may invoke stateful auto-configuration if it detects that no routers are present on the Logical Link. An IPv6 host that is obtaining configuration information through the stateful mechanism will hereafter be referred to as a DHCPv6 client. Armitage, et al. Expires January 22nd, 1998 [Page 29] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv6 Server/Relay-Agent multicast address to locate a DHCPv6 Agent. When the soliciting node's IPv6/ATM driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in section 4.4.2. Sending Multicast Data. This will result in one or more nodes on the LL receiving the message. Each node that receives the solicitation packet will process it as described in section section 4.5 and will pass the message up to the IPv6 network layer. Only the IPv6 network layer of the DHCPv6 server/relay-agent will accept the packet and process it. A DHCPv6 Server or Relay Agent on the Logical Link will unicast a DHCPv6 Advertisement to the DHCPv6 client. The IPv6 Network Layer will give the node's IPv6 to ATM IPv6/ATM driver the packet and link-layer address of the DHCPv6 client (obtained through Neighbor Discovery if necessary). The node IPv6/ATM driver will then transmit the packet as described in section 4.4.1. This will result a new PtP VC being created between the server and the client if one did not previously exist. The DHCP client's node IPv6/ATM driver will receive the encapsulated packet from the DHCP Server or Relay Agent, as described in section 4.5. Receiving Data . The node will de- encapsulate the multicast packet and then pass it up to the IPv6 Network Layer for processing. The IPv6 Network Layer will deliver the DHCPv6 Advertise message to the DHCPv6 client. Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are unicast between the DHCPv6 client and the DHCPv6 Server. Depending on the reachability of the DHCPv6 client's address, messages exchanged between a DHCPv6 client and a DHCPv6 Server on another LL are sent either via a router or DHCPv6 Relay-Agent. Prior to sending the DHCPv6 message, the IPv6 Network Layer will perform Neighbor` Discovery (if necessary) to obtain the link-layer address corresponding to the packet's next-hop. An PtP VCwill be set up between the sender and the next hop, and the encapsulated packet transmitted over it, as described in 4.4. Sending Data. A.2.3 Manual Address Configuration An IPv6 host will be manually configured if it discovers through DAD that its link-local address is not unique. Once the IPv6 host is configured with a unique interface token, the auto-configuration mechanisms can then be invoked. A.3 Internet Group Management Protocol (IGMP) IPv6 multicast routers will use the IGMPv6 protocol to periodically determine group memberships of local hosts. In the framework described here, the IGMPv6 protocols can be used without any special modifications for ATM. While these protocols might not be the most efficient in this environment, they will still work as described below. However, IPv6 multicast routers connected to an ATM LL could Armitage, et al. Expires January 22nd, 1998 [Page 30] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 optionally optimize the IGMP functions by sending MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and determining group memberships by the MARS_GROUPLIST_REPLY messages. Querying the MARS for multicast group membership is an optional enchancement and is not required for routers to determine IPv6 multicast group membership on a LL. There are three ICMPv6 message types that carry multicast group membership information: the Group Membership Query, Group Membership Report and Group Membership Reduction messages. The Internet Group Management Protocol (IGMPv6) will continue to work unmodified over the framework described in this document. An IPv6 multicast router receives all IPv6 multicast packets on the LL joining all multicast groups in promiscuous mode [5]. The MARS server will then cause the multicast router to be added to all existing and future multicast VCs. The IPv6 multicast router will thereafter be the recipient of all IPv6 multicast packets sent within the Logical Link. An IPv6 multicast router discovers which multicast groups have members in the Logical Link by periodically sending Group Membership Query messages to the IPv6 all-nodes multicast address. When the local node IPv6/ATM driver gets the request from the IPv6 Network Layer to send the Group Membership Query packet, it follows the steps described in 4.4.2. Sending Multicast Data . The node determines that the destination address of the packet is the all-nodes multicast address and passes the packet to the node's MARS client where the packet is encapsulated and transmitted to the MARS server over the PtP VC connecting the mutlicast router to the MARS server. The MARS server then relays the packet to it's ClusterControlVC, sending the packet to all nodes in the LL. Each node's IPv6/ATM drivers will receive the packet from the ClusterControlVC via it's MARS client. The incoming packet will be de-encapsulated and passed up to the IPv6 Network layer. If the originating node receives the encapsulated packet, the packet will be filtered out by the MARS client since the Cluster Member ID of the receiving node will match the CMI in the packet header. IPv6 hosts in the Logical Link will respond to a Group Membership Query with a Group Membership Report for each IPv6 multicast group joined by the host. IPv6 hosts can also transmit a Group Membership Report when the host joins a new IPv6 multicast group. The Group Membership Report is sent to the multicast group whose address is being reported. When the local node IPv6/ATM driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps described in 4.4.2. Sending Multicast Data. The node determines that the packet is being sent to a multicast address so forwards it to the node's MARS client for sending on the appropriate VC. The Group Membership Report packets will arrive at every node which is a member of the group being reported through one of the VC attached to each node's MARS client. The MARS client will de- Armitage, et al. Expires January 22nd, 1998 [Page 31] Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997 encapsulate the incoming packet and the packet will be passed to the IPv6 Network layer for processing. The MARS client of the sending node will filter out the packet when it receives it. An IPv6 host sends a Group Membership Reduction message when the host leaves an IPv6 multicast group. The Group Membership Reduction is sent to the multicast group the IPv6 host is leaving. The transmission and receipt of Group Membership Reduction messages are handled in the same manner as Group Membership Reports. Armitage, et al. Expires January 22nd, 1998 [Page 32]