| Internet-Draft | ICMPv6 Prefix Redirect | July 2025 |
| Smith | Expires 24 January 2026 | [Page] |
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.¶
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 (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
[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.¶
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.¶
The enhanced ICMPv6 Redirect Message Format is as per [RFC4861] 4.5, with the following modification:¶
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.¶
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 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.¶
A host that receives an ICMPv6 Prefix Redirect Message initially validates the message according to the steps specified in [RFC4861], Section 8.1.¶
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.¶
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 :¶
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.¶
This memo includes no request to IANA.¶
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.¶
Your name here!¶