[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]