From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3122.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc3122.txt (limited to 'doc/rfc/rfc3122.txt') 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] + -- cgit v1.2.3