IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
RFC 4943
|
| Document |
Type |
|
RFC - Informational
(September 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4943 (Informational)
|
|
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
Show full document text