IPv6 Inverse Neighbor Discovery Update

This draft updates the Inverse Neighbor Discovery Specification . Any behaviour or format that is not explicitely changed is preserved. The behaviour of the protocol is slightly amended : Secure Inverse Neighbor Discovery is added for unicast addresses with a 64bit interface ID. This specification provides the additional options that are required to sign Inverse ND messages with the properties that are defined in and details how they may be used to prove the ownership of advertised addresses. Fragmentation of ND messages is accepted but not required. requires the use of multiple Advertisement messages when the Target Address List does not fit within MTU. With this specification, it is acceptable to fragment a message, but it is still possible to use multiple Advertisement messages, which can be necessary in particular in the context of Secure Inverse Neighbor Discovery. does not allow a crisp management of all Addresses that a peer may use on an interface. When multiple Advertisement messages are used, it is possible to miss one and thus miss some information. With this specification, Address Management is improved in such a way that it is possible to advertise the addition or the deletion of a single address and to get the exhaustive list of all the addresses that a neighbor might use to source packets on an interface. With IPv4, Inverse ARP is traditionally applied to Point to Multipoint networks only. claims to apply to "Frame Relay networks", and "also apply to other networks with similar behavior". This specification extends the domain of applicability of Inverse Neighbor Discovery and provides some additional information on how and why Inverse ND MAY be used on all types of interface. Typos such as the length field in the Source/Target Address List are corrected. The concept of transaction is introduced to group multiple messages into a single set to enable the advertisement of the complete list of all addresses used to source packets on on an interface. Whenever possible, a node should use one message per transaction. This is problematic when: The list of addresses is so large that it causes the message to be larger than MTU and the node can not fragment. Secure Inverse ND is applied and not all of the addresses are based on a same CGA modifier (see ).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This section updates the Inverse Neighbor Discovery Messages defined in section 2. A new field from the ICMP reserved part is used to indicate the version and preserve backward compatibility. Version 0 is . Version 1 is this specification. A node proposes a version in the Inverse Neighbor Discovery Solicitation Message and responds with the smallest of its own preferred version and the received proposed version in an Advertisement. Another new field from the ICMP reserved part is used to indicate the Transaction ID of a Neighbor Discovery Solicitation Message, in order to correlate multiple Advertisement messages that may result from one Solicitation Message. When the information about an address is not seen after 2 consecutive advertisement of a full List of addresses that address is considered as removed. This decision is made upon the reception of an advertisement with a Transaction ID that is sequentially later then the 2 consecutive advertisements.

The Inverse Neighbor Discovery Solicitation Message can be used to obtain the full list of IPv6 addresses from the remote end of a Point to Point link such as a PPP link, a tunnel or a Virtual Channel. The Inverse Neighbor Discovery Solicitation can also be used as a heartbeat mechanism to verify whether a Point to Point link such as a tunnel is still up when there is no signal from the lower layers to indicate a failure. The Inverse Neighbor Discovery Solicitation Message is changed as follows:

This specification adds the following fields: 8bit field. Inverse Neighbor Discovery Solicitation. 8bit field. Version of 0 indicates the support of only. Version of 1 indicates the desire to follow this specification and the backward compatibility with version 0. 8bit field. The Transaction ID is incremented with each Inverse Neighbor Discovery Solicitation Message sent to the same neighbor. The transaction ID can not be set to zero so it starts at 1 and wraps from 255 directly to 1. 1bit field. The "F" flag indicates a request of the Full List of addresses on the peer side of the Link.

The Inverse Neighbor Discovery Advertisement Message can be used as a response to an Inverse Neighbor Discovery Solicitation Message or asynchronously at any point of time once a first Inverse Neighbor Discovery Solicitation Message was received indicating that the remote peer supports this specification. Multiple Inverse Neighbor Discovery Advertisement Messages might be needed to report the full list of addresses. Those messages are correlated by a same transaction ID. An unsolicited Advertisement is used to advertise the addition or the deletion of a single address and is contained in a single Inverse Neighbor Discovery Advertisement Message, with a transaction ID of 0. The Inverse Neighbor Discovery Advertisement Message is changed as follows:

This specification adds the following fields: 8bit field. Inverse Neighbor Discovery Advertisement. 8bit field. Version of 0 indicates the support of only. Version of 1 indicates the desire to follow this specification. Version can only be set to 1 if the Version in the Solicitation Message was 1 or above. 8bit field. The Transaction ID echoes that of the Inverse Neighbor Discovery Solicitation Message that this Message is responding to. The transaction ID zero is used for unsolicited Advertisements. 1bit field. The "F" flag indicates that the Full List of addresses will be provided for that transaction. Upon a request by the remote peer of the Full List of addresses, this node SHOULD answer with all the addresses that can be used to reach it over this link in the modified Target Address List. If the IND Solicitation does not request the full list then his node MAY answer with all the addresses that can be used to reach it over this link in the modified Target Address List.

This section updates the Inverse Neighbor Discovery Options defined in section 3.

