RFC 7048

Neighbor Unreachability Detection Is Too Impatient 🦋

Okay bestie, this one is an Internet Standards Track doc from the IETF, written by E. Nordmark (Arista Networks) and I. Gashinsky (Yahoo!) 💖. It was published in January 2014 and has ISSN 2070-1721. It updates RFC 4861 (IPv6 Neighbor Discovery), and it doesn't obsolete anything 🧚. It's giving "we're fixing a timeout that was too impatient" energy, and I'm obsessed.

Abstract ✨

IPv6 Neighbor Discovery has this feature called Neighbor Unreachability Detection, and it's SO useful when a host has a backup neighbor (like when there are multiple default routers) 🫶. It lets the host hop over to that backup quickly. By default that takes about 3 seconds after the node starts probing. BUT if there's no backup at all, that timeout is literally way too impatient 😭. This doc sets out relaxed rules for Neighbor Discovery retransmissions, so an implementation can pick different timeout behavior depending on whether alternative neighbors exist. It updates RFC 4861.

Status of This Memo 📜

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741.

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7048 🌸.

Copyright Notice 💅

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc 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 spell out 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
2. Definition of Terms .............................................3
3. Protocol Updates ................................................3
4. Example Algorithm ...............................................6
5. Acknowledgements ................................................7
6. Security Considerations .........................................8
7. References ......................................................8
   7.1. Normative References .......................................8
   7.2. Informative References .....................................8

1. Introduction 🌈

Okay so IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability Detection (NUD), which figures out when a neighbor isn't reachable anymore 👀. The timeouts for NUD are super short. By default that's three transmissions spaced one second apart 😳. Short timeouts make sense when there are alternative neighbors the packets can go to. For example, a host might have several default routers in its Default Router List, or it might have a Neighbor Cache Entry (NCE) that was created by a Redirect message. In those cases, when NUD fails, the host tries the alternative neighbor by redoing the next-hop selection. That means it picks the next router in the Default Router List, or it discards the NCE created by a Redirect message, depending on which case you're in 🦋.

The timeouts in [RFC4861] were picked to be short so they'd be optimized for scenarios where alternative neighbors are available. Makes sense, right? 🧠

BUT when there's no alternative neighbor, making NUD probe for longer has real perks. One is that NUD gets more robust against transient failures, like spanning tree reconvergence and other layer 2 issues that can take many seconds to sort out ⏳. Marking the NCE as unreachable in that situation causes extra multicast on the network 📡. Assuming there are IP packets to send, not having an NCE means multicast Neighbor Solicitations go out (to the solicited-node multicast address) every second. NUD would have sent unicast Neighbor Solicitations instead 🙈.

So the result is that IPv6 Neighbor Discovery is operationally more brittle than the IPv4 Address Resolution Protocol (ARP) 😤. For IPv4, there's no mandatory time limit on ARP retransmission behavior [RFC0826], which lets implementors pick more robust schemes 💪.

The following constant values in [RFC4861] seem to have become part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT, MAX_UNICAST_SOLICIT, and RETRANS_TIMER 🎯. Strict conformance testing does seem consistent with [RFC4861], but it means the standard needs an update so IPv6 Neighbor Discovery can be as robust as ARP. Iconic glow-up needed 🌸.

This document updates RFC 4861 to relax the retransmission rules.

More motivations for making IPv6 Neighbor Discovery sturdier in degenerate conditions are covered in [RFC6583] 🫶.

2. Definition of Terms 📖

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] 🎀.

3. Protocol Updates 🔥

Discarding the NCE after three packets spaced one second apart is only needed when an alternative neighbor is available, like an additional default router or discarding an NCE created by a Redirect 🧚.

If an implementation transmits more than MAX_UNICAST_SOLICIT/MAX_MULTICAST_SOLICIT packets, then it SHOULD use the exponential backoff of the retransmit timer. The reason is to avoid significant load from a steady background level of retransmissions, from implementations that retransmit a large number of Neighbor Solicitations (NS) before discarding the NCE 💜.

Even if there's no alternative neighbor, the protocol still needs to handle the case where the link-layer address of the neighbor/target has changed. It does that by switching to multicast Neighbor Solicitations at some point in time 🦋.

