Internet Engineering Task Force M. Smith Internet-Draft 23 July 2025 Updates: 4861 (if approved) Intended status: Standards Track Expires: 24 January 2026 ICMPv6 Prefix Redirect Messages draft-smith-6man-icmpv6-prefix-redirect-03 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Smith Expires 24 January 2026 [Page 1] Internet-Draft ICMPv6 Prefix Redirect July 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. ICMPv6 Prefix Redirect Message Format . . . . . . . . . . . . 4 3. Router Processing . . . . . . . . . . . . . . . . . . . . . . 4 4. Host Processing . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Legacy Hosts . . . . . . . . . . . . . . . . . . . . . . 5 4.2. ICMPv6 Prefix Redirect Aware hosts . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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 Smith Expires 24 January 2026 [Page 2] Internet-Draft ICMPv6 Prefix Redirect July 2025 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. Smith Expires 24 January 2026 [Page 3] Internet-Draft ICMPv6 Prefix Redirect July 2025 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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 seconds 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. 3. 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- Smith Expires 24 January 2026 [Page 4] Internet-Draft ICMPv6 Prefix Redirect July 2025 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 in seconds 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. 4. 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. 4.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 and Prefix Redirect Lifetime fields because they are 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. Smith Expires 24 January 2026 [Page 5] Internet-Draft ICMPv6 Prefix Redirect July 2025 4.2. 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. Over time, the host decrements the lifetime of the redirect prefix route, unless the received Prefix Redirect Lifetime value was infinity. 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], regardless of the remaining redirected prefix route lifetime, or the lifetime of the redirected prefix route reaches 0 seconds. 5. IANA Considerations This memo includes no request to IANA. 6. 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 Smith Expires 24 January 2026 [Page 6] Internet-Draft ICMPv6 Prefix Redirect July 2025 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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [exampleRefMin] Surname [REPLACE], Initials [REPLACE]., "Title [REPLACE]", 2006. [exampleRefOrg] Organization [REPLACE], "Title [REPLACE]", 1984, . Acknowledgements Your name here! Author's Address Mark Smith PO BOX 521 Heidelberg Victoria 3084 Australia Email: markzzzsmith@gmail.com Smith Expires 24 January 2026 [Page 7]