Internet Draft






ION/IPng Working Groups                     A. Conta (Lucent)
INTERNET-DRAFT
                                            November 1997


      Extensions to IPv6 Neighbor Discovery for Inverse Discovery

                             Specification

                    draft-conta-ion-ipv6-ind-00.txt


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  six
   months.  Internet-Drafts  may  be  updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to  use  Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To learn the current status of any Internet-Draft, please  check  the
   ``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).

   Distribution of this memo is unlimited.

Abstract

   This memo describes extensions to the IPv6  Neighbor  Discovery  that
   allow   a   node  to  solicit  and  be  advertised  an  IPv6  address
   corresponding to a given link-layer  address.  These  extensions  are
   called  Inverse  Neighbor Discovery. They specifically apply to Frame
   Relay networks but they may also apply to other networks with similar
   behavior.


1. Introduction


   This document defines extensions to the IPv6 Neighbor Discovery  (ND)
   that  allow  a  node  to  solicit  and  be advertised an IPv6 address



Conta & Malis                  Expires in six months[Page 1]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


   corresponding to a  known  link-layer  address.  The  extensions  are
   called Inverse Neighbor Discovery.

   The Inverse Neighbor Discovery (IND) specifically  applies  to  Frame
   Relay  nodes.   Frame  Relay  permanent  virtual  circuits (PVCs) and
   switched virtual circuits (SVCs) are  identified  in  a  Frame  Relay
   network  by  a  Data  Link  Connection  Identifier  (DLCI). Each DLCI
   defines for a Frame Relay node a single  virtual  connection  through
   the wide area network (WAN).

   By way of specific signaling messages,  a  Frame  Relay  network  may
   announce to a node a new virtual circuit with its corresponding DLCI.
   The DLCI  identifies  to  a  node  a  virtual  circuit,  and  can  be
   considered  the  equivalent  of  a  remote  node  link-layer address,
   allowing a node to address at link layer level the node at the  other
   end  of  the virtual circuit. However, the signaling message does not
   contain information about the identifier used by  a  remote  node  to
   identify  the  node, which would be the equivalent of the local link-
   layer address. Furthermore, the message being  transmitted  at  link-
   layer  level and completely independent of the IPv6 protocol does not
   include any IPv6 addressing information. Therefore  it  seems  to  be
   useful  to  define  a  protocol  that  allows  a  Frame Relay node to
   discover the equivalent of a local link layer address, that  is,  the
   identifier  by  way  of which remote nodes address the node, and more
   importantly discover based on a known remote link  layer  address  an
   IPv6 address of a node at the other end of the virtual circuit.

   The IPv6 Inverse Neighbor Discovery (IND) protocol  defined  by  this
   document  allows  a Frame Relay node to discover dynamically the DLCI
   by way of which a remote node identifies the virtual circuit as  well
   an  IPv6  address of a remote node associated with a virtual circuit.
   These mechanisms can be used with other links that similar  to  Frame
   Relay provide to nodes information equivalent to destination (remote)
   data link-layer addresses without indicating the  corresponding  IPv6
   addresses.

   The keywords MUST, MUST NOT, MAY, OPTIONAL,   REQUIRED,  RECOMMENDED,
   SHALL,  SHALL  NOT,  SHOULD,  SHOULD  NOT   are  to be interpreted as
   defined in RFC 2119.

   There is  a  number  of  similarities  and  differences  between  the
   mechanisms described here and those defined for InARP for IPv4 in RFC
   1293, or its replacing documents.


2. Inverse Neighbor Discovery Messages

   The following messages are defined:



Conta & Malis                  Expires in six months[Page 2]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


