[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                    Randall Atkinson
Internet Draft                                              cisco Systems
draft-ahl-ipv6-nbma-00.txt                                 Dimitry Haskin
                                                             Bay Networks
                                                            James Luciani
                                                             Ascom Nexion
                                                         15 February 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 Routing over Large Clouds and
   IETF IP:next generation working groups 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 Routing Over Large Clouds (ROLC)
   mailing list <rolc@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             15 February 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             15 February 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             15 February 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



Atkinson, Haskin, & Luciani                                     [Page 4]


Internet Draft               IPv6 over NBMA             15 February 1996


   be  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             15 February 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             15 February 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



Atkinson, Haskin, & Luciani                                     [Page 7]


Internet Draft               IPv6 over NBMA             15 February 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



Atkinson, Haskin, & Luciani                                     [Page 8]


Internet Draft               IPv6 over NBMA             15 February 1996


   for  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



Atkinson, Haskin, & Luciani                                     [Page 9]


Internet Draft               IPv6 over NBMA             15 February 1996


   the other node SHOULD send  a  NHRP  Resolution  Request  message  to
   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             15 February 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             15 February 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             15 February 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             15 February 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

   Telephone:      +1 (508) 436-8124


   James V. Luciani <luciani@nexen.com>
   Ascom Nexion
   289 Great Road
   Acton, MA 01720-4379
   USA

   Telephone:  +1 (508) 266-3450




















Atkinson, Haskin, & Luciani                                    [Page 14]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/