]>

PO BOX 521 Heidelberg Victoria 3084 AU markzzzsmith@gmail.com

Internet Internet Engineering Task Force ipv6 icmpv6 prefix redirect redirection The existing IPv6 ICMPv6 Redirect Message informs a host of a better next hop for a single destination IPv6 address. There are use cases for informing a host of a better next hop for a prefix or range of IPv6 addresses that includes or covers the single destination address that triggered the ICMPv6 redirect message. This memo specifies an ICMPv6 Prefix Redirect Message for this purpose.

Introduction [RFC9663] describes a method of assigning client hosts a prefix or range IPv6 addresses via DHCPv6-PD [RFC8415]. The IPv6 prefix size expected to be delegated to client hosts is a /64. When packets are sent between hosts on the same link with different host prefixes, from and to addresses within the delegated prefixes, the sending host will normally send the packets to a default router for delivery, as the sending host is not aware that the destination address is within a prefix that is directly reachable via another host attached to the same link. [RFC9663] advises that routers SHOULD send an ICMPv6 Redirect Message [RFC4861] to the packet sending host to inform it that the destination address of the packet is directly reachable via another host attached to the same link. The major drawback of using existing ICMPv6 Redirect Messages in this case is that the ICMPv6 Redirect Message only redirects packets for a single destination address. Should the same sending host send a packet to a different destination within the same destination prefix assigned to the same on-link host, it will again send that packet to a default router and the default router will again generate an ICMPv6 Redirect Message for the different destination address to the same on-link destination host. In the scenario described by [RFC9663], a default router is aware of the prefix assigned to a host that includes the destination address that will trigger an ICMPv6 Redirect Message. Consequently, rather than generating an ICMPv6 Redirect Message for an individual destination address, it would be preferable if an ICMPv6 redirection message could convey redirection for a prefix covering a range of destination addresses assigned to a host. Another potential use case is in a broadband access network. Similar to the [RFC9663] scenario, broadband subscribers' CPE are delegated IPv6 prefixes, such as a /48 or /56, for use on downstream LAN interfaces via DHCPv6-PD [RFC8415]. Traffic between subscribers' delegated prefixes will follow a default route to the upstream Broadband Network Gateway [BNG] router. If the subscribers' CPE are attached to the same subnet and link, the traffic between subscribers' delegated prefixes could be sent directly between their CPEs, rather than going via the upstream BNG. A subscriber's CPE would need to be informed of the other subscriber's delegated prefix that is directly reachable over the common subnet and link. This could be achived with an ICMPv6 redirection message that conveys redirection for a prefix. Note that routers, of which subscriber CPE are an example, do not normally process ICMPv6 redirection messages [RFC4861]. [RFC7084] CPE perform some host processing of IPv6 messages, such as sending Router Soliciations and processing received Router Advertisements [RFC4861]. [RFC7084] would need to be updated to allow CPE to receive and process ICMPv6 redirection messages for a prefix. This memo enhances the existing ICMPv6 Redirect Message so that it can convey an IPv6 prefix that includes the single IPv6 destination address that triggered the redirection. This enhanced redirect message is known as an ICMPv6 Prefix Redirect Message. The ICMPv6 Prefix Redirect Message is backwardly compatible with host implementations that only understand the existing single destination IPv6 address ICMPv6 Redirect Message.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

ICMPv6 Prefix Redirect Message Format The enhanced ICMPv6 Redirect Message Format is as per [RFC4861] 4.5, with the following modification:

• The first 8 bits of the Reserved field are designated as the unsigned 8 bit integer "Prefix Length" field, carrying the length of the prefix being redirected.
• The second 8 bits of the Reserved field remain reserved, meaning set to all zeros upon transmission and ignored upon receipt.
• The final 32 bits of the Reserved field are designated as an unsigned 32 bit integer specifying the Prefix Redirect Lifetime, specifying the length of time in seconds that the prefix redirection remains valid relative to when the ICMPv6 Prefix Redirect Message is received. A value of all one bits (0xffffffff) represents infinity. A value of 0 is invalid.

Note that the Destination Address field continues to carry the IPv6 address of the packet that triggered the enhanced ICMPv6 Prefix Redirect Message, retaining backward compatibility with hosts that do not understand this ICMPv6 Prefix Redirect Message.

