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

Versions: 00 02 03 04 rfc3122                            Standards Track
ION/IPng Working Groups                     A. Conta (Transwitch)
INTERNET-DRAFT
                                           July 2000


      Extensions to IPv6 Neighbor Discovery for Inverse Discovery

                             Specification

                     draft-ietf-ion-ipv6-ind-04.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

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










Conta                       Expires in six months   [Page 1]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


Table of Contents

1. Introduction......................................................3
2. Inverse Neighbor Discovery Messages...............................3
   2.1 Inverse Neighbor Discovery Solicitation Message...............3
   2.2 Inverse Neighbor Discovery Advertisement Message..............5
3. Inverse Neighbor Discovery Options Format.........................7
   3.1 Target Address List...........................................7
4. Inverse Neighbor Discovery Protocol...............................9
   4.1 Sender Node Processing.......................................10
   4.2 Receiver Node Processing.....................................10
     4.2.1 Processing Inverse Neighbor Discovery Solicitations......10
     4.2.2 Processing Inverse Neighbor Discovery Advertisements.....11
   4.3 Message Validation...........................................11
     4.3.1 Validation of Inverse Neighbor Discovery Solicitations...11
     4.3.2 Validation of Inverse Neighbor Discovery Advertisements..12
5. Security Considerations..........................................13
6. IANA Considerations..............................................13
7. Acknowledgments..................................................14
8. References.......................................................14
9. Authors' Addresses...............................................16
Appendix A..........................................................17





























Conta                       Expires in six months   [Page 2]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


1. Introduction


   This document defines extensions to the IPv6 Neighbor Discovery
   (ND)[IPv6-IND]. The extensions are called IPv6 Inverse Neighbor
   Discovery (IND).  The IPv6 Inverse Neighbor Discovery (IND) allows a
   node that knows the link-layer address of a directly connected remote
   node to learn the IPv6 addresses of that node. A node using IND sends
   solicitations and receives advertisements for one or more IPv6
   addresses corresponding to a known link-layer address.

   The Inverse Neighbor Discovery (IND) /specifically applies to/was
   developed for/ Frame Relay networks. It may apply also to other
   networks that have a similar behavior.

   The keywords MUST, MUST NOT, MAY, OPTIONAL,  REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT  are to be interpreted as
   defined in [KEYWORDS].

   There is a number of similarities and differences between the
   mechanisms described here and those defined for Inverse ARP for IPv4
   in [INV-ARP] or its replacement documents.


2. Inverse Neighbor Discovery Messages

   The following messages are defined:

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 [IPv6], [IPv6-FR], [ENCAPS]. 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 ...
     +-+-+-+-+-+-+-+-+-+-+-+-



Conta                       Expires in six months   [Page 3]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


   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. This address
                     is specified in its link-scope format, which is
                     FF02::1.


      Hop Limit      255

      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           [Value to be assigned by IANA]

      Note: The Type value should be assigned from the IPv6 Neighbor
      Discovery family of values.

      Code           0

      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:

   The sender node MUST send the following options in the Solicitation
   message:

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








Conta                       Expires in six months   [Page 4]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


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



   Other valid options:

   The sender node MAY choose to add the following options in the
   Solicitation message:

      Source Address List
                     The list of one or more IPv6 addresses of the
                     interface identified by the Source Link-Layer
                     Address. This option is defined in section 3.

      MTU            The MTU configured for this link [IPv6-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.



2.2   Inverse Neighbor Discovery Advertisement Message

   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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


   IP Fields:

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







Conta                       Expires in six months   [Page 5]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


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

      Hop Limit      255

      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.


   ICMP Fields:

      Type           [Value to be assigned by IANA]

      Note: The Type value should be assigned from the IPv6 Neighbor
      Discovery family of values.

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].


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

   Required options:

   The sender node MUST send the following options in the Advertisement
   message:

      Source Link-Layer Address
                     This field is copied from the Target link-layer
                     address field of the Inverse Neighbor Discovery
                     Solicitation.

      Target Link-Layer Address
                     This field is copied from the Source link-layer
                     address field of the Inverse Neighbor Discovery
                     Solicitation.








