doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc3122.txt b/doc/rfc/rfc3122.txt
new file mode 100644
index 0000000..4fd81cd
--- /dev/null
+++ b/doc/rfc/rfc3122.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                           A. Conta
+Request for Comments: 3122                        Transwitch Corporation
+Category: Standards Track                                      June 2001
+
+
+      Extensions to IPv6 Neighbor Discovery for Inverse Discovery
+                             Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo describes extensions to the IPv6 Neighbor Discovery that
+   allow a node to determine and advertise an IPv6 address corresponding
+   to a given link-layer address.  These extensions are called Inverse
+   Neighbor Discovery.  The Inverse Neighbor Discovery (IND) was
+   originally developed for Frame Relay networks, but may also apply to
+   other networks with similar behavior.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta                       Standards Track                     [Page 1]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+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....................... 6
+      3.1 Target Address List......................................... 6
+   4. Inverse Neighbor Discovery Protocol............................. 9
+      4.1 Sender Node Processing...................................... 9
+      4.2 Receiver Node Processing.................................... 9
+        4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
+        4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
+      4.3 Message Validation......................................... 10
+        4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
+        4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
+   5. Security Considerations........................................ 12
+   6. IANA Considerations............................................ 13
+   7. Acknowledgments................................................ 13
+   8. References..................................................... 13
+   9. Authors' Addresses............................................. 14
+   Appendix A........................................................ 15
+   Full Copyright Statement.......................................... 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta                       Standards Track                     [Page 2]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+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) was originally developed for
+   Frame Relay networks, but may also apply to other networks with
+   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 are 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                       Standards Track                     [Page 3]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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, then the sender SHOULD
+      include this header.
+
+   ICMP Fields:
+
+      Type           141
+
+      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.
+
+      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.
+
+
+
+
+Conta                       Standards Track                     [Page 4]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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.
+
+   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         142
+
+      Code         0
+
+      Checksum     The ICMP checksum.  See [ICMPv6].
+
+
+
+
+
+Conta                       Standards Track                     [Page 5]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+      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 The link-layer address of the sender.
+
+      Target Link-Layer Address
+         The link-layer address of the target, that is, the sender of
+         the advertisement.
+
+      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                       Standards Track                     [Page 6]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+    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           9 for Source Address List
+                    10 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.
+
+      IPv6 Addresses One or more IPv6 addresses of the interface.
+
+
+
+
+
+Conta                       Standards Track                     [Page 7]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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 1: The scope of the Inverse Neighbor Discovery mechanism is
+   limited to IPv6 address discovery, that is, providing address mapping
+   information.  Therefore, it does not make any provisions or rules
+   regarding how a node uses the addresses that were returned in an
+   Inverse Discovery message.  Furthermore, it does not exclude any
+   particular type of IPv6 address from the Source or Target Address
+
+   List.  For example, if an interface has manually configured, and
+   autoconfigured addresses, including temporary ones, unicast,
+   multicast, etc..., the list should not exclude any.
+
+   Note 2: An implementation MUST NOT send duplicates in the IPv6
+   address list.
+
+
+
+
+
+
+
+
+
+Conta                       Standards Track                     [Page 8]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+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.
+
+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.
+
+
+
+
+Conta                       Standards Track                     [Page 9]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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.
+
+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.
+
+   -     All included options have a length that is greater than
+         zero.
+
+
+
+
+Conta                       Standards Track                    [Page 10]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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.
+
+   -     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.
+
+
+
+Conta                       Standards Track                    [Page 11]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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.
+
+   Received Authentication Headers in Inverse Neighbor Discovery packets
+   MUST be verified for correctness and packets with incorrect
+   authentication MUST be ignored.
+
+   In case of use with Frame Relay, to avoid an IP Security
+   Authentication verification failure, the Frame Relay specific
+   preprocessing of a Neighbor Discovery Solicitation message that
+   contains a DLCI format Source link-layer address option, MUST be done
+   by the receiver node after it completed IP Security processing.
+
+   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.
+
+
+
+
+Conta                       Standards Track                    [Page 12]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   Confidentiality issues are addressed by the IP Security Architecture
+   and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-
+   ESP].
+
+6. IANA Considerations
+
+   IANA was requested to assign two new ICMPv6 type values, as described
+   in Section 2.1 and 2.2.  They were assigned from the Informational
+   range of messages, as defined in Section 2.1 of RFC 2463.  There were
+   no ICMPv6 code values defined for these types (other than 0); future
+   assignments are to be made under Standards Action as defined in RFC
+   2434.
+
+   IANA was also requested to assign two new ICMPv6 Neighbor Discovery
+   Option types as defined in Section 3.1.  No outside reviewing was
+   necessary.
+
+7. Acknowledgments
+
+   Thanks to Steve Deering, Thomas Narten and Erik 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]        Deering, S. and R. Hinden, "Internet Protocol Version 6
+                 Specification", RFC 2460, December 1998.
+
+   [IPv6-ND]     Narten, T., Nordmark, E. and W. Simpson "Neighbor
+                 Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                 1998.
+
+   [ICMPv6]      Conta, A., and S. Deering "Internet Control Message
+                 Protocol for the Internet Protocol Version 6", RFC
+                 2463, December 1998.
+
+   [IPv6-FR]     Conta, A., Malis, A. and M. Mueller, "Transmission of
+                 IPv6 Packets over Frame Relay Networks", RFC 2590, May
+                 1999. December 1997.
+
+   [IPSEC]       Atkinson, R. and S. Kent, "Security Architecture for
+                 the Internet Protocol", RFC 2401, November 1998.
+
+
+
+
+Conta                       Standards Track                    [Page 13]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   [IPSEC-Auth]  Atkinson, R. and S. Kent, "IP Authentication Header",
+                 RFC 2402, December 1998.
+
+   [IPSEC-ESP]   Atkinson, R. and S. Kent, "IP Encapsulating Security
+                 Protocol (ESP)", RFC 2406, November 1998.
+
+   [ASSIGN]      Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
+                 RFC 1700, March 1994.
+
+   [ENCAPS]      Brown, C. and A. Malis, "Multiprotocol Interconnect
+                 over Frame Relay", RFC 2427, November 1998.
+
+   [INV-ARP]     Bradley, T., Brown, C. and 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.
+
+9. Authors' Addresses
+
+   Alex Conta
+   Transwitch Corporation
+   3 Enterprise Drive
+   Shelton, CT 06484
+
+   Phone: +1-203-929-8810
+   EMail: aconta@txc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta                       Standards Track                    [Page 14]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+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.  The Inverse Neighbor Discovery is 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                       Standards Track                    [Page 15]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+                              ~~~~~~~~~~~                 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
+
+   Frame Relay nodes generate Inverse Neighbor Discovery messages 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.  If the sender knows the
+      information, it SHOULD include it in the field, otherwise it
+      SHOULD live it zero (empty).  This information, if present, can be
+      used for network debugging purposes.  Regardless of the sender's
+      action on this field, 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].
+
+
+
+
+
+
+Conta                       Standards Track                    [Page 16]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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
+      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:
+
+
+
+
+
+Conta                       Standards Track                    [Page 17]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+   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.
+
+A.3. Inverse Neighbor Discovery Protocol
+
+   This section of the appendix documents only the specific aspects of
+   Inverse Neighbor Discovery with Frame Relay Networks.
+
+
+
+
+Conta                       Standards Track                    [Page 18]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+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.
+
+   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, that is having the same prefix.
+
+
+
+
+Conta                       Standards Track                    [Page 19]
+
+RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta                       Standards Track                    [Page 20]
+