Router Processing A router that can send ICMPv6 Prefix Redirect messages follows the Router Specification in section 8.2 of [RFC4861], with the additional steps:

• A router implementation maintains a per-interface system varliable that specifies the largest size of a prefix that can be redirected, with a default value of 48, corresponding to redirecting an IPv6 /48 prefix or longer. The per-interface system variable's valid range is 0 through 128. The Prefix Length field in the ICMPv6 Prefix Redirect Message is set to the length of the prefix in the route table that best matches the destination IPv6 address that triggered the prefix redirection, where the matching prefix's length is greater than or equal to the per-interface largest size prefix system variable's current value. If the length of the best matching route is shorter/smaller than the per-interface largest size prefix system variable's value, the ICMPv6 Redirection Message is sent with the Prefix Length field value set to 128 (this is the ICMPv6 Prefix Redirect Message equivalent of a traditional ICMPv6 Redirect Message for a single IPv6 destinaton address.)
• A router implementation maintains a per-interface system variable that specifies the Prefix Redirect Lifetime value used for ICMPv6 Prefix Redirect Messages sent out of this interface. The default value for this variable is 3600 seconds or 1 hour.

A router implentation should also provide a mechanism via an administrative interface to suppress ICMPv6 Prefix Redirection Messages for a specified prefix on a per-interface basis.

Host Processing A host that receives an ICMPv6 Prefix Redirect Message initially validates the message according to the steps specified in [RFC4861], Section 8.1.

Legacy Hosts Once the message has been validated, a legacy host that does not understand the ICMPv6 Prefix Redirect message will ignore the Prefix Length field because it is utilising part of the existing Reserved field, which is a backward-compatible change; [RFC4861]: "The contents 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." A legacy host will process the ICMPv6 Prefix Redirect message as though it was for a single destination address, the address held in the ICMP Prefix Redirect message Destination Address field, per [RFC4861] section 8.3.

ICMPv6 Prefix Redirect Aware hosts In addition to validating the ICMPv6 Prefix Redirect Message according to [RFC4861] section 8.1, a host implementing this specification performs the following steps. If any of the message validation steps fail, the ICMPv6 Prefix Redirect Message is silently discarded, or is discarded and a suitable ICMPv6 error counter incremented :

• The Prefix Length field value is no less than a per-interface system implementation variable that limits how large the redirected prefix can be. By default, this system variable's value is 48, supporting a redirected prefix of a /48 or smaller, such as a /56 or /64. The minimum value for this system varible is 0, while the maximum value 128 corresponding to a /128 or a single IPv6 address.
• The Prefix Redirect Lifetime field value is greater than 0.
• A host then combines the ICMPv6 Prefix Redirect Message Destination Address field with the Prefix Length field to determine the prefix that is being redirected.
• An ICMPv6 Prefix Redirect Aware host will then update its route table with a route for the redirected prefix information and the ICMPv6 Prefix Redirect Message Target Address as the route's next hop. The host decrements the lifetime of the route table entry for the redirected prefix.

This redirected prefix route MUST be removed from the host's route table if either the next hop becomes unreachable, as detected by Neighbor Unreachability Detection (NUD) [RFC4861], or the lifetime of the redirected prefix route reaches 0.

IANA Considerations This memo includes no request to IANA.

Security Considerations The security threats for ICMPv6 Prefix Redirect Messages are the same as those for the ICMPv6 Redirect Message; see [RFC4861]. The significant security difference between an ICMPv6 Prefix Redirect Message and an ICMPv6 Redirect Message is that a successful malicious ICMPv6 Prefix Redirect Message will redirect traffic for a range or a prefix's worth of IPv6 addresses rather than just a single address. By default, a prefix redirection is limited to a /48. The size of the prefix that is accepted in an ICMPv6 Prefix Redirect Message can be reduced to a smaller prefix, such as a /56 or a /64, if necessary. To further mitigate the impact of a malicious prefix redirect, the ICMPv6 Prefix Redirect Message contains a Prefix Redirect Lifetime field, which defaults to 3600 seconds or 1 hour, which limits how long a malicous ICMPv6 Prefix Redirect takes effect. The Prefix Redirect Lifetime field value accepted by a host can be reduced if necessary.

References Normative References Informative References Organization [REPLACE]

Acknowledgements Your name here!