First Hop Redundancy in IPv6 Networks: Operational Considerations
draft-calink-v6ops-fhrd-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ondřej Caletka , Jen Linkova | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-calink-v6ops-fhrd-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/rfc/rfc4191>.
[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,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
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,
<https://www.rfc-editor.org/rfc/rfc9568>.
8.2. Informative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/rfc/rfc4862>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/rfc/rfc7772>.
[RFC8475] Linkova, J. and M. Stucchi, "Using Conditional Router
Advertisements for Enterprise Multihoming", RFC 8475,
DOI 10.17487/RFC8475, October 2018,
<https://www.rfc-editor.org/rfc/rfc8475>.
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
"Operational Security Considerations for IPv6 Networks",
RFC 9099, DOI 10.17487/RFC9099, August 2021,
<https://www.rfc-editor.org/rfc/rfc9099>.
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]