Movatterモバイル変換

Network Working Group                                             S. RoyRequest for Comments: 4943                        Sun Microsystems, Inc.Category: Informational                                        A. Durand                                                                 Comcast                                                                J. Paugh                                                           Nominum, Inc.                                                          September 2007IPv6 Neighbor Discovery On-Link Assumption Considered HarmfulStatus 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  Background on the On-link Assumption  . . . . . . . . . . . . .23.  Problems  . . . . . . . . . . . . . . . . . . . . . . . . . . .33.1.  First Rule of Destination Address Selection . . . . . . . .33.2.  Delays Associated with Address Resolution . . . . . . . . .33.3.  Multi-interface Ambiguity . . . . . . . . . . . . . . . . .43.4.  Security-Related Issues . . . . . . . . . . . . . . . . . .44.  Changes toRFC 2461 . . . . . . . . . . . . . . . . . . . . . .55.  Security Considerations . . . . . . . . . . . . . . . . . . . .56.  Normative References  . . . . . . . . . . . . . . . . . . . . .6Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . .7Roy, et al.                  Informational                      [Page 1]

RFC 4943               On-Link Assumption Harmful         September 20071.  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 inSection 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).Roy, et al.                  Informational                      [Page 2]

RFC 4943               On-Link Assumption Harmful         September 20073.  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 that takes an unordered list of   destination addresses as input and produces a sorted list of   destination addresses as output.  The algorithm consists of   destination address sorting rules, the first of which is "Avoid   unusable destinations".  The idea behind this rule is to place   unreachable destinations at the end of the sorted list so that   applications will be least likely to try to communicate with those   addresses first.   The on-link assumption could potentially cause false positives when   attempting unreachability determination for this rule.  On a network   where there is no IPv6 router (all off-link IPv6 destinations are   unreachable), the on-link assumption states that destinations are   assumed to be on-link.  An implementation could interpret that as, if   the default router list is empty, then all destinations are reachable   on-link.  This may cause the rule to prefer an unreachable IPv6   destination over a reachable IPv4 destination.3.2.  Delays Associated with Address Resolution   Users expect that applications quickly connect to a given destination   regardless of the number of IP addresses assigned to that   destination.  If a destination name resolves to multiple addresses   and the application attempts to communicate to each address until one   succeeds, this process shouldn't take an unreasonable amount of time.   It is therefore important that the system quickly determine if IPv6   destinations are unreachable so that the application can try other   destinations when those IPv6 destinations are unreachable.   For an IPv6-enabled host deployed on a network that has no IPv6   routers, the result of the on-link assumption is that link-layer   address resolution must be performed on all IPv6 addresses to which   the host sends packets.  The application will not receive   acknowledgment of the unreachability of destinations that are not on-   link until at least address resolution has failed, which is no less   than 3 seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER).  This is   greatly amplified by transport protocol delays.  For example,[RFC1122] Section 4.2.3.5 requires that TCP retransmit for at least 3   minutes before aborting the connection attempt.Roy, et al.                  Informational                      [Page 3]

RFC 4943               On-Link Assumption Harmful         September 2007   When the application has a large list of off-link unreachable IPv6   addresses followed by at least one reachable IPv4 address, the delay   associated with Neighbor Unreachability Detection (NUD) of each IPv6   address before successful communication with the IPv4 address is   unacceptable.3.3.  Multi-interface Ambiguity   There is no defined way to implement this aspect of the sending   algorithm on a node that is attached to multiple links.   Specifically, a problem arises when a node is faced with sending a   packet to an IPv6 destination address to which it has no route, and   the sending node is attached to multiple links.  With the on-link   assumption, this node assumes that the destination is on-link, but on   which link?  From an implementor's point of view, there are three   ways to handle sending an IPv6 packet to a destination in the face of   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 is indeed on-link, the first option might not   succeed since the wrong link could be picked.  The second option   might succeed in reaching the destination but is more complex to   implement and isn't guaranteed to pick the correct destination.  For   example, there could be more than one node configured with the same   address, each reachable through a different link.  The address by   itself does not disambiguate which destination the sender actually   wanted to reach, so attempting to send the packet to every link is   not guaranteed to reach the anticipated destination.  The third   option, dropping the packet, is equivalent to not making the on-link   assumption at all.  In other words, if there is no route to the   destination, don't attempt to send the packet.  An implementation   that behaves this way would require an administrator to configure   routes to the destination in order to have reachability to the   destination, thus eliminating the ambiguity.3.4.  Security-Related Issues   The on-link assumption discussed here introduces a security   vulnerability to the Neighbor Discovery protocol described inSection4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756]   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 startRoy, et al.                  Informational                      [Page 4]

RFC 4943               On-Link Assumption Harmful         September 2007   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-related side-effect of the on-link assumption has to   do with virtual private networks (VPNs).  It has 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 simply drop IPv6 packets).  Consider a   scenario where a system has a single Ethernet interface with VPN   software that encrypts and encapsulates certain packets.  The system   attempts to send a packet to an IPv6 destination that it obtained by   doing 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.4.  Changes toRFC 2461   The following changes have been made to the Neighbor Discovery   specification between [RFC2461] and [RFC4861]:      The last sentence of the second paragraph ofSection 5.2      ("Conceptual Sending Algorithm") was removed.  This sentence was,      "If the Default Router List is empty, the sender assumes that the      destination is on-link."      Bullet item 3) inSection 6.3.6 ("Default Router Selection") was      removed.  The item read, "If the Default Router List is empty,      assume that all destinations are on-link as specified inSection5.2."      APPENDIX A was modified to remove on-link assumption related text      in bullet item 1) under the discussion on what happens when a      multihomed host fails to receive Router Advertisements.   The result of these changes is that destinations are considered   unreachable when there is no routing information for that destination   (through a default router or otherwise).  Instead of attempting link-   layer address resolution when sending to such a destination, a node   should send an ICMPv6 Destination Unreachable message (code 0 - no   route to destination) message up the stack.5.  Security Considerations   The removal of the on-link assumption from Neighbor Discovery   addresses all of the security-related vulnerabilities of the protocol   as described inSection 3.4.Roy, et al.                  Informational                      [Page 5]

RFC 4943               On-Link Assumption Harmful         September 20076.  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.Roy, et al.                  Informational                      [Page 6]

RFC 4943               On-Link Assumption Harmful         September 2007Appendix A.  Acknowledgments   The authors gratefully acknowledge the contributions of Jim Bound,   Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka   Savola, and Ronald van der Pol.Authors' Addresses   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.comRoy, et al.                  Informational                      [Page 7]

RFC 4943               On-Link Assumption Harmful         September 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   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 takes no position regarding the validity or scope of any   Intellectual Property Rights or other rights that might be claimed to   pertain to the implementation or use of the technology described in   this document or the extent to which any license under such rights   might or might not be available; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat and any   assurances of licenses to be made available, or the result of an   attempt made to obtain a general license or permission for the use of   such proprietary rights by implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at   ietf-ipr@ietf.org.Roy, et al.                  Informational                      [Page 8]