Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
Extracted elements (28)
IND Solicitations are addressed to the IPv6 all-node multicast address (FF02::1) at the IP layer because the remote node's IPv6 addresses are not yet known, but they are sent directly to the target node at the link-layer level using the known link-layer address.
IND was originally developed for Frame Relay networks where a node learns a remote DLCI (virtual circuit identifier) via signaling but has no knowledge of the remote node's IPv6 addresses or the DLCI by which the remote node identifies the local node.
The Source Address List in a Solicitation is explicitly allowed to be incomplete if all IPv6 addresses do not fit in a single message, but the Target Address List in an Advertisement should be complete (potentially spanning multiple Advertisement messages). This asymmetry reflects that the advertiser has full knowledge of its own addresses.
For Frame Relay nodes, the Source Link-Layer Address field in an IND Solicitation is overwritten by the receiver with the DLCI from the Frame Relay frame header before further IND processing. The sender may leave it zero if unknown.
IND extends the standard IPv6 Neighbor Discovery (RFC 2461) and reuses ND options, cache structures, and timers (RetransTimer, MAX_MULTICAST_SOLICIT). Information learned from IND MAY be stored in the Neighbor Discovery cache as with standard ND.
A node MUST silently discard any received IND Advertisement that fails validity checks including: Hop Limit 255, valid ICMP checksum, Code 0, ICMP length >= 48 octets, Source Link-Layer Address present, Target Link-Layer Address present, Target Address List present with length >= 3, and all options have length > 0.
An implementation MUST NOT send duplicates in the IPv6 address list included in Source or Target Address List options.
If a Security Association for the IP Authentication Header exists between the sender and destination, the sender SHOULD include the Authentication Header in IND Solicitation and Advertisement messages.
If no IND Advertisement is received after MAX_MULTICAST_SOLICIT solicitations and the sending was required by an upper-layer, the sender MUST notify the error to the upper-layer through an appropriate mechanism.
Received Authentication Headers in IND packets MUST be verified for correctness, and packets with incorrect authentication MUST be ignored.
Receivers MUST silently ignore any options they do not recognize and continue processing the message. This applies to both Solicitation and Advertisement messages.
The Reserved field in IND messages MUST be initialized to zero by the sender and MUST be ignored by the receiver.
The sender of an IND Advertisement MUST include the Source Link-Layer Address, Target Link-Layer Address, and Target Address List options.
The sender of an IND Solicitation MUST include both the Source Link-Layer Address option and the Target Link-Layer Address option in the message.
The Source Address List MUST fit in one IND Solicitation message; if all IPv6 addresses of an interface do not fit, the option contains an incomplete list. A complete list should be obtained from the IND Advertisement.
The Target Address List SHOULD be the complete list of addresses of the target interface. If it does not fit in one Advertisement, one or more additional IND Advertisement messages SHOULD follow with the remaining addresses.
While awaiting a response, the sender SHOULD retransmit IND Solicitation messages approximately every RetransTimer interval. Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer.
The Inverse Neighbor Discovery Advertisement message (ICMPv6 Type 142) is sent in response to an IND Solicitation. Its destination address is the source address of the invoking solicitation, and it carries the Target Address List of IPv6 addresses associated with the target's link-layer address.
The Inverse Neighbor Discovery Solicitation message (ICMPv6 Type 141) is sent by a node to request the IPv6 addresses corresponding to a known link-layer address of a target node. It is sent as an IPv6 all-node multicast (FF02::1) at the IP layer but directed to the target at the link-layer level.
IANA assigned two new ICMPv6 Neighbor Discovery Option types: Type 9 for Source Address List and Type 10 for Target Address List, from the IPv6 Neighbor Discovery family of option type values.
IANA assigned two new ICMPv6 type values from the Informational range: Type 141 for IND Solicitation and Type 142 for IND Advertisement, as defined in RFC 2463. Future ICMPv6 code assignments for these types are to be made under Standards Action.
For Frame Relay use, IPsec Authentication verification MUST be completed before the Frame Relay-specific preprocessing that replaces the Source Link-Layer Address DLCI from the frame header, to avoid spurious authentication failures.
IND packet exchanges can be authenticated using the IP Authentication Header (IPsec). It SHOULD be possible for the system administrator to configure a node to ignore any IND messages that are not authenticated; such a switch SHOULD default to allowing unauthenticated messages.
IND uses the Hop Limit field (required value 255) to reject packets that could have been forwarded by a router, thus limiting exposure to off-link attackers. Because routers decrement Hop Limit, a received packet with Hop Limit 255 must have originated from a directly connected neighbor.
When used on point-to-point virtual circuits such as Frame Relay, IND messages are less sensitive to impersonation attacks from on-link nodes compared to broadcast links, because each virtual circuit connects only two endpoints.
The IND Advertisement message shares the same header layout as the Solicitation (Type/Code/Checksum/Reserved), with Type=142 and minimum ICMP length of 48 octets, followed by options including required Source Link-Layer Address, Target Link-Layer Address, and Target Address List.
The IND Solicitation message is a 32-bit-aligned ICMP message with Type (8 bits), Code (8 bits, must be 0), Checksum (16 bits), and a 32-bit Reserved field (must be zero), followed by options. Minimum ICMP length is 24 octets.
The Source Address List (Type 9) and Target Address List (Type 10) are TLV options with an 8-bit Type, 8-bit Length (in units of 8 octets, minimum 3), a 24-bit Reserved field, and one or more 128-bit IPv6 addresses. The number of addresses n = (Length - 1) / 2.