RFC 7559

Packet-Loss Resiliency for Router Solicitations

📅 published May 2015, from ietf

RFC 7559: Packet-Loss Resiliency for Router Solicitations 🎀

  • Who wrote it: S. Krishnan (Ericsson), D. Anipko (Unaffiliated), and D. Thaler (Microsoft), all for the Internet Engineering Task Force (IETF) 💖
  • Category: Standards Track, so it's a real Internet Standard 🔥
  • Date: May 2015 📅
  • Updates: RFC 4861 🧩
  • ISSN: 2070-1721

Abstract 💌

Okay so when an interface on a host first starts up, the host sends Router Solicitations so it doesn't have to wait forever for the next unsolicited multicast Router Advertisement. 🦋 Sometimes those early RSs get lost, and this doc is all about how hosts cope when that happens. ✨

Status of This Memo 📜

This is an Internet Standards Track document. 🌈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). 👑 More info on Internet Standards is in Section 2 of RFC 5741.

Want the current status, any errata, or a place to send feedback? Check http://www.rfc-editor.org/info/rfc7559 🔗

Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🫶

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
2.  Proposed Algorithm  . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Stopping the Retransmissions  . . . . . . . . . . . . . .   3
3.  Configuring the Use of Retransmissions  . . . . . . . . . . .   4
4.  Known Limitations . . . . . . . . . . . . . . . . . . . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction 🌸

Picture this. As [RFC4861] lays out, when an interface on a host starts up, the host wants Router Advertisements fast, so it sends up to MAX_RTR_SOLICITATIONS (3) Router Solicitation (RS) messages, each one at least RTR_SOLICITATION_INTERVAL (4) seconds apart. 🧚

Those RSs can get lost in some situations. For example, the host is hooked up to a bridged residential gateway over Ethernet or Wi-Fi. LAN connectivity works the moment the interface comes up, but the upstream WAN connection isn't active yet. So the host just gives up after its initial RS retransmits. 💀

Once those first RSs are lost, the host gives up and assumes there are no routers on the link, as described in Section 6.3.7 of [RFC4861]. 🙈 Then it has no Internet connectivity at all until the next unsolicited multicast Router Advertisement shows up. Those get sent at most MaxRtrAdvInterval seconds apart (maximum value 1800 seconds), so in the worst case a host could be offline for 30 minutes. 😭 That delay may be unacceptable in some scenarios.

1.1. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔑

2. Proposed Algorithm 🚀

To be resilient to packet loss, the host needs to keep retransmitting Router Solicitations until it gets a Router Advertisement, or until it's willing to accept that no router exists. 💅 But if it keeps retransmitting every RTR_SOLICITATION_INTERVAL seconds, it may cause excessive network traffic when a huge number of hosts are doing it. 📈 So to stay resilient while keeping the aggregate traffic low, the host can use some form of exponential backoff to retransmit the RSs. 🌊

Hosts complying to this specification MUST use the exponential backoff algorithm for retransmits that is described in Section 14 of [RFC3315], so they keep retransmitting the Router Solicitations until a Router Advertisement is received. ✨ The hosts SHOULD use the following variables as input to the retransmission algorithm:

IRT (Initial Retransmission Time):     4 seconds
MRT (Maximum Retransmission Time):  3600 seconds
MRC (Maximum Retransmission Count):    0
MRD (Maximum Retransmission Duration): 0

The starting value IRT was picked to match the current retransmission interval (RTR_SOLICITATION_INTERVAL) specified by [RFC4861]. The maximum retransmission time MRT was picked to match the new value of SOL_MAX_RT specified by [RFC7083]. 🎀 The point is that the short-term behaviour of the RSs looks like what people already see on current networks, and the long-term persistent retransmission behaviour trends toward what DHCPv6 does [RFC3315] [RFC7083]. 🫶

2.1. Stopping the Retransmissions 🛑

On multicast-capable links, the hosts following this specification SHOULD stop retransmitting the RSs when Router Discovery succeeds (i.e., an RA with a non-zero Router Lifetime that results in a default route is received). 🎉 If an RA comes in from a router and it doesn't result in a default route (i.e., Router Lifetime is zero), the host MUST continue retransmitting the RSs. 🙅‍♀️

On non-multicast links, the hosts following this specification MUST continue retransmitting the RSs even after an RA that results in a default route is received. 🧐 This is required because, on links like that, sending an RA can only be triggered by an RS. Please note that these links have special mechanisms for sending RSs too. For example, the mechanism in Section 8.3.4 of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] unicasts the RSs to specific routers. 🦋

3. Configuring the Use of Retransmissions ⚙️

Implementations of this specification are encouraged to provide a configuration option to enable or disable potentially infinite RS retransmissions. 🧠 If a configuration option is provided, it MUST enable RS retransmissions by default. 💜 Giving people a way to enable or disable retransmissions on a per-interface basis lets network operators set RS behaviour in whatever way fits each connected link best. 👑

4. Known Limitations 🙈

When an IPv6-capable host attaches to a network that doesn't have IPv6 enabled, it transmits 3 (MAX_RTR_SOLICITATIONS) Router Solicitations as specified in [RFC4861]. If it gets no Router Advertisements, it assumes there are no routers on the link and stops sending RSs. 🙃 With the mechanism in this document, though, the host keeps retransmitting RSs indefinitely, at roughly 1 RS per hour. 🕐 It's unclear how to tell apart a network with no IPv6 routers from a link where an IPv6 router is temporarily unreachable but could become reachable later. 🤷‍♀️

5. Security Considerations 💀

This document does not present any additional security issues beyond those discussed in [RFC4861] and those RFCs that update [RFC4861]. 🔒 Nothing new to panic about here, but do keep those other documents in mind. 🫣

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 🫶

The authors want to thank Steve Baillargeon, Erik Kline, Andrew Yourtchenko, Ole Troan, Erik Nordmark, Lorenzo Colitti, Thomas Narten, Ran Atkinson, Allison Mankin, Les Ginsberg, Brian Carpenter, Barry Leiba, Brian Haberman, Spencer Dawkins, Alia Atlas, Stephen Farrell, and Mehmet Ersue for the reviews and suggestions that made this document better. 💖

Authors' Addresses 💌

Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada

Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com


Dmitry Anipko
Unaffiliated

Phone: +1 425 442 6356
EMail: dmitry.anipko@gmail.com


Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA
United States

EMail: dthaler@microsoft.com
📦 where this page comes from