draft-ietf-v6ops-onlinkassumption-01.txt   draft-ietf-v6ops-onlinkassumption-02.txt 
Network Working Group S. Roy Network Working Group S. Roy
Internet-Draft A. Durand Internet-Draft A. Durand
Expires: August 31, 2004 J. Paugh Expires: November 5, 2004 J. Paugh
Sun Microsystems, Inc. Sun Microsystems, Inc.
March 2, 2004 May 7, 2004
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
draft-ietf-v6ops-onlinkassumption-01.txt draft-ietf-v6ops-onlinkassumption-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2004. This Internet-Draft will expire on November 5, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document proposes a change to the IPv6 Neighbor Discovery This document describes a change to the IPv6 Neighbor Discovery
conceptual host sending algorithm. According to the algorithm, when conceptual host sending algorithm. According to the algorithm, when
a host's default router list is empty, the host assumes that all a host's default router list is empty, the host assumes that all
destinations are on-link. This is particularly problematic with destinations are on-link. This is particularly problematic with
IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g.,
no default router). This document describes how making this no default router). This document describes how making this
assumption causes problems, and describes how these problems outweigh assumption causes problems, and describes how these problems outweigh
the benefits of this part of the conceptual sending algorithm. the benefits of this part of the conceptual sending algorithm.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background on the On-link Assumption . . . . . . . . . . . . . 3 2. Background on the On-link Assumption . . . . . . . . . . . . . 3
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 First Rule of Destination Address Selection . . . . . . . . . 3 3.1 First Rule of Destination Address Selection . . . . . . . 3
3.2 Delays Associated with Address Resolution . . . . . . . . . . 4 3.2 Delays Associated with Address Resolution . . . . . . . . 4
3.3 Multi-homing Ambiguity . . . . . . . . . . . . . . . . . . . . 4 3.3 Multi-homing Ambiguity . . . . . . . . . . . . . . . . . . 4
3.4 Security Related Issues . . . . . . . . . . . . . . . . . . . 5 3.4 Security Related Issues . . . . . . . . . . . . . . . . . 5
4. Proposed Changes to RFC2461 . . . . . . . . . . . . . . . . . 5 4. Proposed Changes to RFC2461 . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Informative References . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 6
6.2 Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
B. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 7 B. Changes from draft-ietf-v6ops-onlinkassumption-01 . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8 C. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
1. Introduction 1. Introduction
Neighbor Discovery for IPv6 [ND] defines a conceptual sending Neighbor Discovery for IPv6 [ND] defines a conceptual sending
algorithm for hosts. This algorithm states that if a host's default algorithm for hosts. This algorithm states that if a host's default
router list is empty, then the host assumes that all destinations are router list is empty, then the host assumes that all destinations are
on-link. on-link.
This assumption is problematic with IPv6-capable nodes that do not This assumption is problematic with IPv6-capable nodes that do not
have off-link IPv6 connectivity. Specifically, it creates problems have off-link IPv6 connectivity. Specifically, it creates problems
for destination address selection as defined in [ADDRSEL], and adds for destination address selection as defined in [ADDRSEL], and adds
connection delays associated with unnecessary address resolution and connection delays associated with unnecessary address resolution and
neighbor unreachability detection. The behavior associated with the neighbor unreachability detection. The behavior associated with the
assumption is undefined in multihomed scenarios, and has some subtle assumption is undefined in multihomed scenarios, and has some subtle
security implications. All of these issues are discussed in this security implications. All of these issues are discussed in this
document. document.
A revision of Neighbor Discovery [NDBIS] is removing the on-link
assumption from the specification, but this memo gives historical
reference and background to why this is has been a good decision.
2. Background on the On-link Assumption 2. Background on the On-link Assumption
This part of Neighbor Discovery's [ND] conceptual sending algorithm This part of Neighbor Discovery's [ND] conceptual sending algorithm
was created to facilitate communication on a single link between was created to facilitate communication on a single link between
systems manually configured with different global prefixes. For systems manually configured with different global prefixes. For
example, consider the case where two systems on separate links are example, consider the case where two systems on separate links are
manually configured with global addresses, and are then plugged in manually configured with global addresses, and are then plugged in
back-to-back. They can still communicate with each other via their back-to-back. They can still communicate with each other via their
global addresses because they'll correctly assume that each is global addresses because they'll correctly assume that each is
on-link. on-link.
Without the on-link assumption, the above scenario wouldn't work as Without the on-link assumption, the above scenario wouldn't work as
seamlessly. One workaround would be to use link-local addresses for seamlessly. One workaround would be to use link-local addresses for
this communication. Another is to configure new global addresses this communication. Another is to configure new global addresses
using the same /64 prefix on these systems, either by manually using the same /64 prefix on these systems, either by manually
configuring such addresses, or by placing a router on-link that configuring such addresses or by placing a router on-link that
advertises this prefix. advertises this prefix, however users may not have appropriate
privileges or knowledge to implement this workaround.
3. Problems 3. Problems
The on-link assumption causes the following problems. The on-link assumption causes the following problems.
3.1 First Rule of Destination Address Selection 3.1 First Rule of Destination Address Selection
Default Address Selection for IPv6 [ADDRSEL] defines a destination Default Address Selection for IPv6 [ADDRSEL] defines a destination
address selection algorithm that takes an unordered list of address selection algorithm that takes an unordered list of
destination addresses as input, and produces a sorted list of destination addresses as input, and produces a sorted list of
destination addresses as output. The algorithm consists of destination addresses as output. The algorithm consists of
destination address sorting rules, the first of which is "Avoid destination address sorting rules, the first of which is "Avoid
unusable destinations". The idea behind this rule is to place unusable destinations". The idea behind this rule is to place
unreachable destinations at the end of the sorted list so that unreachable destinations at the end of the sorted list so that
applications will be least likely to try to communicate with those applications will be least likely to try to communicate with those
addresses first. addresses first.
The unreachability determination for a destination as it pertains to The on-link assumption could potentially cause false positives when
this rule is an implementation detail. One implementable method is attempting unreachability determination for this rule. On a network
to do a simple forwarding table lookup on the destination, and to where there is no IPv6 router (all off-link IPv6 destinations are
deem the destination as reachable if the lookup succeeds. The unreachable), the on-link assumption states that destinations are
Neighbor Discovery on-link assumption makes this method somewhat assumed to be on-link. An implementation could interpret that as, if
irrelevant, however, as an implementation of the assumption could the default router list is empty, then all destinations are
simply be to insert an IPv6 default on-link route into the system's reachable. This causes the rule to not necessarily prefer reachable
forwarding table when the default router list is empty. The IPv4 destinations over unreachable IPv6 destinations, resulting in
side-effect is that the rule would always determine that all IPv6 unreachable destinations being placed at the front of the sorted
destinations are reachable. list.
On a network where there is no IPv6 router (all off-link IPv6
destinations are unreachable) and there is off-link IPv4
connectivity, the on-link assumption causes the rule to not
necessarily prefer reachable IPv4 destinations over unreachable IPv6
destinations. This results in unreachable destinations being placed
at the front of the sorted list.
3.2 Delays Associated with Address Resolution 3.2 Delays Associated with Address Resolution
Users expect that applications quickly connect to a given destination Users expect that applications quickly connect to a given destination
regardless of the number of IP addresses assigned to that regardless of the number of IP addresses assigned to that
destination. If a destination name resolves to multiple addresses destination. If a destination name resolves to multiple addresses
and the application attempts to communicate to each address until one and the application attempts to communicate to each address until one
succeeds, this process shouldn't take an unreasonable amount of time. succeeds, this process shouldn't take an unreasonable amount of time.
It is therefore important that the system quickly determine if IPv6 It is therefore important that the system quickly determine if IPv6
destinations are unreachable so that the application can try other destinations are unreachable so that the application can try other
skipping to change at page 5, line 37 skipping to change at page 5, line 35
The on-link assumption discussed here introduces a security The on-link assumption discussed here introduces a security
vulnerability to the Neighbor Discovery protocol described in section vulnerability to the Neighbor Discovery protocol described in section
4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [PSREQ] 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [PSREQ]
titled "Default router is 'killed'". There is a threat that a host's titled "Default router is 'killed'". There is a threat that a host's
router can be maliciously killed in order to cause the host to start router can be maliciously killed in order to cause the host to start
sending all packets on-link. The attacker can then spoof off-link sending all packets on-link. The attacker can then spoof off-link
nodes by sending packets on the same link as the host. The nodes by sending packets on the same link as the host. The
vulnerability is discussed in detail in [PSREQ]. vulnerability is discussed in detail in [PSREQ].
Another security related side-effect of the on-link assumption has to Another security related side-effect of the on-link assumption has to
do with VPN's. It has been observed that some commercially available do with virtual private networks (VPN's). It has been observed that
VPN software solutions that don't support IPv6 send IPv6 packets to some commercially available VPN software solutions that don't support
the local media in the clear (their security policy doesn't simply IPv6 send IPv6 packets to the local media in the clear (their
drop IPv6 packets). Consider a scenario where a system has a single security policy doesn't simply drop IPv6 packets). Consider a
Ethernet interface with VPN software that encrypts and encapsulates scenario where a system has a single Ethernet interface with VPN
certain packets. The system attempts to send a packet to an IPv6 software that encrypts and encapsulates certain packets. The system
destination that it obtained by doing a DNS lookup, and the packet attempts to send a packet to an IPv6 destination that it obtained by
ends up going in the clear to the local media. A malicious second doing a DNS lookup, and the packet ends up going in the clear to the
party could then spoof the destination on-link. local media. A malicious second party could then spoof the
destination on-link.
4. Proposed Changes to RFC2461 4. Proposed Changes to RFC2461
This document suggests the following changes to the Neighbor This document suggests the following changes to the Neighbor
Discovery [ND] specification: Discovery [ND] specification:
The last sentence of the second paragraph of section 5.2 The last sentence of the second paragraph of section 5.2
("Conceptual Sending Algorithm") should be removed. This sentence ("Conceptual Sending Algorithm") should be removed. This sentence
is currently, "If the Default Router List is empty, the sender is currently, "If the Default Router List is empty, the sender
assumes that the destination is on-link. assumes that the destination is on-link.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
link-layer address resolution when sending to such a destination, a link-layer address resolution when sending to such a destination, a
node should send an ICMPv6 Destination Unreachable message (code 0 - node should send an ICMPv6 Destination Unreachable message (code 0 -
no route to destination) message up the stack. no route to destination) message up the stack.
5. Security Considerations 5. Security Considerations
The removal of the on-link assumption from Neighbor Discovery removes The removal of the on-link assumption from Neighbor Discovery removes
some security related vulnerabilities of the protocol as described in some security related vulnerabilities of the protocol as described in
Section 3.4. Section 3.4.
Normative References 6. References
6.1 Normative References
[ADDRSEL] Draves, R., "Default Address Selection for Internet [ADDRSEL] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998. 1998.
[PSREQ] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [PSREQ] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery trust models and threats", October 2003. Discovery trust models and threats", October 2003.
draft-ietf-send-psreq-04 draft-ietf-send-psreq-04
Informative References 6.2 Informative References
[AUTOCONF] [AUTOCONF]
Thomson, S. and T. Narten, "IPv6 Stateless Address Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[NDBIS] Narten, T., Nordmark, E., Simpson, W., Soliman, H. and J.
Tatuya, "Neighbor Discovery for IP Version 6 (IPv6)",
February 2004.
draft-soliman-ipv6-2461-bis-01
Authors' Addresses Authors' Addresses
Sebastien Roy Sebastien Roy
Sun Microsystems, Inc. Sun Microsystems, Inc.
1 Network Drive 1 Network Drive
UBUR02-212 UBUR02-212
Burlington, MA 01801 Burlington, MA 01801
EMail: sebastien.roy@sun.com EMail: sebastien.roy@sun.com
skipping to change at page 7, line 34 skipping to change at page 7, line 36
Sun Microsystems, Inc. Sun Microsystems, Inc.
17 Network Circle 17 Network Circle
UMPK17-202 UMPK17-202
Menlo Park, CA 94025 Menlo Park, CA 94025
EMail: james.paugh@sun.com EMail: james.paugh@sun.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of Jim Bound, The authors gratefully acknowledge the contributions of Jim Bound,
Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol. Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald
van der Pol.
Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-00 Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-01
o Clarrified in the abstract and introduction that the problem is o Added text in the Introduction stating that rfc2461bis has removed
the on-link assumption, and that this memo gives the historical
reference and background for its removal.
o Stated in Section 2 that users may not have sufficient privileges
or knowledge to manually configure addresses or routers in order
to work-around the lack of an on-link assumption.
o Removed implementation details of the on-link assumption from
Section 3.1.
o Miscellaneous editorial changes.
Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-00
o Clarified in the abstract and introduction that the problem is
with systems that are IPv6 enabled but have no off-link with systems that are IPv6 enabled but have no off-link
connectivity. connectivity.
o In section Section 3.3, clarified that soliciting on all links o In Section 3.3, clarified that soliciting on all links could have
could have ambiguous results. ambiguous results.
o The old Security Considerations section was moved to section o The old Security Considerations section was moved to Section 3.4,
Section 3.4, and the new Security Considerations section refers to and the new Security Considerations section refers to that new
that new section. section.
o Miscelaneous editorial changes. o Miscellaneous editorial changes.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/