ICMPv6 Prefix Redirect Messages

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. The primary goal of [RFC9663] is to avoid large numbers of IPv6 neighbor cache entries in the router(s) connected to the same and a typically large network segment, which can occur due to IPv6 hosts having multiple IPv6 addresses for various purposes [BCP204][RFC1681]. These hosts' addresses' neighbor cache entries are instead replaced with route table entries for the prefixes provided to the hosts via DHCPv6-PD. There will typically only be a single neighbor cache entry for each host, for the link-local address that is used as the next hop address for the DHCPv6-PD provided prefix in the route table. 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 a 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 an 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. 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.

Broadband Access Network Use-Case Broadband access networks can commonly have subscriber layer 2 aggregation distributed across multiple points-of-presence (PoPs), such as telephone exchanges (central offices), while the upstream layer 3 Broadband Network Gateway (BNG) is located in a remote data center, reached via the access network backhaul links. The BNG is likely to provide services to multiple PoPs, hence the more central location in a data center. Subscribers individual services and sessions are typically isolated from each other using VLAN tags. Each subscriber session between the BNG and the subscriber's CPE will have a unique IPv6 /64 or perhaps a /128. They will be delegated an IPv6 prefix for their CPE's downstream LAN interfaces of up to a /48 via DHCPv6-PD. A drawback of this existing deployment model is that all inter-subscriber traffic between subscribers attached to the same PoP, and therefore the same layer 2 aggregation infastructure, will traverse the backhaul link or links to the remote data center in both directions as well as traversing the BNG or BNGs the subscribers sessions reside on. Another drawback of this existing model is that content caches also have to be co-located in the data center where the BNGs are located or further upstream in the network. As content caches are commonly used for distributing high bandwidth video content, large amounts of video traffic traverse the BNGs and the backhaul links between the subscriber PoPs. An alternative deployment model would be to place all subscribers CPE within a single LAN segment (e.g. VLAN) within a PoP in addition to any upstream BNGs, meaning that the subscriber CPEs and BNGs share a single common IPv6 /64 subnet. Subscriber CPEs still use DHCPv6-PD to acquire prefixes, e.g., up to a /48, for their downstream LAN interfaces. Should a subscriber send a packet to another subscriber attached to the same PoP, the sending subscriber's CPE would use its default route to an upstream BNG to reach the destination subscriber's CPE. The receiving BNG would recognise that the two subscribers' CPE are attached to the same LAN segment, and could send an ICMPv6 Prefix Redirect Message to the source subscriber's CPE, informing it that the destination subscriber's CPE's DHCPv6-PD acquired LAN prefix, e.g. up to /48, is directly reachable over the single common subnet via the common layer 2 aggregation infrastructure. This would have the benefits of removing the inter-subscriber traffic from the backhaul link to the upsteam data center and BNG, sending it directly between the subscribers' CPEs. This would also reduce the latency of the traffic between the subscribers, which may be beneficial for on-line gaming between the two subscribers. This deployment model would also allow content caches to be placed within the subscriber PoP, attached to the same LAN segment as the subscriber CPEs. ICMPv6 Redirect or ICMPv6 Prefix Redirect Messages could be used to inform subscriber CPEs that a content cache is directly reachable within the PoP rather than going via the BNG. This could signficantly reduce the amount of traffic travelling over the access network backhaul to the upstream BNG, and the traffic load on the BNG, when the traffic being distributed by the content cache is high bandwidth video traffic. [RFC4861] prohibits routers, of which subscriber CPE are a type, from processing ICMPv6 Redirect Messages. The same prohibition would apply to ICMPv6 Prefix Redirect Messages. Similarly, Router Advertisements (RAs) [RFC4861] are also not to be used by routers, although they may be processed for validation. However, [RFC7084] loosens this prohibitation for RA processing, allowing CPE to process RAs to learn of upstream default routers - the CPE's upstream interface is acting as a router interface for the purposes of packet forwarding, and acting as a host interface for the purposes of discovering upstream default routers. A similar loosening of this prohibition, in an update to [RFC7084], to allow CPE to process ICMPv6 Redirect Messages and ICMPv6 Prefix Redirect Messages would be needed to suit this new model. In a sense, Router Advertisments, ICMPv6 Redirect Messages and ICMPv6 Prefix Redirect Messages are acting as an ad-hoc on-demand routing protocol between the upstream BNG and subscribers' CPEs, that do not have a conventional routing protocol adjacency. One of the reasons that subscriber sessions are isolated using VLAN tags is for authentication purposes. In this alternative shared single LAN segment model, subscriber authentication could continue to be achieved via a Lightweight DHCPv6 Relay Agent [RFC6221] Interface-ID option [RFC8415] or Subscriber-ID option [RFC4580], or via [IEEE802.1X] authentication. BNGs are commonly used to record individual subscriber traffic statistics for traffic billing functions. Sending traffic directly between subscribers or subscribers and a PoP located content cache via ICMPv6 Redirect Messages or ICMPv6 Prefix Redirect Messages would mean that the redirected traffic would not be recored by the BNG (other than the packets that trigger the Redirect Messages). This may be a suitable trade-off in comparison to the backhaul link and BNG resources saved by having traffic directly flow between subscribers or subscribers and a PoP located content cache when possible.

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.

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 also validates the Prefix Length field. If any of the validation steps fail, the ICMPv6 Prefix Redirect Message is silently discarded:

The Prefix Length field value is no greater than 128 (which is possible as it is an 8 bit field).
The Prefix Length field value is no less than a host 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.

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. This redirected prefix route MUST be removed from the host's route table if the next hop becomes unreachable, as detected by Neighbor Unreachability Detection (NUD) [RFC4861].