With this specification, the Source/Target Address List may be partial or full. It can be used to indicate addition or deletion of individual addresses. This new support can only be used once the first Inverse Neighbor Discovery Solicitation Message is received from the remote peer indicating the support of this specification. Until the Version that is supported by the peer is known, the only Inverse Neighbor Discovery Messages that this node should send are Solicitations, and this option if present can only be a Source Address List option with a list of addresses that can be used to reach this node over this link. This specification uses a Length field of 8 bits, assuming that most implementations of also use a Length field of 8 bits and that the misalignment in section 3.1 is commonly undestood as an undetected typo. An error in reading the Length field can be detected when confronting the length of the IPv6 packet and the expected length of this option. The Inverse Neighbor Discovery Advertisement Message is changed as follows:

This specification adds the following fields: 8bit enumeration Mode of 0 indicates that the list is built conforming to . All the addresses listed are usable but the list might not be complete. Mode of 1 indicates that the list might contain addresses that are defined on another interface but may be used to source or receive packets over this interface. This is the mode that is used to in reply to a Solicitation with the "F" bit set. Mode of 2 indicates that the list is a list of recently added addresses but not necessarily part of a full report. Mode of 3 indicates that the list is a list of recently removed addresses that may no more be used on this link. Upon receiving an Address List, a node should verify that the addresses in the list don't collide with any of its own address. In case it does, the duplicate address received in the list will be ignored. When Secure IND is being used, all the addresses listed in the Target Address List option in one Inverse Neighbor Discovery Advertisement Message must be based on the same CGA modifier. If multiple modifiers are used or some addresses were not built based on CGA, then they must be split in multiple Inverse Neighbor Discovery Advertisement Messages.

The list of addresses provided in Source/Target address list can be defended using the CGA and the RSA options specified in [RFC3972] and [RFC3971]. However, in the case of Secure Inverse Neighbor Discovery, several addresses announced in one message (IND Solicitation or Advertisement) are defended by a single CGA option and a single RSA option. T hat mandates that all addresses in the list are based on CGA and were computed with the same public key, modifier, collision count, and the same security parameter sec. In this case, the CGA option is as following:

Since each address in the list is going to carry its own prefix (/64 if CGA is used), the Subnet Prefix in the CGA option is set to zero. Therefore, it should not be checked by the receiver against the prefix (/64 bits) of each CGA address found in the Address List. The collision count is always zero, since no Duplicate Address Detection is performed, other than the node ignoring peer addresses colliding with one of its own. The remaining of the CGA algorithm, as described in [RFC3972] applies. The 16*Sec leftmost bits of Hash2 should equal zero. Hash1 is computed separately for each address in the list, using the first 64 bits as the Subnet Prefix, and the interface identifier should match Hash1 (except for bits 0, 1, 2, 6, and 7, which encode the collision count and the "u" and "g" bits). The RSA option must also be provided in the message, and the signature must verify with the public key provided in the CGA option In order to protect against replays, Timestamp and Nonce options, should also be used in the message, with similar rules as one described in [RFC3971]. When the message is a solicitation (INS), it should have a nonce option. When the message is sollicited (INA as a response to INS), it should repeat the nonce value seen in the solicitation. As far as unsolicited message and solicitation, the timestamp option is required.

Because of IPv4 and the ARP legacy, Inverse Neighbor Discovery is usually associated to Point to Multipoint (P2MP) or Non-Broadcast Multi-Access (NBMA) networks. And certainly, this specification is usable on such networks as Frame Relay or Multidrop tunnels. But the similarity with IPv4 is limited and this specification enables a lot more:

IPv6 Secure Inverse Neighbor Discovery can be applied to P2MP and NBMA networks to prevent the theft an address by another Node.

As opposed to IPv4, using Inverse Neighbor Discovery makes a lot of sense on Point-to-Point link such as PPP or tunnels: This specification inherits from the support of the authentication header to authenticate the remote peer on the link. For P2P links, this might prove more relevant than Secure ND itself. Because IPv6 operates purely at layer 3, the PPP Network Control Protocol for IPv6 defined in provides a way to negotiate a unique, 64bit interface identifier to be used for the address autoconfiguration but does not enable to advertise an IPv6 address. This would not fit anyway since IPv6 might use many addresses of various lifetimes on a same interface. This specification provides the means to create and maintain the list of addresses that can be used to reach the remote peer at any point of time. A number of Denial of Service attacks are documented when using by sending packets to addresses that are not assigned but belong to a prefix that is associated to the P2P link. On those links, Inverse Neighbor Discovery enables a proactive model that defeats those attacks. Any packet that is received for a destination that is not in the ND table is simply dropped.

A multihomed host attached to a broadcast network might use an address that belongs to another interface on another subnet to source a packet. This makes the validation of source addresses very problematic. With this specification, a router may solicit the full list of all addreses that this host might use to source packets on that interface, and prove the ownership using SeND. The router might then accept packets that are sourced off-link and may install a host route to that address.

This memo includes no request to IANA.

This draft improves the security model in by adding the capability to use Secure Neighbor Discovery

Thanks to Tony Cheneau and Wojciech Dec for useful feedback and discussion.