RFC 4943

IPv6 Neighbor Discovery On-Link Assumption Considered Harmful

📅 published September 2007, from ietf

okay bestie, this is an RFC, which is basically the Internet's official rulebook for how protocols work 💅 This one is RFC 4943, dated September 2007. It was written by S. Roy (Sun Microsystems, Inc.), A. Durand (Comcast), and J. Paugh (Nominum, Inc.) 👑 It's Informational, so it's giving "here's some useful info," not "here's a standard you have to follow." The title block doesn't list anything it obsoletes or updates, so no drama there 🙈

Status of This Memo ✨

This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind 🧚 Distribution of this memo is unlimited, so share it with everyone 💜

Abstract 🦋

okay so this doc is all about the history behind why the "on-link assumption" got removed from the conceptual host sending algorithm in Neighbor Discovery for IP Version 6 (IPv6) 😭 In the original version of the algorithm, if a host's default router list was empty, the host assumed that all destinations were on-link. That's a big problem for IPv6-capable nodes that don't have off-link IPv6 connectivity (like, no default router, e.g.). The doc explains how making that assumption causes problems, and how those problems outweigh the benefits of that part of the algorithm 💀

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Background on the On-link Assumption  . . . . . . . . . . . . . 2
3.  Problems  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  3.1.  First Rule of Destination Address Selection . . . . . . . . 3
  3.2.  Delays Associated with Address Resolution . . . . . . . . . 3
  3.3.  Multi-interface Ambiguity . . . . . . . . . . . . . . . . . 4
  3.4.  Security-Related Issues . . . . . . . . . . . . . . . . . . 4
4.  Changes to RFC 2461 . . . . . . . . . . . . . . . . . . . . . . 5
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 7

1. Introduction 💖

okay so [RFC4861] is the newer Neighbor Discovery for IPv6 spec, and it defines a conceptual sending algorithm for hosts 🫶 The version in [RFC2461] said that if a host's default router list is empty, the host assumes that all destinations are on-link. This memo documents the removal of that assumption in the updated Neighbor Discovery spec ([RFC4861]), and explains why it got removed ✨

This assumption is a problem for IPv6-capable nodes that don't have off-link IPv6 connectivity. This is pretty common when systems have IPv6 turned on for their network interfaces (either on by default or set up that way by an admin) and are plugged into networks with no IPv6 services, like off-link routing. These systems will resolve DNS names to AAAA and A records, and they might try to connect to off-link IPv6 nodes that they can't actually reach 😭

The on-link assumption creates problems for destination address selection as defined in [RFC3484]. It also adds connection delays from unnecessary address resolution and neighbor unreachability detection. The behavior tied to the assumption is undefined on multi-interface nodes, and it has some sneaky security implications too 🙈 This doc talks about all of these issues.

okay so this part of Neighbor Discovery's [RFC2461] conceptual sending algorithm was made to help systems talk on a single link when they have different global prefixes and there's no IPv6 router around 🧚 Picture two systems on separate links, both manually given global addresses, and then plugged in back-to-back. They can still talk using those global addresses, because they'll correctly assume each other is on-link.

Without the on-link assumption, that setup wouldn't work. The systems would have to be configured to share a common prefix, like the link-local prefix. On the flip side, the on-link assumption causes several problems in different parts of the networking stack, which are covered in Section 3. So this doc argues that those problems outweigh the benefit the assumption gives this one scenario. It's better for the end user to remove the on-link assumption from Neighbor Discovery and just call this scenario illegitimate (or a misconfiguration) 💅

3. Problems 🔥

The on-link assumption causes the following problems.

3.1. First Rule of Destination Address Selection 👑

Default Address Selection for IPv6 [RFC3484] defines a destination address selection algorithm. It takes an unordered list of destination addresses as input and gives back a sorted list of destination addresses as output. The algorithm has destination address sorting rules, and the first one is "Avoid unusable destinations". The idea behind this rule is to put unreachable destinations at the end of the sorted list, so applications are least likely to try talking to those addresses first 🦋

The on-link assumption could cause false positives when trying to figure out unreachability for this rule. On a network with no IPv6 router (so all off-link IPv6 destinations are unreachable), the on-link assumption says destinations are assumed to be on-link. An implementation could read that as: if the default router list is empty, then all destinations are reachable on-link. That might make the rule prefer an unreachable IPv6 destination over a reachable IPv4 destination, which is so not it 😭

3.2. Delays Associated with Address Resolution 🫠

