Network Working Group Randall Atkinson Internet Draft cisco Systems draft-ietf-ion-ipv6-nbma-01.txt Dimitry Haskin James Luciani Bay Networks 14 November 1996 IPv6 over NBMA Networks STATUS OF THIS MEMO This document 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 6 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 "work in progress". To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft is being proposed to the IETF Internetworking over NBMA (ION) working group for consideration as a standards-track document. Editorial corrections should be sent to the author. Because of the cross-technology aspect of this draft, comments on this draft should be sent cross-posted to both the IPng mailing list and also the Internetworking over NBMA (ION) mailing list . ABSTRACT This draft proposes an comprehensive approach to IPv6 over Non-Broadcast Multiple Access (NBMA) technologies that maximises reuse of existing technology and should work equally well over Frame Relay, ATM, and other NBMA technologies. Atkinson, Haskin, & Luciani [Page 1] Internet Draft IPv6 over NBMA 14 November 1996 1. INTRODUCTION Traditional IPv6 Neighbor Discovery [NN95] and Address Autoconfiguration [TN95] were designed for use over subnetworks where the underlying media has a native broadcast capability. By definition, NBMA subnetworks lack a native broadcast capability, but are capable of concurrent connections to different nodes on a single NBMA logical link. The NBMA Next Hop Resolution Protocol (NHRP) has been developed within the IETF to provide link-layer address resolution capability over NBMA logical links in a network-layer independent manner. In addition, NHRP may provide an important function of dynamically discovering and resolving the address of the closest egress router to the node associated with a target address outside the NBMA portion of the network. This document proposes an approach to handling IPv6 over NBMA media that relies on use of NHRP to provide IPv6 Neighbor Discovery and IPv6 Address Autoconfiguration support. While some ICMPv6 messages originally defined for traditional IPv6 Neighbor Discovery [NN95] are reused for NBMA logical links, the general IPv6 Neighbor Discovery process of that specification is not reused because NBMA environments were outside the intended design scope of that protocol. In addition, this document proposed the use of 6 octet interface tokens [TN95], which are used in conjunction with IPv6 address prefixes to autoconfigure IPv6 addresses. Longer interface tokens are avoided to reduce the amount of IPv6 address space wasted by the interface token. 1.1. TERMINOLOGY The acronym "NBMA" expands to "Non-Broadcast, Multiple Access" and refers to networking technologies that lack a native broadcast facility. Examples of NBMA technologies include ATM, SMDS, Frame Relay, and ISDN. NBMA interfaces are considered to be attached to the same NBMA logical link if these interfaces are administratively configured to receive Router Advertisements from the same set of routers and therefore share the same set of routing prefixes. The terms "subnet" and "subnetwork" in this document refer to the set of nodes connected to the same NBMA logical link (as defined just above). The term "MARS" refers to the proposal for "Multicast Address Resolution Servers" for use with IP multicasting over ATM. Atkinson, Haskin, & Luciani [Page 2] Internet Draft IPv6 over NBMA 14 November 1996 The term "interface token" refers to an interface-specific token, usually 6 octets long, that can be used in conjunction with an IPv6 address prefix to autoconfigure an IPv6 address as part of IPv6 stateless autoconfiguration. In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 2. FORMING AN IPV6 INTERFACE TOKEN The IPv6 interface token is used when auto-configuring an IPv6 address on a network interface. IPv6 addresses are bound to logical network interfaces rather than being bound to nodes. [DH96] There are three cases to consider. The first case is when an IEEE 802 MAC address is on an interface. The second case is when an IEEE 802 MAC address is not available but an E.164, X.121, or ATM Forum NSAP-like address is available to an interface. The last case handles situations where none of those three address types is available or when duplicate addresses have been detected. This specification handles all three cases. 2.1 Interface Tokens based on IEEE 802 MAC Addresses Interfaces having an IEEE 802 MAC address embedded into them MUST use that IEEE 802 MAC address as the interface token for their auto- configured IPv6 addresses on the first logical interface of that physical interface. Atkinson, Haskin, & Luciani [Page 3] Internet Draft IPv6 over NBMA 14 November 1996 When multiple logical interfaces exist on a single physical interface and those logical interfaces share a common NBMA logical link, then the 2nd and later logical interface's interface tokens MAY be formed by the method described below in "Interface Tokens for other cases". Should Duplicate Address Detection (see below) or other information indicate that the autoconfigured address is duplicate with another node on the same NBMA logical link, then the node MUST NOT use that address. In this case, the node SHOULD generate an address using the method described below for "Address Tokens for Other Cases" available to them. In any event, the interface token for the IPv6 address SHOULD NOT exceed 6 bytes in length. This restriction is placed to ensure that sufficient IPv6 address space will remain available to facilitate hierarchical routing. 2.2 Interface Tokens based on E.164, X.121, or NSAP-like addresses If no IEEE 802 MAC address is available but an E.164 address is available, then the IPv6 interface token SHOULD be formed from the E.164 address as follows. The 12 right-most digits of the E.164 address are encoded in Binary Coded Decimal (BCD) syntax to form a 6 octet IPv6 address token. If the E.164 number has less than 12 digits, then the BCD encoded value is padded with leading semi-octet 0000 to obtain the 6-octet IPv6 interface token. If no IEEE 802 MAC address is available, but an X.121 address is available, then the IPv6 interface token SHOULD be formed from the X.121 address as follows. The 12 right-most decimal digits of the X.121 number are encoded in Binary Coded Decimal (BCD) syntax to form a 6 octet IPv6 address token. If the X.121 number has less than 12 digits, then the BCD encoded value is padded with leading semi-octet 0000 to obtain the 6-octet IPv6 interface token. If no IEEE 802 MAC address is available, but an ATM Forum NSAP- like address is available, then the IPv6 interface token SHOULD be the 6 octet ESI field of the ATM Forum address. 2.3 Address Tokens for Other Cases Many believe that manual configuration of interface tokens is the only reasonable choice for interfaces lacking an on-board MAC address. One argument for this is the desire to retain the same interface token across cold reboots of nodes. If neither an IEEE 802 MAC address, nor an E.164 address, nor an X.121 address, nor an ATM Forum NSAP-like address is available to use in forming an IPv6 interface token, then manual configuration MAY be Atkinson, Haskin, & Luciani [Page 4] Internet Draft IPv6 over NBMA 14 November 1996 used to form the IPv6 interface token for autoconfiguration. Users are encouraged to use stateful configuration (e.g. DHCP for IPv6) instead of stateless autoconfiguration to handle such cases. Implementations MUST permit a system administrator to manually configure an interface token for each NBMA interface that lacks an on-board IEEE 802 MAC address. The use of stateful autoconfiguration or manual configuration will ensure that address token collisions do not occur. Alternately, an extension could be added to the NHRP protocol which would cause an unused address (for example, an IPv6 link-local address) to be supplied from a range of specified addresses. This extension would be included in an NHRP Registration Request message from a client to the NHS. When the extension were included in an NHRP Registration Request, an unused address would be allocated from within the range of specified addresses only if the address being registered has already been registered with the "uniqueness" qualifier (c.f. the "Duplicate Address Detection" section of this draft). In this case, the NHRP Registration Reply would still contain a NAK,but the extension will include an acceptable IPv6 address that would then be registered using a subsequent NHRP Registration Request. This approach is for further study. 2.4 Duplicate Address Detection Duplicate Address Detection is performed with a minor enhancement to the NHRP protocol. The NHRP client indicates whether the upper-layer destination address in the NHRP request is to be treated with the "uniqueness" qualifier. To do this, a bit is added to the Mandatory part of the appropriate NHRP messages. When set, this bit indicates that a registration of this upper-layer to NBMA address binding is unique. This "uniqueness" bit MUST be stored in the NHS/NHC cache for the given entry. Any attempt to register a binding between the upper-layer address and an NBMA address when this bit is set MUST be rejected with a new NAK code of "Internetworking Layer Address Already Registered" if an existing binding with the "uniqueness" bit set already exists in the NHS cache. Further, if this bit is set in an NHRP Resolution Request and multiple entries exist in the NHS cache, then only the Next Hop Entry with this bit set will be returned. Note that even if this bit was set at registration time, there can still be multiple Next Hop Entries that might fulfill the NHRP Resolution Request because an entire subnet can be registered through use of the Prefix Length extension and the address of interest might be within such a subnet. If the "uniqueness" bit is set in a NHRP Resolution Request and the responding NHS has one or more cache Atkinson, Haskin, & Luciani [Page 5] Internet Draft IPv6 over NBMA 14 November 1996 entries which match the request but do not have the "uniqueness" bit set, then the NHRP Resolution Reply has the "P" bit set to zero and no Next Hop Entry is included. If a client wishes to receive non- unique Next Hop Entries, then the client must have the "uniqueness" bit set to zero in its NHRP Resolution Request. It is suggested that NHRP adopt a NAK code for NHRP Resolution Replies so that a reason can be given for a failed NHRP Resolution Reply. 3. NEIGHBOR ADDRESS RESOLUTION The NBMA Next-Hop Resolution Protocol (NHRP) defined in [KPCL95] is used to locate the lower-layer address for a given IPv6 destination reached via an NBMA interface. This maximises technology reuse since NHRP is an existing technology that is designed to support multiple upper-layer protocols over NBMA networks. The processes for initial bootstrapping, neighbor discovery, and redirect handling are outlined below so that the relationship and sequencing between the IPv6 Discovery messages and the NHRP messages is clear. None of the procedures in this section assume or imply that the NHS is acting as a MARS, though it is permitted and might be common that the NHS is also acting as a MARS. 3.1 Host Bootstrap Processing The initial VC to the NHS could be created using information manually configured into the node or using some kind of media- specific group address (e.g. as has been proposed for the ATM UNI) Initially, the host creates link-local IPv6 addresses using the above procedures to generate the local-identification token of the link-local address. The host registers this link-local IPv6 address with its NHS by sending its link-local IPv6 address and its corresponding lower-layer NBMA address in an NHRP Registration Request message containing a Responder Address Extension to the NHS. The NHS then processes this message and sends an appropriate NHRP Registration Reply and includes its unicast address in the extension. If the registration is successful, then the NHS reply will have a NAK code of zero. Otherwise, the NHS reply will indicate why the registration failed. The host has now registered its link-local IPv6 address with the NHS. The host then sends an NHRP Resolution Request containing the host's link-local address as the IPv6 Source Address and the link- local all-routers multicast address as the IPv6 Destination Address Atkinson, Haskin, & Luciani [Page 6] Internet Draft IPv6 over NBMA 14 November 1996 to the Next-Hop Server (NHS). The NHS will respond with an NHRP Resolution Reply containing all of the cached bindings between the link-local all-routers multicast IPv6 address and corresponding lower-layer NBMA addresses. The host now knows the lower-layer NBMA address(es) for the IPv6 router(s) on its NBMA logical link. If the NHS is also the IPv6 router for the host's NBMA logical link, then the router SHOULD immediately send a unicast IPv6 Router Advertisement to the requesting host. If no IPv6 Router Advertisement is received, the host SHOULD send an IPv6 Router Solicitation message to each known IPv6 router for its NBMA logical link. Those routers will in turn send a unicast IPv6 Router Advertisement back to the requesting host. The IPv6 Router Solicitation message MUST be sent as a unicast lower-layer message though it MAY contain the link-local scope all-routers multicast address as the IPv6 Destination Address. Routers SHOULD use the IP Authentication Header to authenticate IPv6 Router Advertisement messages whenever the router has an appropriate IP Security Association with the destination node for the IPv6 Router Advertisement. At this point, the host knows the unicast IPv6 address(es) of its router(s), the lower-layer address of its router(s), its routing prefix(es), and whether it needs to perform stateful IPv6 configuration. If stateless IPv6 autoconfiguration was indicated by the received Router Advertisement(s), the host now configures its global IPv6 address(es) as described in [TN95] and uses the NHRP Registration Request to register its global IPv6 address(es) with the NHS. If stateful autoconfiguration was indicated in the IPv6 Router Advertisement, then the host MUST follow the stateful configuration procedure described in [DHCPv6], using NHRP as necessary to obtain lower- layer addresses for IPv6 addresses. Once its global IPv6 address(es) is (are) configured, the node uses the NHRP Registration Request message to register those addresses with the NHS. 3.2 Ongoing Host Processing The NHRP client resolves anycast addresses using the NHRP Resolution Request message to the NHS, taking care to indicate that the target IPv6 address is an anycast address. When NHRP is used to resolve an IPv6 Anycast address, the NHRP "Additional Next Hop Atkinson, Haskin, & Luciani [Page 7] Internet Draft IPv6 over NBMA 14 November 1996 Entries Extension" will be included with the NHRP Resolution Reply if more than one IPv6 node has registered that IPv6 Anycast address with the NHS. The host MAY establish and maintain connections with all routers for the purpose of sending Router Solicits and receiving Router Advertisements if it wishes to. If it does not do this, then the host SHOULD periodically establish/remove connections to handle periodic transmission of IPv6 Router Solicit messages and reception of corresponding IPv6 Router Advertisement messages. The interval between IPv6 Router Solicit messages determines how quickly a host can react to changes in the IPv6 routing prefix. It is recommended that the default interval between IPv6 Router Solicit messages be no smaller than the minimum time between unsolicited IPv6 Router Advertisements (i.e. 3 seconds). [NOTE: The authors are interested in finding out from the WG what the WG believes the default interval between RS messages should be. One alternative value might be 10 minutes. Perhaps this value should be derived in part from one of the advertisement lifetimes carried in IPv6 Router Advertisement messages.] 3.3 Router Bootstrap Processing Initially, the router creates link-local IPv6 addresses using the above procedures to generate the local-identification token of the link-local address. Then the router configures the globally routable IPv6 addresses on those interfaces supporting IPv6 routing. Because it is a router, it already knows its global routing prefixes. The router then uses the NHRP Registration Request message(s) to register each of its globally routable addresses with the NHS. In the absence of a standards-track NHS synchronisation method, the router SHOULD register its IPv6 addresses for a given NBMA logical link with each known NHS for that NBMA logical link. The router MUST NOT register an IPv6 address belonging to one NBMA logical link with the NHS for a different NBMA logical link. Then, the router registers each IPv6 interface's lower-layer NBMA address and the IPv6 link-local all-routers multicast address with each appropriate NHS, taking care that the "uniqueness" bit is NOT set in in the NHRP Registration Request message. As above, the router MUST NOT register an interface's (lower-layer address, IPv6 link-local all-routers multicast address) pair with an NHS that does not serve that interface's NBMA logical link. If the IPv6 router is its own NHS and there is no other NHS for Atkinson, Haskin, & Luciani [Page 8] Internet Draft IPv6 over NBMA 14 November 1996 any of the attached NBMA logical links, then the above procedure can be internalised. If the IPv6 router is its own NHS and other NHSs exist for one or more of the attached NBMA logical links, then the above procedure needs to be followed only for the non-internal NHSs. 3.4 Neighbor Address Discovery Once bootstrapped using the above procedure, the host MUST use the NHRP Resolution Request and NHRP Resolution Response messages to obtain the lower layer address corresponding to any IPv6 unicast address not already having a lower-layer address known to the host. In the case where the target IPv6 address is associated with a node not on the attached NBMA network, NHRP will respond with the lower- layer NBMA address of the closest egress router to the node associated with the target IPv6 address. Thus, short-cut routing is automatically provided to IPv6 nodes connected via NBMA. 3.5 Redirects The ICMP Redirect messages defined for traditional IPv6 Neighbor Discovery are also used over NBMA networks.[NN95] Routers on NBMA networks MAY include the Target Link-Layer Address option in the ICMPv6 Redirect message if that target link- layer address is known. Routers MUST limit the rate at which ICMPv6 Redirect messages are sent, as is detailed in [CD96]. Routers SHOULD use the IPv6 Authentication Header or IPv6 Encapsulating Security Payload to authenticate ICMPv6 Redirect messages whenever an appropriate IP Security Association exists for the destination of such a message. Hosts on NBMA networks that receive a ICMPv6 Redirect message not containing a Target Link-Layer Address option via an NBMA interface MUST then use the NHRP Resolution Request procedure to determine the appropriate lower-layer address to use for the redirected IPv6 address. Nodes MAY ignore unauthenticated ICMPv6 Redirect messages. 3.6 Neighbor Unreachability Detection (NUD) Although the IPv6 Neighbor Solicit and Neighbor Advertisement messages are replaced by NHRP messages for the purpose of determining the lower-layer address of neighbors, the Neighbor Solicit and Neighbor Advertisement messages are retained for use in Neighbor Unreachability Detection. If the IPv6 Neighbor Solicit and Neighbor Advertisement exchanges indicate that a remote node has become unreachable, then the other node SHOULD send a NHRP Resolution Request message to Atkinson, Haskin, & Luciani [Page 9] Internet Draft IPv6 over NBMA 14 November 1996 attempt to determine the current reachability of the remote node. Over NBMA networks, the Neighbor Solicit and Neighbor Advertisement messages are always unicast and they are only used for the purpose of Neighbor Unreachability Detection after the existence of the neighbor was established via NHRP. The Source Link-layer Address Option MAY be used with Neighbor Solicit or Neighbor Advertisement messages over NBMA networks, however NHRP MUST be used for initial determination of lower-layer addresses except for the case of a received ICMPv6 Redirect containing a Target Link-Layer Address Option or for the case where manual configuration is supplied (e.g. an administratively configured host route). Neighbor Solicit and Neighbor Advertisement messages sent over NBMA networks MUST NOT contain either the unspecified address or a multicast address. Receipt of NHRP messages is considered reachability confirmation for the node whose IP address is associated with that lower-layer address. Otherwise, the process described in Sections 7.2.3, 7.2.4, 7.2.5, and 7.3 of [NN95] is followed. The NHRP Purge Request message is used to invalidate cached IPv6 to lower-layer NBMA address bindings in IPv6 nodes connected to the NBMA network.[KPCL95] Hence, the conceptual IPv6 "Neighbor Cache" entry corresponding to the address in the NHRP Purge Request message MUST be deleted (in an implementation-dependent way) by an IPv6 node that receives a valid NHRP Purge Request message for an IPv6 address. The conceptual IPv6 "Default Router List" entry corresponding to the address in the NHRP Purge Request message MUST be deleted (in an implementation-dependent way) by an IPv6 node that receives a valid NHRP Purge Request message for an IPv6 address that is known to be a router. Unsolicited Neighbor Advertisements are NOT sent over NBMA networks and section 7.2.6 of [NN95] does not apply to NBMA networks. Upon receipt of a valid NHRP Purge Request, a NHRP Purge Reply message MUST be sent unless the NHRP Purge Request explicitly indicates that it does not require a reply. [KPCL95] 4. LOWER-LAYER ENCAPSULATIONS The encapsulation method standardised in RFC-1483 shall be used for IPv6 traffic carried over ATM Adaptation Layer 5 (AAL 5).[Hei93] The encapsulation method standardised in RFC-1490 shall be used for IPv6 traffic carried over Frame Relay. [BBM93] The encapsulation method standardised in RFC-1356 shall be used for IPv6 traffic carried over X.25 and ISDN in the Packet Mode. [MRU92] The encapsulation method standardised in RFC-1209 shall be used for IPv6 traffic carried over SMDS.[PL91] NHRP traffic will always be encapsulated as described in [KPLC95]. Atkinson, Haskin, & Luciani [Page 10] Internet Draft IPv6 over NBMA 14 November 1996 In all of these cases, the SNAP NLPID encapsulation with the IPv6 EtherType (namely, 86DD hexadecimal) is used instead of using the IPv4 NLPID or SNAP NLPID with the IPv4 EtherType. This reduces the dependence on the IP version numbers, which is important because some historical IPv4 implementations have not dependably checked the version numbers of the packets. This will also add consistency to the IPv6 encapsulation methods used on the various NBMA media. On a virtual circuit carrying only IPv6, the IPv6 packets MAY be sent without a lower layer encapsulation (e.g. RFC-1483 VC-based multiplexing) provided that all nodes on that virtual circuit are configured to only send IPv6 over that virtual circuit.[Hei93] 5. CONFORMANCE REQUIREMENTS The term "conforming implementation" is defined to have the same meaning as "compliant implementation" for this specification. A conforming implementation of this specification MUST implement and comply with the Next-Hop Resolution Protocol (NHRP) as specified in [KPCL95], the Neighbor Discovery for IPv6 as specified in [NN95] except for the Neighbor Solicit and Neighbor Advertisement messages, the IPv6 Address Configuration as specified in [TN95] except as noted in this specification, and MUST follow the procedures and processes outlined in this document. In cases where one process is outlined in this document and a different conflicting process is outlined in [NN95] and/or [TN95], then the process described here is used over NBMA networks instead of the process described in those other documents. All conforming implementations of this specification MUST also implement the IP Security Architecture [Atk95a] and the IP Authentication Header [Atk95b] so that users are able to use cryptographic authentication. All conforming implementations SHOULD also implement the Internet Key Management Protocol (IKMP) once that has been published as a standards-track RFC. All conforming implementations of this specification MUST use the IP Authentication Header [Atk95b] to authenticate IPv6 Neighbor Discovery messages when an appropriate IPsec Security Association [Atk95a] exists. All conforming implementations of this specification MUST use the NHRP Authentication Extension to authenticate NHRP messages when an appropriate NHRP Security Association exists.[KPCL95] NHRP Security Associations based on MD5 MUST be preferred to NHRP Security Associations based on Cleartext Passwords in all conforming implementations. Atkinson, Haskin, & Luciani [Page 11] Internet Draft IPv6 over NBMA 14 November 1996 SECURITY CONSIDERATIONS Unlike traditional IPv6 Neighbor Discovery, NHRP is not built upon IP. This design decision was made so that NHRP can be used for multi-protocol networks and is not limited to IPv4 or IPv6 networks. Although this precludes the use of IP security mechanisms [Atk95a] [Atk95b] to authenticate NHRP, this is not a decrease in security relative to traditional IPv6 Neighbor Discovery because NHRP includes its own cryptographic authentication mechanism (NHRP's Authentication Type = 2) having similar security properties. Acceptance of unauthenticated NHRP response messages can lead to denial of service attacks. Use of the IP Authentication Header for IPv6 traffic can preclude IP-layer host masquerading attacks that would otherwise be possible if a node accepted unauthenticated NHRP response messages. Acceptance of unauthenticated ICMPv6 Neighbor Discovery messages can lead to various attacks. Use of the IP Authentication Header can preclude or significantly mitigate many of these attacks. Security issues specific to IP Security are discussed in [Atk95a] and [Atk95b]. Security issues specific to NHRP are discussed in [KPCL95]. Security issues specific to traditional IPv6 Neighbor Discovery are discussed in [NN95]. The reader is encouraged to read all of these for more information on security issues relating to this specification. ACKNOWLEDGEMENTS This document is largely based on the existing technology cited in the references. The author is obliged to the contributers to those drafts for helping to create that technology. The author wishes to thank (in alphabetical order) Bruce Cole, Francis Dupont, Bob Gilligan, Joel Halpern, Andy Malis, and Erik Nordmark for their review and critique of an earlier version of this draft. REFERENCES [Atk95a] Randall J. Atkinson, IP Security Architecture, RFC-1825, August 1995. [Atk95b] Randall J. Atkinson, IP Authentication Header, RFC-1826, August 1995. [BBM93] Terry Bradley, Caralyn Brown, & Andy Malis, "Multiprotocol Interconnect over Frame Relay", RFC-1490, July 1993. Atkinson, Haskin, & Luciani [Page 12] Internet Draft IPv6 over NBMA 14 November 1996 [CD96] Alex Conta & Steve Deering, "Internet Control Message Protocol for IPv6 (ICMPv6)", RFC-1885, January 1996. [DH96] Steve Deering & Robert Hinden, "Internet Protocol, version 6 Specification", RFC-1883, January 1996. [Hei93] Juha Heinanen, "Multiprotocol Encapsulation over ATM AAL 5", RFC-1483, July 1993. [KPCL95] Dave Katz, David Piscitello, Bruce Cole, & James V. Luciani, "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress, draft-ietf-rolc-nhrp-*.txt, December 1995. [MRU92] Andy Malis, David Robinson, & Robert Ullman, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC-1356, August 1992. [NN95] Thomas Narten & Erik Nordmark, "Neighbor Discovery for IPv6", work in progress, draft-ietf-ipngwg-discovery-*.txt, November 1995. [PL91] Dave Piscitello & Joseph Lawrence, "The Transmission of IP Datagrams over the SMDS Service.", RFC-1209, March 1991. [TN95] Susan Thomson & Thomas Narten, "IPv6 Stateless Address Autoconfiguration", draft-ietf-addrconf-ipv6-auto-*.txt, December 1995. Atkinson, Haskin, & Luciani [Page 13] Internet Draft IPv6 over NBMA 14 November 1996 DISCLAIMER The views and specifications here are those of the authors and are not necessarily those of their employers. AUTHOR INFORMATION Randall Atkinson cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA Telephone: +1 (408) 526-6566 Dimitry Haskin Bay Networks 2 Federal Street Billerica, MA 01821 USA Telephone: +1 (508) 436-8124 James V. Luciani Bay Networks 3 Federal Street Billerica, MA 01821 USA Telephone: +1 (508) 439-4734 Atkinson, Haskin, & Luciani [Page 14] --