To capture all the cases above, this document introduces a brand new UNREACHABLE state in the conceptual model described in [RFC4861] ✨. An NCE in the UNREACHABLE state keeps its link-layer address, and IPv6 packets keep getting sent to that link-layer address. But in the UNREACHABLE state, the NUD Neighbor Solicitations are multicast (to the solicited-node multicast address), and they use a timeout that follows an exponential backoff 🌈.

Wherever [RFC4861] says to discard/delete the NCE after N probes (Sections 7.3 and 7.3.3, and Appendix C), this document instead specifies a transition to the UNREACHABLE state 💅.

If the Neighbor Cache Entry was created by a Redirect message, a node MAY delete the NCE instead of changing its state to UNREACHABLE. In any case, the node SHOULD NOT use an NCE created by a Redirect to send packets if that NCE is in the UNREACHABLE state. Packets should be sent following the next-hop selection algorithm in [RFC4861], Section 5.2, which disregards NCEs that aren't reachable 🙅‍♀️.

Section 6.3.6 of [RFC4861] says default routers that are "known to be reachable" are preferred. For that section's purposes, if the NCE for the router is in the UNREACHABLE state, it is not known to be reachable. So the particular text in Section 6.3.6 that says "in any state other than INCOMPLETE" needs to be extended to say "in any state other than INCOMPLETE or UNREACHABLE" 🫶.

Apart from using multicast NS instead of unicast NS, and the exponential backoff of the timer, the UNREACHABLE state works the same as the current PROBE state 🌸.

A node MAY garbage collect a Neighbor Cache Entry at any time, as specified in [RFC4861]. That freedom to garbage collect doesn't change when the UNREACHABLE state gets introduced into the conceptual model. An implementation MAY prefer garbage collecting UNREACHABLE NCEs over other NCEs 🗑️.

There's a non-obvious extension to the state-machine description in Appendix C of [RFC4861], for the case "NA, Solicited=1, Override=0. Different link-layer address than cached". There we need to add "UNREACHABLE" to the current list of "STALE, PROBE, Or DELAY". In other words, the NCE would stay unchanged. There's no matching change needed to the text in [RFC4861], Section 7.2.5, since it's phrased with "Otherwise" instead of explicitly listing the three states 🧐.

The other state transitions in Appendix C handle the introduction of the UNREACHABLE state without any change, since they're described using "not INCOMPLETE" 💖.

There's also the more obvious change I described above. [RFC4861] has this:

State           Event                   Action             New state

PROBE           Retransmit timeout,     Discard entry         -
                N or more
                retransmissions.

That needs to be replaced by:

State           Event                   Action             New state

PROBE           Retransmit timeout,     Increase timeout  UNREACHABLE
                N retransmissions.      Send multicast NS

UNREACHABLE     Retransmit timeout      Increase timeout  UNREACHABLE
                                        Send multicast NS

The exponential backoff SHOULD be clamped at some reasonable maximum retransmit timeout, such as 60 seconds (see MAX_RETRANS_TIMER below) 🎀. If there's no IPv6 packet sent using the UNREACHABLE NCE, then it is RECOMMENDED to stop the retransmits of the multicast NS until either the NCE is garbage collected or there are IPv6 packets sent using the NCE. The multicast NS and associated exponential backoff can be applied on the condition of continued use of the NCE to send IPv6 packets to the recorded link-layer address 🦋.

A node can unicast the first few Neighbor Solicitation messages even while in the UNREACHABLE state, but it MUST switch to multicast Neighbor Solicitations within 60 seconds of the initial retransmission, so it can handle a link-layer address change for the target 🚨. The example below shows that behavior 👑.

4. Example Algorithm ✨

okay so this section is NOT normative 💅 it's just a simple implementation that totally conforms with the doc. the vibe is operator-configurable values, so you can tune it to be compatible with the retransmission behavior in [RFC4861] 🎀 the knobs are MAX_UNICAST_SOLICIT, MAX_MULTICAST_SOLICIT, RETRANS_TIMER, plus the new BACKOFF_MULTIPLE, MAX_RETRANS_TIMER, and MARK_UNREACHABLE 🦋 and honestly the whole algorithm can be as simple as:

next_retrans = ($BACKOFF_MULTIPLE ^ $solicit_retrans_num) *
$RetransTimer * $JitterFactor