2.1.  Inverse Neighbor Discovery Solicitation Message

   A node sends an Inverse Neighbor Discovery  Solicitation  message  to
   request  an IPv6 address corresponding to a link-layer address of the
   target node while also providing its own link-layer  address  to  the
   target.  Since  the remote node IPv6 addresses are not known, Inverse
   Neighbor Discovery (IND) Solicitations  are  sent  as  IPv6  all-node
   multicasts. However, at link layer level, an IND Solicitation is sent
   directly to the target  node,  identified  by  the  known  link-layer
   address.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


   IP Fields:

      Source Address
                     An IPv6 address  assigned  to  the  interface  from
                     which this message is sent.

      Destination Address
                     The IPv6 all-node multicast address.


      Hop Limit      255

      Priority       15

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header   exists   between   the   sender   and  the
                     destination link-layer  address,  then  the  sender
                     SHOULD include this header.


   ICMP Fields:

      Type           [TBD]

      Code           0



Conta & Malis                  Expires in six months[Page 3]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


      Checksum       The ICMP checksum.  See [ICMPv6].

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender  and  MUST  be  ignored  by  the
                     receiver.

   Required options:

      Source Link-Layer Address
                     The link-layer address of the sender.

                     For Frame Relay, the sender may have  no  knowledge
                     of  the  information  that  indicates to the remote
                     node the equivalent of the  link-layer  address  of
                     the  source of this message. Therefore prior to any
                     Inverse Neighbor Discovery processing, the receiver
                     of this message replaces this field, whether filled
                     in or not by the sender, with  information  carried
                     by  the  Frame  Relay header in the DLCI field. The
                     field is encoded  in  DLCI  format  as  defined  by
                     [IPv6FR].

      Target Link-Layer Address
                     The link-layer address of the target node.

                     For Frame Relay, this  field  is  filled  with  the
                     value  known to the sender as the equivalent of the
                     target node link-layer  address,  encoded  in  DLCI
                     format [IPv6FR].


      Note: For Frame Relay, both  the  above  addresses  are  in  Q.922
      format  (DLCI), which can have 10 (default), 17, or 23 significant
      addressing bits [IPv6FR]. The option length  (link-layer  address)
      is expressed in 8 octet units, therefore, the DLCI will have to be
      extracted from the 8 bytes based on the EA field (bit  0)  of  the
      second,  third,  or  forth octet (EA = 1). The C/R, FECN, BECN, DE
      fields in the Q.922 address have no significance for IND  and  are
      set to 0 [IPv6FR].


   Options:

      MTU            The MTU configured for this link [ND]
                     For Frame Relay is the MTU for this virtual circuit
                     [IPv6FR].

   Future  versions  of  this  protocol  may  add  other  option  types.



Conta & Malis                  Expires in six months[Page 4]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


   Receivers  MUST silently ignore any options they do not recognize and
   continue processing the message.



2.2   Inverse Neighbor Discovery Advertisement Message Format

   A node sends Inverse Neighbor Discovery Advertisements in response to
   Inverse Neighbor Discovery Solicitations.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|S|O|                     Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Target Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


   IP Fields:

      Source Address
                     An address assigned to the interface from which the
                     advertisement is sent.

      Destination Address
                     The Source Address of an invoking Inverse Discovery
                     Neighbor Solicitation.

      Hop Limit      255

      Priority       15

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header   exists   between   the   sender   and  the
                     destination address, then the sender SHOULD include
                     this header.



