| Internet-Draft | v6fhr | November 2026 |
| Caletka & Linkova | Expires 6 May 2027 | [Page] |
This document provides operational guidance for configuring first-hop routers and first-hop redundancy in IPv6 networks. It also discusses design choices for improving recovery time after a renumbering event.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-calink-v6ops-fhrd/.¶
Discussion of this document takes place on the IPv6 Operations Working Group mailing list (mailto:v6ops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/v6ops/. Subscribe at https://www.ietf.org/mailman/listinfo/v6ops/.¶
Source for this draft and an issue tracker can be found at https://github.com/furry13/fhrc.¶
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 6 May 2027.¶
Copyright (c) 2026 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.¶
Unlike IPv4, the IPv6 protocol supports operation with multiple gateways as a native part of the Neigbor Discovery Protocol [RFC4861]. On the other hand, first hop redundancy protocols used in IPv4 like Virtual Router Redundancy Protocol [RFC9568] can be used for IPv6 as well, making the redundant gateways appear as a single logical gateway.¶
This document discusses different options for deploying redundant first-hop IPv6 gateways to ensure high availability and compatibility with various client implementations. First-hop routers face hosts and provide them with information to configure routing as well as well other network parameters, including but not limited to stateless address autoconfiguration, SLAAC [RFC4862].¶
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.¶
One of the posisble deployment scenarios is to deploy multiple routers in the same link. A host can choose one of those routers as a default router and if the selected router becomes unreachable, switch to another reachable one. If multiple routers are present on a link, Section 6.3.4 of [RFC4861] requiresthat an IPv6 host MUST retain at least two router addresses and SHOULD retain more.¶
If the administrator requires all hosts to use the same router, the following mechanisms can be utilized:¶
Advertize backup routers with Router Lifetime set to zero, changing that value to non-zero automatically when a primary router fails. This approach is similar to one described in [RFC8475].¶
The main disadvantace of this approach is time to recover: a host would only switch to another default router from the list after the Nighbor Unreachability Detection (NUD, [RFC4861]) marks the router as unreachable. The default value would be (without taking randomisation factors into account): ReachableTime milliseconds (to move from REACHABLE to STALE) + DELAY_FIRST_PROBE_TIME + MAX_UNICAST_SOLICITRetransTimer = 30 seconds + 5 second + 31 = 38 seconds.¶
Since those timers timers are protocol constant (see Section 10 of [RFC4861] or vary from one host operating system ti another, it is not possible to influence them from the network side. It is namely not possible to achieve shorter failover time by shortening the Router Lifetime of the active router to a very low value. Not only that leads to frequent sending of Router Advertisements, which has an impact on battery-powered devices [RFC7772], some operating systems are known to ignore routers announced with a very short lifetime.¶
VRRPv3 [RFC9568] specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. A Virtual Router has one or more dedicated virtual IPv6 addresses and a virtual MAC address. Hosts are provided with the virtual IPv6 address as the default router via Router Advertisements. Since the hosts only see a single high available logical gateway, the solution is also useful for hosts with broken IPv6 stacks which cannot correctly process Router Advertisements from multiple independent routers.¶
Section 1.4 of [RFC9568] compares convergence time between NUD (as discussed in the section above) and VRRPv3. Using VRRPv3 default parameters, a backup router can take over a failed default router in three seconds, with the switchover being transparent to hosts.¶
An Anycast Default Gateway assigns the identical IPv6 address and Virtual MAC (VMAC) address across multiple first-hop routers attached to the same broadcast domain or overlay network (e.g., EVPN-VXLAN).¶
Similarly to the previous solution, hosts will configure a single high available logical gateway using Router Advertisements. Because every participating router concurrently processes and forwards first-hop ingress traffic, this approach provides active-active first-hop redundancy and multi-path forwarding. In the event of a router failure, convergence is dictated solely by local physical link-down detection or underlying L2/L3 topology reconvergence.¶
All redundant gateways must correctly forward packets destined to the subnet where the hosts are connected, usually by means of an Internal Gateway Protocol (IGP). By default, this can lead to a routing asymmetry where return traffic uses a different gateway than the forward traffic. This is not a problem, unless some stateful processing like firewall rules or connection tracking takes place on the gateways.¶
If routing asymmetry is not desirable and gateways are operated in active-standby mode, symmetric routing can be achieved by influencing the route metric of the active gateway announced in the IGP together with virtual IP/MAC address failover so that the currently active gateway will provide a more preferred route for the return path.¶
AI: copy some text from draft-link-6man-gulla¶
This document does not introduce any new security considerations. It inherits security considerations of IPv6 (see [RFC9099]).¶
This document has no IANA actions.¶
TODO acknowledge.¶