where solicit_retrans_num is zero for the first transmission, and JitterFactor is a random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR [RFC4861] so hosts don't all fire in sync 🌸 (no synchronized transmissions from different hosts, bestie 🫶)

after MARK_UNREACHABLE transmissions, the implementation marks the NCE UNREACHABLE and then goes hunting for alternate next hops 🧚. after MAX_UNICAST_SOLICIT, it switches to multicast NUD probes 💜

so the behavior here is 5 attempts: the first at time 0 (initial request), then 1 second later, 3 seconds after the first retransmission, then 9, then 27, and it switches to UNREACHABLE after the first three transmissions 😭 counting from the very first send, the retransmissions land at 1 second, 4 seconds, 13 seconds, and finally 40 seconds. at 4 seconds the NCE gets marked UNREACHABLE. the config for that is:

MAX_UNICAST_SOLICIT=5

RETRANS_TIMER=1 (default)

MAX_RETRANS_TIMER=60

BACKOFF_MULTIPLE=3

MARK_UNREACHABLE=3

after 3 retransmissions the NCE gets marked UNREACHABLE, and that leads to trying an alternative neighbor, like another default router, or ignoring an NCE created by a Redirect as specified in [RFC4861] 🍓. with these values that happens 4 seconds after the first transmission, vs. 2 seconds with the fixed scheme in [RFC4861]. that extra delay is small compared to the default ReachableTime of 30,000 milliseconds, iykyk 💖

after 5 transmissions (40 seconds after the initial one) the example switches to multicast NUD probes. in the state machine language of [RFC4861], that's the action "Discard entry" 💀 so any attempt to send future packets results in sending multicast NS packets. an implementation MAY retain the backoff value as it switches to multicast NUD probes 🌈 the potential downside of deferring the switch to multicast is that NUD takes longer to handle a change in a link-layer address (the case where a host or router changes its link-layer address but keeps the same IPv6 address) 🙈. however, [RFC4861] says a node MAY send unsolicited NS to handle that case, which is pretty infrequent in operational networks ✨. either way, the implementation needs to follow the "SHOULD" in Section 3 and switch to multicast solutions within 60 seconds after the initial transmission 👑

if BACKOFF_MULTIPLE=1, MARK_UNREACHABLE=3, and MAX_UNICAST_SOLICIT=3, you get the exact same behavior as [RFC4861] 🫶

if the request wasn't answered at first (say, because of a transitory condition) an implementation following this algorithm retries immediately and then backs off for progressively longer periods 🦋. that means a reasonably fast resolution time once the transitory condition clears 🔥

note that RetransTimer and ReachableTime are set by default from the protocol constants RETRANS_TIMER and REACHABLE_TIME, but they get overridden by values advertised in Router Advertisements as specified in [RFC4861] 💅. that stays true even with the protocol updates in this document. the key values the operator would configure are BACKOFF_MULTIPLE, MAX_RETRANS_TIMER, MAX_UNICAST_SOLICIT, and MAX_MULTICAST_SOLICIT 🎀

it's useful to have a maximum value for ($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RetransTimer so the retransmissions aren't too far apart 🧚. the 60 second value for MAX_RETRANS_TIMER is consistent with DHCPv6 🌸

5. Acknowledgements 🫶

the comments from Thomas Narten, Philip Homburg, Joel Jaeggli, Hemant Singh, Tina Tsou, Suresh Krishnan, and Murray Kucherawy helped improve this document 💜

6. Security Considerations 💀

relaxing the retransmission behavior for NUD is believed to have no impact on security 🔒. in particular, it doesn't impact the application of Secure Neighbor Discovery [RFC3971] 😭

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
           Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           September 2007.

7.2. Informative References

[RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
           converting network protocol addresses to 48.bit Ethernet
           address for transmission on Ethernet hardware", STD 37,
           RFC 826, November 1982.

[RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
           Neighbor Discovery Problems", RFC 6583, March 2012.

Authors' Addresses 🎀

Erik Nordmark
Arista Networks
Santa Clara, CA
USA

EMail: nordmark@acm.org


Igor Gashinsky
Yahoo!
45 W 18th St
New York, NY
USA

EMail: igor@yahoo-inc.com