Network Working Group Randall Atkinson
Internet Draft cisco Systems
draft-ietf-ion-ipv6-nbma-00.txt Dimitry Haskin
Expire in six months James Luciani
Bay Networks
4 June 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 <ipng@sunroof.eng.sun.com> and also the
Internetworking over NBMA (ION) mailing list <ion@nexen.com>.
ABSTRACT
This draft proposes an 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 4 June 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 4 June 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 4 June 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 4 June 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 4 June 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.
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
to the Next-Hop Server (NHS). The NHS will respond with an NHRP
Atkinson, Haskin, & Luciani [Page 6]
Internet Draft IPv6 over NBMA 4 June 1996
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
Entries Extension" will be included with the NHRP Resolution Reply if
Atkinson, Haskin, & Luciani [Page 7]
Internet Draft IPv6 over NBMA 4 June 1996
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
any of the attached NBMA logical links, then the above procedure can
Atkinson, Haskin, & Luciani [Page 8]
Internet Draft IPv6 over NBMA 4 June 1996
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
attempt to determine the current reachability of the remote node.
Atkinson, Haskin, & Luciani [Page 9]
Internet Draft IPv6 over NBMA 4 June 1996
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].
In all of these cases, the SNAP NLPID encapsulation with the
IPv6 EtherType (namely, 86DD hexadecimal) is used instead of using
Atkinson, Haskin, & Luciani [Page 10]
Internet Draft IPv6 over NBMA 4 June 1996
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 4 June 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 4 June 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 4 June 1996
DISCLAIMER
The views and specifications here are those of the authors and are not
necessarily those of their employers.
AUTHOR INFORMATION
Randall Atkinson <rja@cisco.com>
cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Telephone: +1 (408) 526-6566
Dimitry Haskin <dhaskin@BayNetworks.com>
Bay Networks
2 Federal Street
Billerica, MA 01821
USA
Telephone: +1 (508) 436-8124
James V. Luciani <luciani@baynetworks.com>
Bay Networks
3 Federal Street
Billerica, MA 01821
USA
Telephone: +1 (508) 439-4734
Atkinson, Haskin, & Luciani [Page 14]