Conta                       Expires in six months   [Page 6]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


      Target Address List
                     The list of one or more IPv6 addresses of the
                     interface identified by the Target Link-Layer
                     Address in the Inverse Neighbor Discovery
                     Solicitation message that prompted this
                     advertisement. This option is defined in Section 3.


   Other valid options:

   The sender node MAY choose to add the following option in the
   Advertisement message:

      MTU            The MTU configured for this link
                     [IPv6-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 Options Formats

   Inverse Neighbor Discovery messages include Neighbor Discovery
   options [IPv6-ND] as well as an Inverse Neighbor Discovery specific
   options: the Source Address List and the Target Address List.


3.1  Source/Target Address List

   The Source Address List and the Target Address List option are TLV
   options (type, length, variable size field) (see Section 4.6 of
   [IPv6-ND] with the following fields:


















Conta                       Expires in six months   [Page 7]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


      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      |    Length   |                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        -       -       -        +
     |                          Reserved                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        IPv6 Address                           +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        IPv6 Address                           +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     ~
     |
     +-+-+-+-+...

   Fields:

      Type           [To be assigned by IANA] for Source Address List
                     [To be assigned by IANA] for Target Address List

      Note: These Option Type values should be assigned from the IPv6
      Neighbor Discovery family of values.

      Length         The length of the option (including the Type,
                     Length, and the Reserved fields) in units of 8
                     octets. The minimum value for Length is 3, for one
                     IPv6 address.

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







Conta                       Expires in six months   [Page 8]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


      IPv6 Addresses One or more IPv6 addresses of the interface.


   Description:

   The Source Address List contains a list of IPv6 addresses of the
   interface identified by the Source Link-Layer Address.

   The Target Address List contains a list of IPv6 addresses of the
   interface identified by the Target Link-Layer Address.

   The number of addresses "n" in the list is calculated based on the
   length of the option:

         n = (Length - 1)/2  (Length is the number of groups of 8 octets)

   The Source Address List MUST fit in one IND Solicitation message.
   Therefore in case all IPv6 addresses of an interface do not fit in
   one messages, the option does not contain a complete list. For a
   complete list of IPv6 addresses, a node should rely on the IND
   Advertisement message.

   The Target Address List SHOULD be the complete list of addresses of
   the interface identified by the Target Link-Layer Address. If the
   list of IPv6 addresses of an interface does not fit in one IND
   Advertisement message, one or more IND Advertisement messages, with
   the same fields as the first message, SHOULD follow. The Target
   Address List option(s) of the second, and subsequent message(s)
   SHOULD contain the rest of the IPv6 addresses of the interface
   identified by the Target Link-Layer Address, which did not fit in the
   first message.

   Note: An implementation MUST NOT send duplicates in the IPv6 address
   list.


4. Inverse Neighbor Discovery Protocol

   IND operates essentially the same as ND [IPv6-ND]: the solicitor of a
   target IP address sends on an interface a solicitation message, the
   target node responds with an advertisement message containing the
   information requested. The information learned MAY be stored in the
   Neighbor Discovery cache [IPv6-ND], as well as IPv6 address
   structures which may be associated with the interface.







Conta                       Expires in six months   [Page 9]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


4.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
   and sends it directly to the target node. Although the destination IP
   address is the all-node multicast address, the message is sent only
   to the target node. 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 in setting
   the optimum value of the MTU for the link.

   While awaiting a response, the sender SHOULD retransmit IND
   Solicitation messages approximately every RetransTimer
   (expiration)[IPv6-ND], even in the absence of additional traffic to
   the neighbor. Retransmissions MUST be rate-limited to at most one
   solicitation per neighbor every RetransTimer.

   If no IND  Advertisement is received after MAX_MULTICAST_SOLICIT
   [IPv6-ND] solicitations, inverse address resolution has failed. If
   the sending of the Solicitation was required by an upper-layer, the
   sender module MUST notify the error to the upper-layer through an
   appropriate mechanism (e.g. return value from a procedure call).

4.2  Receiver Node Processing


4.2.1  Processing Inverse Neighbor Solicitation Messages

   For every IND Solicitation, the receiving node SHOULD 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 updates the Neighbor Discovery Cache with information
   learned from IND messages, the receiver node of the IND Solicitation
   SHOULD 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 [IPv6-ND] as it would for a
   ND solicitation.

   Because IPv6 nodes may have multiple IPv6 addresses per interface, a
   node responding to an IND Solicitation SHOULD return in the Target
   Address List option a list containing one or more IPv6 addresses
   corresponding to the interface identified by the Target Link-Layer
   Address field in the solicitation message.  The list MUST not contain
   duplicates.





Conta                       Expires in six months  [Page 10]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


4.2.2  Processing Inverse Neighbor Advertisement Messages

   If a node updates The Neighbor Discovery Cache with information
   learned from IND messages, the receiver node of the IND advertisement
   SHOULD put the sender's IPv6 address/link-layer address mapping -
   i.e. the IP addresses from Target addresses list and the Source
   link-layer address from the IND advertisement  message - into its ND
   cache [IPv6-ND] as it would for a ND advertisement.


4.3  Message Validation

   Inverse Neighbor Discovery messages are validated as follows:


4.3.1  Validation of Inverse Neighbor Discovery Solicitations

   A node MUST silently discard any received Inverse Neighbor
   Solicitation messages that do not satisfy all of the following
   validity checks:


       -    The IP Hop Limit field has a value of 255, i.e., the packet
            could not possibly have been forwarded by a router.


       -    If the message includes an IP Authentication Header, the
            message authenticates correctly.


       -    ICMP Checksum is valid.


       -    ICMP Code is 0.


       -    ICMP length (derived from the IP length) is 24 or more
            octets.


       -    The Target Link-Layer Address is a required option and MUST
            be present.


       -    The Source Link-Layer Address is a required option and MUST
            be present.





Conta                       Expires in six months  [Page 11]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


       -    All included options have a length that is greater than
            zero.

   The content of the Reserved field, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved field or add new options;
   backward-incompatible changes may use different Code values.

   The contents of any Neighbor Discovery [IPv6-ND] options that are not
   specified to be used with Inverse Neighbor Discovery Solicitation
   messages MUST be ignored and the packet processed as normal. The only
   defined option that may appear besides the required options is the
   MTU option.

   An Inverse Neighbor Solicitation that passes the validity checks is
   called a "valid solicitation".


4.3.2  Validation of Inverse Neighbor Discovery Advertisements

   A node MUST silently discard any received Inverse Neighbor Discovery
   Advertisement messages that do not satisfy all of the following
   validity checks:


       -    The IP Hop Limit field has a value of 255, i.e., the packet
            could not possibly have been forwarded by a router.


       -    If the message includes an IP Authentication Header, the
            message authenticates correctly.


       -    ICMP Checksum is valid.


       -    ICMP Code is 0.


       -    ICMP length (derived from the IP length) is 48 or more
            octets.


       -    Source Link-Layer Address option is present.


       -    Target Link-Layer Address option is present.




Conta                       Expires in six months  [Page 12]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


       -    The Target Address List option is present.


       -    The length of the Target Address List option is at least 3.


       -    All other included options have a length that is greater
            than zero.

   The contents of the Reserved fields, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved fields or add new options;
   backward-incompatible changes may use different Code values.

   The contents of any defined options [IPv6-ND] that are not specified
   to be used with Inverse Neighbor Advertisement messages MUST be
   ignored and the packet processed as normal. The only defined option
   that may appear besides the required options is the MTU option.

   An Inverse Neighbor Advertisement that passes the validity checks is
   called a "valid advertisement".



5. Security Considerations

   When being employed on point to point virtual circuits, as it is the
   case with Frame Relay networks, Inverse Neighbor Discovery messages
   are less sensitive to impersonation attacks from on-link nodes, as it
   would be the case with broadcast links.

   Like Neighbor Discovery, the protocol reduces the exposure to threats
   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 [IPSEC-Auth].  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.




Conta                       Expires in six months  [Page 13]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


   Received Authentication Headers in Inverse 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 [IPSEC], [IPSEC-
   ESP].


6. IANA Considerations

   Values marked in previous sections  of this specification as "Value
   to be assigned by IANA", or "To be assigned by IANA" need to be
   assigned by IANA.

   The ICMP Type values should be assigned similarly to the other ICMP
   Type values. It is preffered to assign, if possible, an ICMP Type
   value from the IPv6 Neighbor Discvery family of values, that is,
   close or in sequential order with the ICMP Type values assigned for
   the IPv6 Neighbor Discovery.  No outside reviewing is necessary.

   The Option Type Value should be assigned similarly to the IPv6
   Neighbor Discovery Option Type values. It is preffered to assign, if
   possible, an Option Type value close or in sequential order with the
   Option Type values assigned to the IPv6 Neighbor Discovery.  No
   outside reviewing is necessary.


7. Acknowledgments

   Thanks to Steve Deering, Thomas Narten and Eric Nordmark for
   discussing the idea of Inverse Neighbor Discovery. Thanks to Thomas
   Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar,
   Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing.

   Also it should be acknowledged that parts of the text in this
   specification derived from the IPv6 Neighbor Discovery text [IPv6-
   ND].

8. References

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



Conta                       Expires in six months  [Page 14]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


   Specification", RFC 2460, December 1998.


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


   [ICMPv6] A. Conta, S. Deering "Internet Control Message Protocol for
   the Internet Protocol Version 6", RFC 2463, December 1998.


   [IPv6-FR] A. Conta, A. Malis, M. Mueller, "Transmission of IPv6
   Packets over Frame Relay networks" Work in Progress, December 1997.


   [IPSEC]    Atkinson, R., S. Kent, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.


   [IPSEC-Auth]  Atkinson, R., S. Kent, "IP Authentication Header", RFC
   2402, December 1998.


   [IPSEC-ESP]   Atkinson, R., S. Kent, "IP Encapsulating Security
   Protocol (ESP)", RFC 2406, November 1998.


   [ASSIGN]  J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700.


   [ENCAPS]  C. Brown, A. Malis, "Multiprotocol Interconnect over Frame
   Relay", RFC 2427, November 1998.


   [INV-ARP]  T. Bradley, C. Brown, A.Malis "Inverse Address Resolution
   Protocol",RFC 2390, August 1998


   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.











Conta                       Expires in six months  [Page 15]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


9. Authors' Addresses

   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484
   +1-203-929-8810
   email: aconta@txc.com











































Conta                       Expires in six months  [Page 16]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


Appendix A


A. Inverse Neighbor Discovery with Frame Relay Networks

   This appendix documents the details of using the Inverse Neighbor
   Discovery on Frame Relay Networks, which were too specific to be part
   of the more general content of the previous sections.


A.1  Introduction


   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). A DLCI has in general a local
   significance.

   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 used as
   the equivalent of a remote node link-layer address, allowing a node
   to identify at link layer level the node at the other end of the
   virtual circuit. For instance in Figure 1., node A (local node)
   identifies the virtual circuit to node B (remote node) by way of DLCI
   = 30. However, the signaling message does not contain information
   about the DLCI used by a remote node to identify the virtual circuit
   to the local node, which could be used as the equivalent of the local
   link-layer address. For instance in Figure 1., node B (remote node)
   may identify the virtual circuit to node A by way of DLCI = 62.

   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 identify the node, and more importantly discover the
   IPv6 addresses of the interface at the other end of the virtual
   circuit, identified by the remote link-layer address.









Conta                       Expires in six months  [Page 17]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


                           ~~~~~~~~~~~                 Remote
                          {           }                Node
        +-----+ DLCI     {             }         DLCI+-----+
        |  A  |-30------{--+----+----+--}---------62-|  B  |
        +-----+          {             }             +-----+
        Local             {           } Frame Relay
        Node               ~~~~~~~~~~~  Network Cloud

                    Figure 1.

   The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame
   Relay node to discover dynamically the DLCI by which a remote node
   identifies the virtual circuit. It also allows a node to learn the
   IPv6 addresses of a node at the remote end of a virtual circuit.


A.2. Inverse Neighbor Discovery Messages

   The Inverse Neighbor Discovery messages are generated by Frame Relay
   nodes as follows:

A.2.1. Inverse Neighbor Discovery Solicitation Message

   The sender of an Inverse Neighbor Discovery Solicitation does not
   know the remote node's IPv6 addresses, but knows the equivalent of a
   remote node link-layer address. Inverse Neighbor Discovery (IND)
   Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR],
   [ENCAPS]. However, at link layer level, an IND Solicitation is sent
   directly to the target node, identified by the known link-layer
   address (DLCI).

   The fields of the message which are filled following considerations
   specific to Frame Relay are:

   Source Link-Layer Address
      For the sender Frame Relay node, the Source Link-Layer Address is
      the equivalent of the link-layer address by which the remote node
      identifies the source of this message. The sender may have no
      knowledge of this information, and may leave this field empty.
      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 [IPv6-FR].

   Target Link-Layer Address
      For sender Frame Relay node, the Target Link-Layer Address field
      is filled with the value known as the equivalent of the target