Conta & Malis                  Expires in six months[Page 5]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


   ICMP Fields:

      Type           [TBD]

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      R              Router flag. Defined for compatibility
                     with Neighbor Discovery advertisement messages.  It
                     is not used. It MUST be clear.

      S              Solicited flag. Defined for compatibility with
                     Neighbor Discovery advertisement  messages.  It  is
                     used mostly with Neighbor Unreachability Detection.
                     It is not used by IND. It MUST be clear.

   Note:

   In case of Frame Relay, this message is sent on  a  virtual  circuit,
   which acts like a virtual-link. If it brakes, all participants to the
   circuit receive appropriate link layer signaling messages, which  can
   be  propagated  to  the   upper layers, including IPv6. Consequently,
   Neighbor Unreachability Detection is a mechanism that is  superfluous
   and therefore less useful than for datagram oriented links.

      O              Override flag.  When set, the O-bit indicates that
                     the advertisement should override an existing cache
                     entry  and  update  the cached mapping of the link-
                     layer address to IPv6 address. When it is  not  set
                     the  advertisement  will  not update a cached link-
                     layer address to IPv6  address  mapping  though  it
                     will  update  an  existing Neighbor Cache entry for
                     which no IPv6 address is known.  It SHOULD be set.

   Note:

   For  Frame  Relay,  the  Inverse  Neighbor  Discovery   Advertisement
   messages   unlike   the  Neighbor  Discovery  Advertisement  messages
   carrying DLCI format link-layer addresses, SHOULD  have a "O" bit set
   to 1.

      Reserved       29-bit unused field. It MUST be initialized to
                     zero by the sender  and  MUST  be  ignored  by  the
                     receiver.






Conta & Malis                  Expires in six months[Page 6]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


      Target Address
                     The IPv6 address corresponding to the Target  Link-
                     Layer  Address  in  the  Inverse  Neighbor Discover
                     Solicitation    message    that    prompted    this
                     advertisement.
   Required options:

      Source Link-Layer Address
                     The  link-layer  address  of  the  sender  of  this
                     message.

                     For Frame Relay, the sender link-layer  address  is
                     filled  with  the DLCI value of the virtual circuit
                     known to the sender of this message.  The field  is
                     in DLCI format as defined by [IPv6FR].

      Target Link-Layer Address
                     The  link-layer  address  of  the  sender  of  this
                     message.

                     For Frame Relay, this  field  is  copied  from  the
                     Inverse   Neighbor  Discovery  Solicitation  Target
                     link-layer address field. It  is  encoded  in  DLCI
                     format [IPv6FR].


   Options

      MTU            The MTU configured for this link
                     (virtual circuit) [ND].

   Future  versions  of  this  protocol  may  add  other  option  types.
   Receivers  MUST silently ignore any options they do not recognize and
   continue processing the message.


3. Inverse Neighbor Discovery Protocol

   IND operates essentially the same as ND. The solicitor of a target IP
   address  sends  a solicitation message, the target node responds with
   an advertisement message containing the information requested.


3.1  Sender Node Processing

   A soliciting node formats an IND solicitation message as defined in a
   previous section, encapsulates the packet for the specific link-layer
   [IPv6FR] and sends it directly  to  the  target  node.  Although  the



Conta & Malis                  Expires in six months[Page 7]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


   destination IP address is the all-node multicast address, the message
   is sent only to the target node.  In the case  of  Frame  Relay,  the
   target  node  is the known remote node on the link represented by the
   virtual circuit. The significant fields for the IND protocol are  the
   Source  IP  address,  the Source link-layer address, the Target link-
   layer address, and the MTU. The latter can be used to set the optimum
   value of the MTU for the link.


3.2  Receiver Node Processing

   A Frame Relay node, before further processing, is  replacing  in  the
   Source link-layer address the existent DLCI value with the DLCI value
   from the Frame Relay header of the frame containing the message.  The
   DLCI  value has to be formated appropriately in the Source link-layer
   address field [IPv6FR]. This operation is required to allow a correct
   interpretation  of  the  fields  in the further processing of the IND
   solicitation message.

   For every IND solicitation, the receiving node may format in response
   a  proper  IND  advertisement  using the link-layer source and target
   address pair as  well  as  the  IPv6  source  address  from  the  IND
   solicitation  message. If a node is unable or unwilling to advertise,
   it ignores the solicitation.

   Further, the receiver node may put the  sender's  IPv6  address/link-
   layer  address  mapping  -  i.e. the source IP address and the Source
   link-layer address from the solicitation message - into its ND  cache
   as it would for a ND solicitation.

   For a Frame Relay node, the MTU value from the  solicitation  message
   MAY  be  used  to  set  the  receiver's  MTU  to a value that is more
   optimal,  in  case  that  was  not  already  done  at  the  interface
   configuration time.

   Because IPv6 nodes may have multiple IPv6 addresses per interface,  a
   node  responding  to  an IND solicitation MAY select the IPv6 address
   which has the same prefix as the solicitor's node IPv6 address.



