Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

Google

3400 Hillview Ave Palo Alto CA 94304 USA jhw@google.com

I-D Internet-Draft The IPv6 Neighbor Discovery protocol provides a Redirect function allowing routers to inform recipients of a better next hop on the link toward the destination. This document specifies a backward-compatible extension to the Redirect function to allow routers to include routing information that the recipient can associate with the next hop.

"Neighbor Discovery for IP version 6 (IPv6)" provides a Redirect function allowing routers to inform recipients of a better next hop on the link toward the destination. Further guidance for processing Redirect messages is given in "First-Hop Router Selection by Hosts in a Multi-Prefix Network" . "Default Router Preferences and More-Specific Routes" specifies a Route Information Option (RIO) that routers can include in Router Advertisement (RA) messages to inform recipients of more-specific routes. This document specifies a backward-compatible extension to allow routers to include RIOs in Redirect messages.

The terminology in the normative references applies. 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 . Lower case uses of these words are not to be interpreted as carrying RFC2119 significance.

The RIO is specified for inclusion in RA messages in Section 2.3 of . The Redirect function is specified in Section 8 of . This specification permits routers to include RIOs in Redirect messages so that recipients can direct future packets to a better next hop for a destination *prefix* instead of just a specific destination. This specification therefore updates and , as discussed in the following sections.

The validation of Redirect messages follows Section 8.1 of , which contains the following passage: "The contents of any defined options that are not specified to be used with Redirect messages MUST be ignored and the packet processed as normal. The only defined options that may appear are the Target Link-Layer Address option and the Redirected Header option." This specification updates the above statement by adding RIOs to the list of defined options that may appear.

The Router Specification follows Section 8.2 of , which provides a list of options that may appear in a Redirect message. This specification updates the list by including RIOs as permissible options. Routers therefore MAY send Redirect messages containing RIOs with values determined by a means outside the scope of this specification. After the initial router sends Redirect messages containing RIOs that are processed by the recipient, the redirection Target MAY send its own Redirect messages containing RIOs. These Redirect messages may be either "solicited" (i.e., an ordinary Redirect) or "unsolicited" (i.e., a Redirect generated without waiting for a packet to arrive). An unsolicited Redirect message includes a Destination Address and Redirected Header option that are either fabricated or derived from a remembered packet that was processed at an earlier time. Alternatively, the message could omit the Redirected Header option and/or set the Destination Address field to "::" (the IPv6 unspecified address). Such a message would still satisfy the message validation checks in Section 8.1 of . Any router may send RA messages with RIOs at any time, but these may be dropped along some paths over layer-2 switch fabrics that implement RA filtering.

The Host Specification follows Section 8.3 of , Section 3 of , and Section 3 of . According to , a host that receives a valid Redirect message updates its destination cache per the Destination Address and its neighbor cache per the Target Address. According to , hosts can be classified as Type "A", "B" or "C" based on how they process valid RA messages, where a Type "C” host updates its routing table per any RIO elements included in the message. Finally, according to , a Type "C” host operating on a Multi-Prefix Network with multiple default routes can make source address selection decisions based on information in its routing table decorated with information derived from the source of the RIO element. In light of these considerations, this document introduces a new Type "D” behavior for hosts with the same behavior as a Type "C” host, but which also process RIO elements in Redirect messages. Type "D” hosts process Redirect messages with RIO elements by updating 1) their neighbor cache per the Target Address, 2) their destination cache per the Destination Address, and 3) their routing tables per any RIO elements present. The host can then make source address selection decisions per the same as described above. When a Type "D" host processes a Redirect message, it SHOULD first test the path to the Target using Neighbor Unreachability Detection (NUD) while continuing to send packets via the router that issued the Redirect until the NUD procedure converges. Thereafter, if a Route Lifetime expires (or if an RIO with Route Lifetime 0 arrives) the host removes the corresponding Prefix from its routing table and allows future packets to follow a different route. The behaviors of Type "A", "B” and "C” hosts defined in are not changed by this specification. This specification updates Section 3 of by introducing a new host Type "D", and updates Section 8.3 of by permitting RIOs to appear in Redirect messages.

Type "D" hosts may be holders of entire IPv6 prefix delegations instead of just a singleton address. For example, the host may connect an entourage of "Internet of Things" devices that derive their addresses from a delegated prefix. In that case, the host may itself serve as a redirection target in a manner consistent with the Router Specification above. Such Type "D" hosts act like a host in terms of processing received Redirects and act like a router in terms of sending Redirects.

The Redirect function and RIOs are widely deployed in IPv6 implementations.

This document introduces no IANA considerations.

Security considerations for Redirect messages that include RIOs are the same as for any IPv6 ND messages as specified in Section 11 of . Namely, the protocol must take measures to secure IPv6 ND messages on links where spoofing attacks are possible. A spoofed Redirect message containing no RIOs could cause corruption in the host's destination cache while a spoofed Redirect message containing RIOs could corrupt the host's routing tables. While the latter would seem to be a more onerous result, the possibility for corruption is unacceptable in either case. "IPv6 ND Trust Models and Threats" discusses spoofing attacks, and states that: "This attack is not a concern if access to the link is restricted to trusted nodes". "SEcure Neighbor Discovery (SEND)" provides one possible mitigation for other cases. describes a layer-2 filtering technique called “RA Guard” intended for network operators to use in protecting hosts from receiving RA messages sent by nodes that are not among the set of default routers regarded as legitimate by the network operator. However, the RA Guard function defined in does not filter ND Redirect messages. On networks with such RA Guard functions, blocked routers can use ND Redirect messages to inform hosts of routes for specific destination addresses. This draft introduces a new method by which such routers can inform Type D hosts of routes for more specific destination prefixes as well as addresses. On networks with layer-2 filters that protect hosts by restricting the delivery to hosts of both RA messages and ND Redirect messages from a limited set of legitimate routers, the host routing tables of both Type C and Type D hosts are protected by that layer-2 filtering function.

Joe Touch suggested a standalone draft to document this approach in discussions on the intarea list. The work was subsequently transferred to the 6man list, where the following individuals provided valuable feedback: Mikael Abrahamsson, Zied Bouziri, Brian Carpenter, Steinar Haug, Christian Huitema, Tomoyuki Sahara.

Type "D" hosts send unsolicited Neighbor Advertisements (NAs) to announce link-layer address changes per standard neighbor discovery . Link-layer address changes may be due to localized factors such as hot-swap of an interface card, but could also occur during movement to a new point of attachment on the same link.

Type "D" host interfaces may have multiple connections to the link; each with its own link-layer address. Type "D" nodes can therefore include multiple link-layer address options in Redirects and other IPv6 ND messages. Neighbors that receive these messages can cache and select link-layer addresses in a manner outside the scope of this specification.