Conta                       Expires in six months  [Page 18]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


      node link-layer address.  This value is the DLCI of the VC to the
      target node. It is encoded in DLCI format [IPv6-FR].

   To illustrate the generating of a IND Solicitation message by a Frame
   Relay node, let's consider as an example Node A (Figure 1.) which
   sends an IND solicitation to Node B. The Solicitation message fields
   will have the following values:

      At Node A (sender of the IND solicitation message).

             Source Link-Layer Address
                     DLCI=unknown (overwritten by the receiver).

             Target Link-Layer Address
                     DLCI=30.

      At Node B (receiver of the IND solicitation message).

             Source Link-Layer Address
                     DLCI=62 (filled in by the receiver).

             Target Link-Layer Address
                     DLCI=30.

   Note: For Frame Relay, both the above addresses are in Q.922 format
   (DLCI), which can have 10 (default), or 23 significant addressing
   bits [IPv6-FR]. 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 [IPv6-FR].

   MTU
      The value filled in the MTU option is the MTU for the virtual
      circuit identified by the known DLCI [IPv6-FR].


A.2.2  Inverse Neighbor Discovery Advertisement Message

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


   The fields of the message which are filled following considerations
   specific to Frame Relay are:

   The "Override" Bit in the message header.
      For Frame Relay, the Inverse Neighbor Discovery Advertisement