4. Security Considerations

   Being employed on point to point virtual  circuits  Inverse  Neighbor
   Discovery  messages  are  not sensitive to impersonation attacks from
   on-link nodes.

   Like Neighbor Discovery, the protocol reduces the exposure to threats



Conta & Malis                  Expires in six months[Page 8]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


   from  off-link nodes in the absence of authentication by ignoring IND
   packets received from off-link senders.  The Hop Limit field  of  all
   received packets is verified to contain 255, the maximum legal value.
   Because routers decrement the Hop Limit on all packets they  forward,
   received  packets  containing a Hop Limit of 255 must have originated
   from a neighbor.

   Inverse  Neighbor  Discovery  protocol  packet   exchanges   can   be
   authenticated  using the IP Authentication Header [RFC 1826].  A node
   SHOULD include an Authentication Header when sending Inverse Neighbor
   Discovery  packets  if  a  security  association  for use with the IP
   Authentication  Header  exists  for  the  destination  address.   The
   security   associations   may   have   been  created  through  manual
   configuration  or  through  the  operation  of  some  key  management
   protocol.

   Received Authentication Headers in Neighbor Discovery packets MUST be
   verified  for  correctness  and packets with incorrect authentication
   MUST be ignored.

   It SHOULD be possible for the system  administrator  to  configure  a
   node  to  ignore any Inverse Neighbor Discovery messages that are not
   authenticated using either the Authentication Header or Encapsulating
   Security   Payload.   Such   a  switch  SHOULD  default  to  allowing
   unauthenticated messages.

   Confidentiality issues are addressed by the IP Security  Architecture
   and  the  IP  Encapsulating Security Payload documents [RFC 1825, RFC
   1827].


5. Acknowledgments

   Thanks to Thomas Narten and Eric Nordmark who spent  time  discussing
   the   idea   of  Inverse  Neighbor  Discovery.  Also  thanks  to  Dan
   Harrington,  Milan  Merhar,  and  Martin  Mueller  for   a   thorough
   reviewing.


6. References

   [IPv6]  S.  Deering,  R.  Hinden,  "Internet   Protocol   Version   6
   Specification"


   [ND] T. Narten, E. Nordmark, W.Simpson  "Neighbor  Discovery  for  IP
   Version 6 (IPv6)"




Conta & Malis                  Expires in six months[Page 9]




INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery    November 17, 1997


   [IPv6FR] A. Conta,  A.  Malis,  M.  Mueller,  "Transmission  of  IPv6
   Packets over Frame Relay networks" <draft-conta-ion-ipv6-fr-00.txt>


   [RFC-1825] R.  Atkinson,  "Security  Architecture  for  the  Internet
   Protocol"


   [RFC-1826] R. Atkinson, "IP Authentication Header"


   [RFC-1827] R. Atkinson.  "IP Encapsulating Security Payload (ESP)".


   [RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers"


   [ENCAPS]C. Brown, A. Malis, "Multiprotocol  Interconnect  over  Frame
   Relay", <draft-ietf-ion-fr-update-03.txt>.


   [RFC-1293]  T.  Bradley,  C.  Brown,  "Inverse   Address   Resolution
   Protocol", 1/1992

7. Authors' Addresses


   Alex Conta
   Lucent Technologies Inc.
   300 Baker Ave, Suite 100
   Concord, MA 01742
   +1-508-287-2842
   email: aconta@lucent.com


















Conta & Malis                  Expires in six months[Page 10]

590