IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
RFC 4943
Document | Type | RFC - Informational (September 2007; No errata) | |
---|---|---|---|
Authors | Alain Durand , Sebastien Roy , James Paugh | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4943 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | David Kessens | ||
Send notices to | kurtis@kurtis.pp.se |
Network Working Group S. Roy Request for Comments: 4943 Sun Microsystems, Inc. Category: Informational A. Durand Comcast J. Paugh Nominum, Inc. September 2007 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending 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 Roy, et al. Informational [Page 1] RFC 4943 On-Link Assumption Harmful September 2007 1. Introduction Neighbor Discovery for IPv6 [RFC4861] defines a conceptual sending algorithm for hosts. The version of the algorithm described in [RFC2461] states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This memo documents the removal of this assumption in the updated Neighbor Discovery specification [RFC4861] and describes the reasons why this assumption was removed. This assumption is problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity. This is typical when systems that have IPv6 enabled on their network interfaces (either on by default or administratively configured that way) are attached to networks that have no IPv6 services such as off-link routing. Such systems will resolve DNS names to AAAA and A records, and they may attempt to connect to unreachable IPv6 off-link nodes. The on-link assumption creates problems for destination address selection as defined in [RFC3484], and it adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined on multi-interface nodes and has some subtle security implications. All of these issues are discussed in this document. 2. Background on the On-link Assumption This part of Neighbor Discovery's [RFC2461] conceptual sending algorithm was created to facilitate communication on a single link between systems configured with different global prefixes in the absence of an IPv6 router. For example, consider the case where two systems on separate links are manually configured with global addresses and are then plugged in back-to-back. They can still communicate with each other via their global addresses because they'll correctly assume that each is on-link. Without the on-link assumption, the above scenario wouldn't work, and the systems would need to be configured to share a common prefix such as the link-local prefix. On the other hand, the on-link assumption introduces several problems to various parts of the networking stack described in Section 3. As such, this document points out that the problems introduced by the on-link assumption outweigh the benefit that the assumption lends to this scenario. It is more beneficial to the end user to remove the on-link assumption from Neighbor Discovery and declare this scenario illegitimate (or a misconfiguration).Show full document text