Conta                       Expires in six months  [Page 19]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


      messages unlike the Neighbor Discovery Advertisement messages
      carrying DLCI format link-layer addresses, SHOULD  have the
      Override bit "O", in the message header set to 1.

   Source Link-Layer Address
      For Frame Relay, this field is copied from the Target link-layer
      address field of the Inverse Neighbor Discovery Solicitation. It
      is encoded in DLCI format [IPv6-FR].

   Target Link-Layer Address
      For Frame Relay, this field is copied from the Source link-layer
      address field of the Inverse Neighbor Discovery Solicitation. It
      is encoded in DLCI format [IPv6-FR].

   For example if Node B (Figure 1.) responds to an IND solicitation
   sent by Node A. with an IND advertisement, these fields will have the
   following values:

      At Node B (sender of the advertisement message):

                 Source Link-Layer Address
                     DLCI=30 (was Target in Solicitation Message).

                  Target Link-Layer Address
                     DLCI=62 (was Source in Solicitation Message).

      At Node A (receiver of the advertisement message from B).

                  Source Link-Layer Address
                     DLCI=30 (was Target in Solicitation Message).

                  Target Link-Layer Address
                     DLCI=62 (was Source in Solicitation Message).

   Target Address List
      The list of one or more IPv6 addresses of the interface identified
      by the Target Link-Layer Address in the Inverse Neighbor Discovery
      Solicitation message that prompted this advertisement.

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

      Note:  In case of Frame Relay networks, the IND messages are sent
      on a virtual circuit, which acts like a virtual-link. If the
      virtual circuit breaks, all participants to the circuit receive
      appropriate link layer signaling messages, which can be propagated
      to the  upper layers, including IPv6.




