RFC 3122
Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
RFC 3122 🎀
Okay bestie, so this is RFC 3122 ✨, called "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification." It came out of the Network Working Group and was written by A. Conta at Transwitch Corporation. It's a Standards Track doc, dated June 2001 📅. The title block doesn't list anything it obsoletes or updates, so nothing to track there 💅.
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 🌸.
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.......................................... 201. Introduction 🧚
Okay so this doc 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) lets a node that knows the link-layer address of a directly connected remote node learn that node's IPv6 addresses 🔥. 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 🙋♀️
Main character moment: a node sends an Inverse Neighbor Discovery Solicitation message to request an IPv6 address corresponding to a link-layer address of the target node, and while it's at it, it also gives the target its own link-layer address 💅. Since the remote node's IPv6 addresses aren't known yet, IND Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], [ENCAPS]. Lowkey clever, though: at link layer level, an IND Solicitation goes 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-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: 255Authentication 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: 141Code: 0Checksum: 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.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: 255Authentication 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: 142Code: 0Checksum: 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: 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 🌸.
Part 1 of 4 is done, bestie 🫶💜. Part 2 is coming next, so stay tuned 🦋✨
3.1. Source/Target Address List
okay so the Source Address List and the Target Address List are both TLV options (type, length, variable size field) (see Section 4.6 of [IPv6-ND]) and they look like this 🎀:
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...Here's the field rundown:
Type:9for Source Address List,10for 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 forLengthis3, 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.
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 from 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. So if all the IPv6 addresses of an interface don't fit in one message, the option won't carry 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 that list doesn't 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, the ones that didn't 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. So it doesn't make any provisions or rules about how a node uses the addresses that were returned in an Inverse Discovery message. It also doesn't 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. 🚫
4. Inverse Neighbor Discovery Protocol ✨
IND works essentially the same way as ND [IPv6-ND] does: the solicitor of a target IP address sends a solicitation message on an interface, and the target node responds with an advertisement message containing the information that was requested. 🦋 The information learned MAY be stored in the Neighbor Discovery cache [IPv6-ND], as well as in IPv6 address structures that 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. Even though the destination IP address is the all-node multicast address, the message is only sent 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 MTU can be used to set the optimum value of the MTU for the link.
While waiting for a response, the sender SHOULD retransmit IND Solicitation messages approximately every RetransTimer (expiration) [IPv6-ND], even when there's no other 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 an upper-layer required the Solicitation to be sent, 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 a proper IND Advertisement in response, 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], just as it would for an 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. 🌸
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 the Target Address List and the Source link-layer address from the IND advertisement message) into its ND cache [IPv6-ND], just as it would for an ND advertisement. 🧚
4.3. Message Validation
Inverse Neighbor Discovery messages get validated like this:
4.3.1. Validation of Inverse Neighbor Discovery Solicitations
A node MUST silently discard any received Inverse Neighbor Solicitation message that doesn't pass all of the following validity checks: 🚨
- The
IP Hop Limitfield 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.
- The ICMP Checksum is valid.
- The ICMP Code is 0.
- The 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.
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 is 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 message that doesn't pass all of the following validity checks: 💀
- The
IP Hop Limitfield 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.
- The ICMP Checksum is valid.
- The ICMP Code is 0.
- The ICMP length (derived from the IP length) is 48 or more octets.
- The Source Link-Layer Address option is present.
- The 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.
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 is 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 🔐
So here's the vibe check: when Inverse Neighbor Discovery runs on point to point virtual circuits, like Frame Relay networks do, the messages are less sensitive to impersonation attacks from on-link nodes than they would be on a broadcast link. Lowkey a relief! 🦋
Like Neighbor Discovery, this protocol cuts down the exposure to threats from off-link nodes even without authentication, because it ignores IND packets that come from off-link senders. The Hop Limit field of every received packet is checked to contain 255, the maximum legal value. Routers decrement the Hop Limit on every packet they forward, so a received packet with a Hop Limit of 255 has to have come from a neighbor. That's the bouncer checking the guest list! 💅
Inverse Neighbor Discovery protocol exchanges can be authenticated with the IP Authentication Header [IPSEC-Auth]. A node SHOULD include an Authentication Header when it sends Inverse Neighbor Discovery packets, as long as a security association for the IP Authentication Header exists for the destination address. Those security associations may have been set up through manual configuration or through 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. No exceptions, bestie! 🚫
If you're using Frame Relay, watch out for this one 👀 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. Order matters, periodt!
It SHOULD be possible for the system administrator to configure a node to ignore any Inverse Neighbor Discovery messages that aren't authenticated using either the Authentication Header or Encapsulating Security Payload. That switch SHOULD default to allowing unauthenticated messages. 🎀
Confidentiality is handled by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-ESP]. 🔒
6. IANA Considerations 📋
IANA was asked to assign two new ICMPv6 type values, as described in Section 2.1 and 2.2. They came 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 asked to assign two new ICMPv6 Neighbor Discovery Option types, as defined in Section 3.1. No outside review was needed. ✅
7. Acknowledgments 🫶
Big thanks to Steve Deering, Thomas Narten and Erik Nordmark for talking through the idea of Inverse Neighbor Discovery. Thanks also to Thomas Narten, Erik Nordmark, and to Dan Harrington, Milan Merhar, Barbara Fox, Martin Mueller, and Peter Tam for doing a thorough review. The whole squad! 💜
It should also be acknowledged that parts of the text in this specification came from the IPv6 Neighbor Discovery text [IPv6-ND]. Credit where it's due 🙌
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.
- [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.comAppendix A
A. Inverse Neighbor Discovery with Frame Relay Networks 🌈
This appendix digs into the details of using Inverse Neighbor Discovery on Frame Relay Networks. They were too specific to fit in the more general content of the previous sections, so they live here, bestie. 🧚
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 a single virtual connection through the wide area network (WAN) for a Frame Relay node. A DLCI generally has local significance. 🍓
Through specific signaling messages, a Frame Relay network can tell a node about a new virtual circuit and its corresponding DLCI. The DLCI identifies the virtual circuit to a node and can be used as the equivalent of a remote node link-layer address, so a node can identify, at the link layer, 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. The signaling message doesn't say which DLCI the remote node uses to identify the virtual circuit to the local node, and that DLCI could serve 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. 🤔
Also, the message is sent at the link layer, totally independent of IPv6, so it doesn't carry any IPv6 addressing information. This is where Inverse Neighbor Discovery comes in: it lets a Frame Relay node discover the equivalent of a local link-layer address (the identifier that remote nodes use to 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. Main character energy! ✨
~~~~~~~~~~~ Remote
{ } Node
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Local { } Frame Relay
Node ~~~~~~~~~~~ Network Cloud
Figure 1.The IPv6 Inverse Neighbor Discovery (IND) protocol lets a Frame Relay node dynamically discover the DLCI by which a remote node identifies the virtual circuit. It also lets a node 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 doesn't know the remote node's IPv6 addresses, but it does know 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 the link layer, an IND Solicitation is sent directly to the target node, identified by the known link-layer address (DLCI). 🎯
These are the fields of the message. Frame Relay considerations determine how they're filled in:
- Source Link-Layer Address For the sender Frame Relay node, the Source Link-Layer Address is the equivalent of the link-layer address that the remote node uses to identify the source of this message. The sender may have no idea what this is. If the sender does know it, it SHOULD include it in the field. Otherwise, it SHOULD set it to zero (empty). If present, this information can be used for network debugging purposes. Either way, before any Inverse Neighbor Discovery processing, the receiver of this message replaces this field, whether the sender filled it in or not, with the 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 the 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. That value is the DLCI of the VC to the target node. It's encoded in DLCI format [IPv6-FR].
To show how a Frame Relay node generates an IND Solicitation message, let's use Node A (Figure 1) as an example. Node A 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 of 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, so the DLCI has to be extracted from the 8 bytes based on the EA field (bit 0) of the second, third, or fourth 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 ✨
okay so a Frame Relay node sends Inverse Neighbor Discovery Advertisements as the reply to Inverse Neighbor Discovery Solicitations 💌
these fields get filled in with Frame Relay stuff in mind:
Source Link-Layer Address: for Frame Relay, this gets copied from theTarget link-layer addressfield of the Inverse Neighbor Discovery Solicitation. It's encoded in DLCI format [IPv6-FR].Target Link-Layer Address: for Frame Relay, this gets copied from theSource link-layer addressfield of the Inverse Neighbor Discovery Solicitation. It's encoded in DLCI format [IPv6-FR].
so for an example, say Node B (Figure 1.) answers an IND solicitation from Node A with an IND advertisement. the values look like this 🦋
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 Frame Relay networks, the IND messages get sent on a virtual circuit, which acts like a virtual-link. if the virtual circuit breaks, everyone on the circuit gets appropriate link layer signaling messages, and those can be passed up to the upper layers, including IPv6. literally so iconic 😭
A.3. Inverse Neighbor Discovery Protocol 🧚
this part of the appendix only covers the specific stuff for Inverse Neighbor Discovery with Frame Relay Networks 💜
A.3.1. Sender Node Processing 📤
so a soliciting Frame Relay node formats an IND solicitation message the way we defined in an earlier section, wraps the packet up for the Frame Relay link-layer [IPv6-FR], and sends it to the target Frame Relay node. 🫶 the destination IP address is the IPv6 all-node multicast address, but the message only goes to the target Frame Relay node, bestie. the target 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 doing anything else, swaps out the existing DLCI value in the Source link-layer address for the DLCI value from the Frame Relay header of the frame carrying the message. the DLCI value has to be formatted properly in the Source link-layer address field [IPv6-FR]. this step is required so the fields get read correctly in the rest of the 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 more optimal value, if that wasn't already done when the interface got configured 🌈
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 (aka the Target IP addresses and the Source link-layer address from the IND advertisement message) into its ND cache [IPv6-ND], the same way it would for a ND Advertisement 🦋
also, 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 the remote node uses to identify the receiver 💖
if the receiver node of the IND Advertisement has a pool of IPv6 addresses, and the implementation allows it, it may decide to pair specific local IPv6 addresses with specific IPv6 addresses from the target list for later communications on the VC. more specifically, that pairing may be based on IPv6 addresses being on the same subnet, meaning they have the same prefix 👑
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. 🫶
📦 where this page comes from
- ietf: rfc3122 2001-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms