Internet Info 1997 December

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-00.txt < prev next >

Wrap

Text File | 1997-03-24 | 82KB | 1,860 lines

Internet-Draft Grenville Armitage (Bellcore) Peter Schulter () Markus Jork Geraldine Harter (Digital) March 20, 1997 Transient Neighbors for IPv6 over ATM <draft-ietf-ion-tn-00.txt> 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 a model for IPv6 over ATM. The model allows conventional host-side operation of the Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM routes. This is achieved through the use of Redirects to create Transient Neighbors, standard IPv6 protocol operation within the IPv6 Logical Link, and partial NHRP for location of off-Link destinations. The egress router detects flows that are suitable candidates for shortcut, uses NHRP to locate a better link level first hop, and then issues a Redirect message to the source. Armitage, et al. Expires September 20, 1997 [Page 1] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 Revision History March 1997, version 00 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 immediately true of ATM interfaces, a fact that is generating a number of attempts to bypass or modify some of ND's assumptions. It has also not been clear to the IP/ATM community how Neighbor Discovery can be applied to services such as locating '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). A general overview of the issues facing IPv6 over ATM is provided in [10]. This document looks at a number of evolving models in the IP world, and attempts to synthesize a general solution of IPv6 ND over ATM that supports shortcut routing without requiring large scale multicasting of ND messages around an ATM network. The salient models are: Armitage, et al. Expires September 20, 1997 [Page 2] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 - The IPv6 Neighbor model, refined as in [10], 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: IPv6 over ATM interfaces utilize the MARS itself to distribute discovery messages around their Logical Link. 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. A number of key advantages are claimed for this approach. These are: The IPv6 stacks on hosts do not implement separate ND protocols for each link layer technology. When the destination of a flow is solicited as a transient neighbor, the returned ATM address will be the one it chose when the flow was originally established through hop-by-hop processing (for destination interface load sharing). 2. Logical Links, and Transient Neighbors. (To review the model of 'link' used in this document, the following text is borrowed straight from section 5 of [10].) 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 Armitage, et al. Expires September 20, 1997 [Page 3] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 Router Advertisement 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 preceding descriptions may need refinement in the context of Logical Links (or equivalent concept). The LL is the same set of hosts that make up a given MARS Cluster - an administratively defined group. These are an IPv6 interface's initial set of neighbors, and each interface's Link-Local address only needs to be unique amongst this set. Events such as the receipt of ND advertisement messages, or the operation of some alternative discovery protocol, may result in the expansion of an IPv6 interface's set of Neighbors. However, this should not be considered to have changed the set of interfaces that make up its LL. This leads to three possible relationships between any two IPv6 interfaces: - On LL, Neighbor. - Off LL, Neighbor. - Off LL, not Neighbor. Off LL Neighbors are the 'shortcut' connections, where some dynamic protocol activity has ascertained that although a target IPv6 interface is not a member of the source's LL, it is possible to achieve link level connectivity. Neighbors 'discovered' through the operation of unsolicited messages, such as Redirects, may be 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. Armitage, et al. Expires September 20, 1997 [Page 4] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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. As noted in [10], IPv6 assumes that multicasting is an integral part of the Internet service. Section 2.1 of [10] shows how this can be provided using the MARS [5] service currently being developed for IPv4 multicast over ATM. 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 explore the tradeoffs of various mechanisms below the IP 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 - MARS as 'black box'. The IPv6/ATM driver utilizes the standard MARS protocol to establish a VC forwarding path out of the interface on which it can transmit the ICMPv6 packet. The ICMPv6 packet is then transmitted, and is received by the intended destination set. With such an approach all the protocol elements in [5] should work 'as is'. However, VC resource consumption must be taken into consideration. Unfortunately, the issues that affect VC resource consumption when supporting ND are not amenable to simply shifting from VC mesh to Multicast Server modes of emulating multicast. 3.1.2 MARS as a Link (Multicast) Server. ND assumes that link level multicast resources are best conserved by generating a sparsely distributed set of Solicited Node multicast addresses (to which discovery queries are initially sent). The original goal was to minimize the number of innocent nodes that simultaneously received discovery messages really intended for someone else. However, in 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 a MARS solution 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 likely to be useful _only_ for additional packets being sent to the Solicited Node multicast address that caused the VC to be created in the first place. This means a new pt- pt VC is established to actually carry the unicast IPv6 traffic that prompted the Neighbor Solicitation. Armitage, et al. Expires September 20, 1997 [Page 5] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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. One possible mechanism for aggregation is for every node's IPv6/ATM driver to trap multicast ICMPv6 packets carrying multicast ND or RD messages, and 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 MARS and MARS clients carry LLC/SNAP encapsulated packets we can multiplex ICMP packets in addition to its original MARS control messages. In essence the MARS behaves as a multicast server for non-MARS control message packets that it receives from around the LL. (Indeed, if we used this approach of 'MARS as MCS' to support the All Nodes multicast group, then the preceding two ideas boil down to the same thing.) As there is no requirement that a MARS client only accepts MARS 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 Armitage, et al. Expires September 20, 1997 [Page 6] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 may still be required by other packets from the host that are leaving the LL). The manner by which a router determines a better first-hop is not specified or constrained in [7]. The model in this document suggests a mechanism. 3.2.1 Redirect Triggers. Technology to support 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 Armitage, et al. Expires September 20, 1997 [Page 7] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 suggests that router-based flow identification mechanisms can be used to trigger the eventual generation of an IPv6 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 yet. 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. 3.2.2 Partial NHRP between routers. Once flow detection has occurred, a router needs some mechanism for establishing the IP to link level address mapping of a better first hop. An obvious approach is for routers to incorporate part of the Next Hop Server (NHS) function that is proposed for them in NHRP. The routers must be able to: - Construct NHRP Requests and Replies. - Parse incoming NHRP Requests and Replies. - Forward NHRP Requests towards an NHS that is topologically closer to the IP target. - Forward NHRP Replies towards an NHS that is topologically closer to the requester. - Perform syntax translation between Neighbor Solicitations and outbound NHRP Requests. - Perform syntax translation between inbound NHRP Replies and Neighbor Redirects or Neighbor Advertisements. The destination of the flow that caused the 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.) To understand the next step it is important to remember that the NHRP Request originates _after_ normal hop-by-hop routing has resulted in IP connectivity between the source and destination. That means the last hop router already has a VC open to the final destination (established by the conventional use of Neighbor Discovery on the destination's LL). As a consequence the NHRP Request may be satisfied using mapping information contained in the router's own neighbor cache. (This assumes that Neighbor Unreachability Detection Armitage, et al. Expires September 20, 1997 [Page 8] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 at the router considers the final destination currently reachable. If not, the final router verifies the reachability of the destination, and builds a NHRP Reply with the validated mapping.) 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. When it reaches the originating router, the resolved address mapping is used to construct a Router Redirect message. The Router Redirect is then unicast to the IP packet flow's source (using the VC on which the flow is arriving at the router, if it's 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 use of NHRP between the routers is not meant to be normative. Any protocol that the routers understood, and was capable of carrying IP to link layer mappings, would suffice. However, current efforts to deploy NHRP in routers means it is the most likely technology on which to build the inter-LL mechanism.) 3.2.3 Host Triggered Redirection In some cases, the sending host may want to trigger a redirection to a transient neighbor. To support host-triggered redirects, routers would have to recognize specific Neighbor Discovery messages sent by hosts which would then trigger NHRP resolutions of off-link addresses. All routers which support NHRP in an IPv6 ATM network should have this capability. To perform host-triggered redirects, a sending host would create a Neighbor Solitication message which contains the destination unicast address (and not the solicited node multicast address) of the off- link node to which the sending host wants to be redirected. Because this NS packet is addressed to a unicast address, the sending host would then send this ND packet to a default router, which must also be running NHRP. The router would recognize the unicast NS to an off-link address as a request for a host-triggered redirect and would turn the NS into an NHRP resolution request. The NS message must not be forwarded. The router would then use NHRP to resolve the transient neighbor's address. Once the NHRP address resolution was complete, the router would construct a Neighbor Advertisement message which contained the IPv6 address of the transient neighbor, the ATM datalink address returned by the NHRP resolution process, and have the Overide bit set to 1. If NHRP returns the address of an egress router rather than of the destination node its self, 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 so that when it has a packet to sent to the transient neighbor it will create a direct VC to that neighbor (or to the best egress router towards that neighbor as determined by Armitage, et al. Expires September 20, 1997 [Page 9] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 provides a basic description of node operations for performing basic functions (such as sending and receiving data) on an LL to aid in understanding how nodes perform these operations in the LL model. The application of these basic functions to the operation of the various IPv6 protocols such as Neighbor Discovery is described in Appendix A. 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 and IPv6 ND operations can then be performed. 4.2 Joining a Multicast Group This section describes the node's behavior when it gets a JoinLocalGroup request from the IPv6 Network Layer. The IPv6 over ATM layer will have to examine each group address joined to determine how the join request is to be handled. If a JoinLocalGroup for a node-local address is received then no action is taken and the JoinLocalGroup function returns success to the caller. Node-local addresses are not handled by the IPv6 over ATM layer. When the MARS clients receive a request to join a non node-local multicast group, it will send to the MARS the appropriate MARS_JOIN request to register its membership of the specified group. Only one special action is required of MARS Clients supporting router Armitage, et al. Expires September 20, 1997 [Page 10] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 interfaces. They MUST issue a block MARS_JOIN for the range(s) of IPv6 multicast addresses that the router is required to listen promiscously across (analogous to the IPv4 description in section 8 of [5]). 4.3. Leaving a Multicast Group This section describes the node's behavior when it gets a LeaveLocalGroup request from the IPv6 Network Layer. The IPv6 over ATM layer will have to examine each group address joined 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 over ATM layer. All other requests to leave multicast groups will be handled in the normal manner by the MARS client. When the MARS clients receive a request to leave a non node-local multicast group, it will send to the MARS the appropriate MARS_LEAVE request to de-register its membership of the specified group. 4.4. Sending Data When the IPv6 over ATM layer is given a packet from the local IPv6 Network Layer, it has to determine whether the packet is being sent to a unicast or multicast link-layer address. The following sections describe the node operations when sending unicast and multicast packets. 4.4.1. Sending Unicast Data When a node is given an IPv6 Network Layer 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, then the packet is 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 layer 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. Armitage, et al. Expires September 20, 1997 [Page 11] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 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 All multicast packets are transmitted using the following encapsulation: [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet] The client's Cluster Member ID (CMI) is copied into the pkt$cmi field prior to transmission. A packet is sent over the MARS client's PtP VC to the MARS if its destination is one of the following multicast addresses: - 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. If the VC to the MARS has been idle timed out for some reason, it must be re-established before forwarding the IPv6 packet to the MARS. The MARS will redistribute the IPv6 packet appropriately as described in section 3.1.3. If the destination multicast group address of the packet to be sent is any other address, then the usual MARS client mechanisms are used to select and/or establish the pt-mpt VC on which the packet is to be sent. 4.5. Receiving Data All IPv6 packets received on any unicast PtP VC are simply de- encapsulated and passed up to the IPv6 Network later. The IPv6 network layer then determines how the incoming packet is to be handled. Packets received using the encapsulation shown in section 4.4.2 have their pkt$cmi field compared to the receiving client's CMI. If the CMI in the header matches the receiver's CMI then the packet was sent by the receiver and is silently dropped [5]. Otherwise, the packet is accepted and passed to the IPv6 network layer. The IPv6 Network layer then determines if the packet should be accepted, routed, or discarded. Armitage, et al. Expires September 20, 1997 [Page 12] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 4.6. Unicast Data VC Setup and Release 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. Unicast VCs are maintained separately from multicast VCs. Currently, only best effort unicast VCs are described here. The creation of non-best effort, or flow based VCs is an area which requires more discussion and study. Unlike the IPv4 over ATM mechanisms (Classical IP and NHRP) which place calls from a sending node towards the receiving node, IPv6 will cause receiving nodes to place calls towards sending nodes in the most common case. This is a natural consequence of the way in which IPv6 resolves datalink addresses. For all cases, it is the transmission of a unicast packet by any node which will trigger that node's call to the destination or next hop node. 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 over ATM layer receives a unicast packet for transmission, it can expect that the IPv6 Network layer will also provide the datalink address for the immediate destination (just as a MAC address is provided to Ethernet, for example). The IPv6 over ATM layer 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 (i.e., 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 Armitage, et al. Expires September 20, 1997 [Page 13] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 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 another area which 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 to ATM layer will not know if the called party is on the calling node's LL. Thus, the calling party can not assume that called party will have the same default MTU as its LL. Thus, MTU MUST be negotiated for each call placed using the procedures described in [14]. This will permit two nodes which are connected via a shortcut VC to establish an MTU which will allow them to exchange data without having to perform fragmentation. Note that while the procedures in [14] still apply to IPv6 over ATM, Armitage, et al. Expires September 20, 1997 [Page 14] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 IPv6 Path MTU Discovery [15] is used by nodes and routers rather than IPv4 MTU discovery. Additionally, IPv6 nodes are not required to implement Path MTU Discovery, but ATM nodes SHOULD implement it. Also, since IPv6 nodes will negoatiate an appropriate MTU for each VC, Path MTU should never be triggered since niether 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. 5. Host Tokens and Link Layer Address Options 5.1 Host Tokens Each IPv6 interface must have a host token which is used to form IPv6 autoconfigured addresses. This host token must be unique within an IPv6 Link (subnet) 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 host token then one interface MUST choose another host-token. All implementations MUST support manual configuration of host tokens to allow operators to manually change a host token on a per-LL basis. Operators may choose to manually set host tokens for reasons other than eliminating duplicate addresses. 5.1.1 Host Tokens Based on MAC or ESI values Where the underlying ATM NIC driver has access to a set of one or more 48 bit values unique to the ATM NIC (e.g. MAC addresses configured into the NIC's ROM), the IPv6/ATM interface SHALL use one of these values to create a unique host token. (These values may or may not also correspond to the ESI(s) registered with the local ATM switch by the ATM driver.) 5.1.2 Host Tokens Based on E.164 Addresses If an interface using E.164 addressing has no available MAC address for use as a host token (as described above), then the E.164 address will be used after conversion to a 48 bit format. To convert an E.164 address to a 48 bit format the series of 15 E.164 BCD encoded digits will be interpreted as a 15 digit decimal number and converted to its binary representation and truncated to 48 bits. 5.1.3 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 NSAPA prefix, or a set of entirely separate ESIs might have been registered with the local ATM switch to create a range of unique NSAPAs. 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 Armitage, et al. Expires September 20, 1997 [Page 15] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 host 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 host 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 [16]. 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 host token from the range of 48 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 host token onto the same LL. 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 Armitage, et al. Expires September 20, 1997 [Page 16] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 NSAPA 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: 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 NSAPA 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 NSAPA 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). 6. Flow Detection Flow detection is not required for IPv6 over ATM to operate, but is desirable to facilitate both QoS based connections between nodes (both intra-LL and shortcut) and to more efficiently use network resources (such as IPv6 routers). In some cases, the establishment of flows may require more information than is currently specified for IPv6 Neighbor Discovery packets. In these cases, the IPv6 Neighbor Discover protocols can be extended to include new TLV options (see [7]). However, if new TLV options are required, the specification of these options must be co- ordinated with the IPNG working group so that they do not conflict with other new options which may be defined (mainly preventing collisions of the option type value). Since [7] specifies that any node must silently ignore any options it does not understand, new Armitage, et al. Expires September 20, 1997 [Page 17] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 options can be added at any time without breaking backward compatability with existing implementations. In this way, the protocols described here are at least as flexible as NHRP in terms of extensibility. The issue of how to detect flows and what to do once flows are detected is still being discussed in many IETF working groups including ISSL and RSVP in addition to the continuing discussions in the ION WG around QoS and flow based shortcuts. The methods used for IPv6 may differ somewhat from those used for IPv4 since IPv6 has the flow label field in the header. Depending on how the use of this field is specified, it might aid in flow detection (for example, a router could use a non-zero flow label as a hint to set up a flow). 7. Conclusion and Open Issues. This document provides a moderately low-level view of an approach to 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). Indeed, no special protocol is required at all in the hosts to support the use of shortcut routes. 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. It is suggested that we explore the model of router-identified IP flows for triggering shortcut connections. It is noted that the IPv6 Router Redirect message is designed with the precise intention of supporting the advertisement of new Neighbors in NBMA environments - and proposes to use the Redirect message in exactly that role. Finally, parts of the NHRP architecture are 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 for Router Redirect packets, NHRP Request/Reply packets, and the sharing of MARS ClusterControlVC by MARS control messages and Discovery related ICMPv6 packets. As with all open issues, contributions to the mailing list are solicited. 8. Security Consideration While this proposal does not introduce any new security mechanisms Armitage, et al. Expires September 20, 1997 [Page 18] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 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 packets. 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. Author's address Grenville Armitage Internetworking Research Group, Bellcore. 445 South Street Morristown, NJ, 07960 USA Email: gja@bellcore.com Peter Schulter 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. [3] M. Crawford, "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996. Armitage, et al. Expires September 20, 1997 [Page 19] Internet Draft draft-ietf-ion-tn-00.txt March 20, 1997 [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] G.J. Armitage, "IPv6 and Neighbor Discovery over ATM", INTERNET-DRAFT, draft-ietf-ion-ipv6nd-00.txt, ION WG, June 1996. [11] Yasuhiro Katsube, Ken-ichi Nagami, Hiroshi Esaki, "Router Architecture Extensions for ATM : Overview", INTERNET-DRAFT, draft- katsube-router-atm-overview-02.txt, March 1996. [12] Ipsilon, "IP Switch Technology", http://www.ipsilon.com/ips.html [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 [16] Robert Elz, "Identifying IPv6 Interfaces in Link-Local Addresses", INTERNET DRAT, draft-ietf-ipngwg-iid-02.txt, May 1996 Armitage, et al. Expires September 20, 1997 [Page 20] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 21] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 22] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 23] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 24] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 25] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 26] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 27] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 28] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 29] Internet Draft draft-ietf-ion-tn-00.txt March 20, 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 September 20, 1997 [Page 30]