Conta                       Expires in six months  [Page 20]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


A.3. Inverse Neighbor Discovery Protocol

     This section of the appendix documents only the specific aspects of
     Inverse Neighbor Discovery with Frame Relay Networks.

A.3.1  Sender Node Processing

   A soliciting Frame Relay node formats an IND solicitation message as
   defined in a previous section, encapsulates the packet for the Frame
   Relay link-layer [IPv6-FR] and sends it to the target Frame Relay
   node. Although the destination IP address is the IPv6 all-node
   multicast address, the message is sent only to the target Frame Relay
   node. The target node is the known remote node on the link
   represented by the virtual circuit.


A.3.2  Receiver Node Processing


A.3.2.1  Processing Inverse Neighbor Solicitation Messages

   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 formatted appropriately in the Source link-layer
   address field [IPv6-FR]. This operation is required to allow a
   correct interpretation of the fields in the further processing of the
   IND solicitation message.

   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.


A.3.2.2  Processing Inverse Neighbor Advertisement Messages

   The receiver Frame Relay node of the IND Advertisement MAY put the
   sender's IPv6 address/link-layer address mapping - i.e. the Target IP
   addresses and the Source link-layer address from the IND
   advertisement  message - into its ND cache [IPv6-ND] as it would for
   a ND Advertisement.

   Further, the receiver Frame Relay node of the IND Advertisement MAY
   store the Target link-layer address from the message as the DLCI
   value at the remote end of the VC. This DLCI value is the equivalent
   of the link-layer address by which the remote node identifies the
   receiver.



Conta                       Expires in six months  [Page 21]


INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery       July 13, 19100


   If the receiver node of the IND Advertisement has a pool of IPv6
   addresses, and if the implementation allows, it may take decisions to
   pairing specific local IPv6 addresses to specific IPv6 addresses from
   the target list in further communications on the VC.  More
   specifically, such a pairing may be based on IPv6 addresses being on
   the same subnet.













































Conta                       Expires in six months  [Page 22]

1298