Users expect applications to connect quickly to a destination, no matter how many IP addresses that destination has. If a destination name resolves to several addresses and the application tries each address until one works, that process shouldn't take an unreasonable amount of time. So it's important that the system quickly figures out whether IPv6 destinations are unreachable, so the application can move on to other destinations when they are 💖

For an IPv6-enabled host on a network with no IPv6 routers, the result of the on-link assumption is that link-layer address resolution has to be done for every IPv6 address the host sends packets to. The application won't hear that a destination that isn't on-link is unreachable until at least address resolution has failed. That takes no less than 3 seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), and transport protocol delays make it way worse 💀 For example, [RFC1122] Section 4.2.3.5 requires that TCP retransmit for at least 3 minutes before it aborts the connection attempt. 3 minutes?! not it 😭

When the application has a long list of unreachable off-link IPv6 addresses followed by at least one reachable IPv4 address, the delay from Neighbor Unreachability Detection (NUD) on each IPv6 address, before it gets to the IPv4 address that works, is unacceptable 🙅‍♀️

3.3. Multi-interface Ambiguity 🌈

There's no defined way to implement this part of the sending algorithm on a node attached to multiple links. The problem shows up when a node needs to send a packet to an IPv6 destination address it has no route to, and the node is attached to multiple links. With the on-link assumption, the node assumes the destination is on-link... but on which link? 🤔 From an implementer's point of view, there are three ways to handle sending an IPv6 packet to a destination with the on-link assumption on a multi-interface node:

  1. Attempt to send the packet on a single link (either administratively pre-defined or using some algorithm).
  2. Attempt to send the packet on every link.
  3. Drop the packet.

If the destination really is on-link, the first option might not work, because the wrong link could get picked. The second option might reach the destination, but it's more complex to implement and isn't guaranteed to pick the correct destination. For example, more than one node could be configured with the same address, each reachable through a different link. The address by itself doesn't tell you which destination the sender actually wanted, so sending to every link isn't guaranteed to reach the intended destination 🫣 The third option, dropping the packet, is the same as not making the on-link assumption at all. In other words, if there's no route to the destination, don't try to send the packet. An implementation that works this way would need an admin to configure routes to the destination for reachability, which gets rid of the ambiguity ✨

The on-link assumption discussed here adds a security vulnerability to the Neighbor Discovery protocol. That's described in Section 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756], titled "Default router is 'killed'". There's a threat that a host's router can be maliciously killed, which would make the host start sending all packets on-link. The attacker can then spoof off-link nodes by sending packets on the same link as the host. The vulnerability is discussed in detail in [RFC3756] 😱

Another security side effect of the on-link assumption has to do with virtual private networks (VPNs). It's been observed that some commercially available VPN software solutions that don't support IPv6 send IPv6 packets to the local media in the clear. Their security policy doesn't just drop IPv6 packets. Here's a scenario: a system has a single Ethernet interface with VPN software that encrypts and encapsulates certain packets. The system tries to send a packet to an IPv6 destination it got from a DNS lookup, and the packet ends up going in the clear to the local media. A malicious third party could then spoof the destination on-link 🥺

okay bestie, this section is seriously important: the VPN thing means packets can leak in the clear, so don't sleep on it 💀

5. Security Considerations ✨

Okay bestie, this is the payoff 💅. Taking the on-link assumption out of Neighbor Discovery wipes out all of the security problems the protocol had, the ones we just went over in Section 3.4. 🔥 Iconic cleanup, no notes 🫶

6. Normative References 📚

  • [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
  • [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
  • [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
  • [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

Appendix A. Acknowledgments 🎀

Huge shoutout 📣 to the people who helped make this happen: Jim Bound, Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol. You're all literally the reason this works 🫶🌸

Authors' Addresses 💌

Here's who wrote it, so you know who to thank (or blame, lol 🙈):

Sebastien Roy Sun Microsystems, Inc. 1 Network Drive UBUR02-212 Burlington, MA 01803

EMail: sebastien.roy@sun.com

Alain Durand Comcast 1500 Market Street Philadelphia, PA 19102

EMail: alain_durand@cable.comcast.com

James Paugh Nominum, Inc. 2385 Bay Road Redwood City, CA 94063

EMail: jim.paugh@nominum.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

Here's the legal fine print, and it's not very cute, but it's important 💀:

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach, or whether a license for them is available. It also doesn't claim to have checked for any such rights itself. If you want info on how rights work for RFC documents, check out BCP 78 and BCP 79 📖

Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses to be made available, or the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that information to ietf-ipr@ietf.org. 💜

📦 where this page comes from