IPv6 Operations O. Caletka Internet-Draft RIPE NCC Intended status: Informational J. Linkova Expires: 6 May 2027 Google, LLC 2 November 2026 First Hop Redundancy in IPv6 Networks: Operational Considerations draft-calink-v6ops-fhrd-00 Abstract 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. About This Document 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. 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 6 May 2027. Caletka & Linkova Expires 6 May 2027 [Page 1] Internet-Draft v6fhr November 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Design Choices to Provide First Hop Redundancy . . . . . . . 3 3.1. Two (or more) independent Routers . . . . . . . . . . . . 3 3.2. Virtual Router Redundancy Protocol (VRRP) or Similar Protocols . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Anycast Default Gateway . . . . . . . . . . . . . . . . . 4 3.4. Routing return traffic back to Hosts . . . . . . . . . . 4 4. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Host Mobility and Renumbering Evens . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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. Caletka & Linkova Expires 6 May 2027 [Page 2] Internet-Draft v6fhr November 2026 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]. 2. Conventions and Definitions 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. 3. Design Choices to Provide First Hop Redundancy 3.1. Two (or more) independent Routers 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: * Configure the default router preference [RFC4191]. * 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_SOLICIT_RetransTimer = 30 seconds + 5 second + 3_1 = 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 Caletka & Linkova Expires 6 May 2027 [Page 3] Internet-Draft v6fhr November 2026 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. 3.2. Virtual Router Redundancy Protocol (VRRP) or Similar Protocols 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. 3.3. Anycast Default Gateway 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. 3.4. Routing return traffic back to Hosts 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. Caletka & Linkova Expires 6 May 2027 [Page 4] Internet-Draft v6fhr November 2026 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. 4. Timers Questions: * How often to send RAs? * How other times in RA should be re: to default router lifetime? 5. Host Mobility and Renumbering Evens AI: copy some text from draft-link-6man-gulla 6. Security Considerations This document does not introduce any new security considerations. It inherits security considerations of IPv6 (see [RFC9099]). 7. IANA Considerations This document has no IANA actions. 8. References 8.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, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Caletka & Linkova Expires 6 May 2027 [Page 5] Internet-Draft v6fhr November 2026 [RFC9568] Lindem, A. and A. Dogra, "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568, DOI 10.17487/RFC9568, April 2024, . 8.2. Informative References [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, . [RFC8475] Linkova, J. and M. Stucchi, "Using Conditional Router Advertisements for Enterprise Multihoming", RFC 8475, DOI 10.17487/RFC8475, October 2018, . [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, . Acknowledgments TODO acknowledge. Authors' Addresses Ondrej Caletka RIPE NCC Email: ondrej.caletka@ripe.net Jen Linkova Google, LLC Email: furry13@gmail.com Caletka & Linkova Expires 6 May 2027 [Page 6]