Network Working Group H. Singh Internet-Draft W. Beebee Intended status: Standards Track Cisco Systems, Inc. Expires: July 21, 2008 January 18, 2008 ND On-link and Off-link Determination draft-wbeebee-on-link-and-off-link-determination-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract RFC 4861 [ND] describes host data forwarding and address resolution. However, nine years after the ND protocol became an RFC, IPv6 hosts still do not fully comply with RFC 4861 [ND]. In particular, hosts incorrectly implement on- vs. off-link data forwarding. This document clarifies host behavior and associated router behavior to define explicitly on-link and off-link determination. Singh & Beebee Expires July 21, 2008 [Page 1] Internet-Draft ND On-link Determination January 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Host Models . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RA Sets the M bit but does not Include the PIO . . . . . . 5 2.2. RA Advertises a Prefix with the On-link(L) Bit Set . . . . 5 2.2.1. When the Valid Lifetime Expires . . . . . . . . . . . 6 2.3. RA Advertises a Prefix with the On-link(L) Bit Clear . . . 6 3. Router Models . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Aggregation Router Deployment Model . . . . . . . . . . . 7 4. Redirect Clarifications . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Singh & Beebee Expires July 21, 2008 [Page 2] Internet-Draft ND On-link Determination January 2008 1. Introduction IPv6 host data forwarding and address resolution is complex. For example, RFC 4861 [ND] (section 3.1) implies that if the RA received by the host does not advertise any prefix, then the host must send all non-link-local data to the default router. This section of the RFC also implies that no address resolution is to be performed in this case. Sections 5.2 and 7.2.2 imply that the host performs address resolution before transmitting a packet if the destination of the packet is on the same link as the host. Some current host implementations perform address resolution in all cases even when the destination is not clearly on-link. However, RFC 4861 [ND] section 6.3.4 implies that hosts must clearly determine that a destination is on-link before performing address resolution. These implications in RFC 4861 [ND] need to be made explicit. Failure of host implementations to comply can result in lack of IPv6 connectivity. One example, included in draft-wbeebee-nd-implementation-problems-00 [I.D.nd-implementation-problems], follows: a host receives an RA with no prefix advertised and incorrectly decides to perform address resolution when the host should have sent all traffic to the default router. The router does not respond to the address resolution and the layer 2 driver of the host stops transmitting IPv6 packets. Host address resolution has implications for router design and deployment. First, host behavior is clarified in the Host Models section. Second, a router deployment model is described in the Router Models section. Third, Redirects are clarified for both routers and hosts in the Redirect Clarifications section. 2. Host Models A correctly implemented IPv6 host MUST adhere to the following rules: 1. On-link determination SHOULD NOT persist across IPv6 interface initializations. Note that section 5.7 of RFC 4862 [ADDRCONF] describes the use of stable storage for addresses acquired with stateless address autoconfiguration with a note that the Preferred and Valid Lifetimes must be retained if this approach is used. 2. The on-link definition in section 2.1 of RFC 4861 [ND] describes the only means for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for on-link determination. Manual configuration of a host introduces its own set of security considerations and is beyond the scope of this Singh & Beebee Expires July 21, 2008 [Page 3] Internet-Draft ND On-link Determination January 2008 document. Note that the on-link definition as specified by RFC 4861 [ND] does not include manual configuration. 3. The host MUST NOT add a directly connected route to the prefix from an assigned address, independent of the information about the prefix received from the sources described in section 2.1 of RFC 4861 [ND]. 4. RFC 4861 [ND] assumes that all prefixes are initially off-link (the host sends data to the default router). RFC 4861 [ND] has no way to indicate that a prefix is off-link. Only when the Prefix Information Option (PIO) of an RA has a set L-bit and a non-zero Valid Lifetime does the on-link status of a prefix change, and it changes to on-link. A prefix with the L-bit cleared does not change the on-link status of prefix and is functionally equivalent to omitting the prefix from the RA. 5. In the absence of other sources of on-link information, including Redirects, if the RA advertises a prefix with the on-link(L) bit set and the Valid Lifetime expires, the host MUST then consider addresses of the prefix to be off-link, as suggested by the PIO paragraph of section 6.3.4 of RFC 4861 [ND]. 6. Newer implementations, which are compliant with RFC 4861 [ND] MUST adhere to the following rules. Older implementations, which are compliant with RFC 2461 [ND] but not RFC 4861 [ND] may remain as is. If the Default Router List is empty and there is no other source of on-link information about any address or prefix: 1. The host MUST NOT assume that all destinations are on-link. 2. The host MUST NOT perform address resolution for non-link- local addresses. 3. Since the host cannot assume the destination is on-link, and off-link traffic cannot be sent to the default router (since the Default Router List is empty), address resolution cannot be performed. This case is analogous to the behavior specified in the last paragraph of section 7.2.2 of RFC 4861 [ND]: when address resolution fails, the host SHOULD send an ICMPv6 Destination Unreachable message. The specified behavior MAY be extended to cover this case where address resolution cannot be performed. On-link information concerning particular addresses and prefixes can make those specific addresses and prefixes on-link, but does not change the default behavior mentioned above for addresses and prefixes not specified. RFC4943 Singh & Beebee Expires July 21, 2008 [Page 4] Internet-Draft ND On-link Determination January 2008 [RFC.ietf-v6ops-onlinkassumptions] provides justification for these rules. The type of RA received can further determine host behavior. 2.1. RA Sets the M bit but does not Include the PIO Section 3.1 of RFC 4861 [ND] describes intended behavior when a host receives an RA without an advertised prefix: "Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate." For example, an IPv6 router can send an RA with no PIO, the M bit set, does not send any Redirects, and does not send any NA or ND messages for non-link local addresses. On receipt of the RA, the host in this example chooses to use DHCPv6 to acquire its IPv6 address. After completing IPv6 address acquisition, the host MUST obey RFC 4861 [ND], section 3.1. In this case, since the RA is the only authority to a host for on-link determination and this RA does not advertise any prefix, the host cannot determine that a destination is on-link. Therefore, the host MUST adhere to the following rules: 1. The host MUST NOT assume any default prefix length. 2. The host MUST send all non-link-local traffic to the default router. 3. The host MUST NOT issue an NS to resolve a destination other than a link-local address. In the presence of Redirects, only the on-link determination of the destination addresses of the original packets for which the Redirects were sent change from what is specified in the rules above. For changes to the on-link determination in the presence of Redirects, see the Redirect Clarifications section. 2.2. RA Advertises a Prefix with the On-link(L) Bit Set Section 6.3.4 of RFC 4861 [ND] mentions that hosts may ignore the valid lifetime for stateless address autoconfiguration. However, this does not apply to on-link determination: Singh & Beebee Expires July 21, 2008 [Page 5] Internet-Draft ND On-link Determination January 2008 "Stateless address autoconfiguration [ADDRCONF] may in some circumstances use a larger Valid Lifetime of a prefix or ignore it completely in order to prevent a particular denial-of-service attack. However, since the effect of the same denial of service targeted at the on-link prefix list is not catastrophic (hosts would send packets to a default router and receive a redirect rather than sending packets directly to a neighbor), the Neighbor Discovery protocol does not impose such a check on the prefix lifetime values." Therefore, when a prefix has been advertised as on-link and the prefix lifetime value has not expired, in the absence of Redirects, any destination included in the prefix will be considered to be on- link, and hosts will issue an NS to resolve the on-link destination. In the presence of Redirects, only the on-link determination of the destination addresses of the original packets for which the Redirects were sent change from what is specified. For changes to the on-link determination in the presence of Redirects, see the Redirect Clarifications section. 2.2.1. When the Valid Lifetime Expires In the absence of other sources of on-link information, including Redirects, regardless of whether the host performs DHCPv6 and/or stateless autoconfiguration, the host MUST adhere to the following rules for addresses contained within the advertised prefix with the on-link bit set and an expired Valid Lifetime: 1. The host MUST NOT issue an NS to resolve a destination other than a link-local address. 2. The host MUST send all non-link-local traffic to the default router. 2.3. RA Advertises a Prefix with the On-link(L) Bit Clear An on-link bit of clear indicates nothing regarding on-link determination. In section 6.3.4 of RFC 4861 [ND]": "...a Prefix Information Option with on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link.... Prefixes with the on-link flag set to zero would normally have the autonomous flag set and be used by [ADDRCONF]." Singh & Beebee Expires July 21, 2008 [Page 6] Internet-Draft ND On-link Determination January 2008 3. Router Models The Redirect Clarifications section clarifies RFC 4861 [ND] host and router behavior for an aggregation router deployment. The Aggregation Router Deployment Model section presents a possible aggregation router deployment model for IPv6 and discusses its properties with respect to ND. Aggregation routers can service more than 100,000 subscribers. Due to scaling considerations, any NS for global address resolution from any host to any other host should not reach the aggregation router. 3.1. Aggregation Router Deployment Model A property of routed aggregation networks is that hosts cannot directly communicate with each other even if they share the same prefix. Physical connectivity between the aggregation router and the modems prevents hosts behind modems to communicate directly with each other. Hosts send their traffic to aggregation router. This design is motivated by scaling and security considerations. If every host could receive all traffic from every other host, then the subscriber's privacy would be violated and the amount of bandwidth available for each subscriber would be very small. That is why hosts communicate between each other through the aggregation router, which is also the IPv6 first-hop router. For scaling reasons, any NS to resolve any address other than that of the default router should not reach the aggregation router. +-----+ | | |Aggre+----(Rtr CPE)----Host1 Core----WAN----+gator| | Rtr | | +----(Br CPE)----(Cust Rtr)----Host2 +-----+ Figure 1. In the figure above, the customer premises equipment (CPE) is managed by the ISP and is deployed behind an aggregation router that is an IPv6 first-hop router and also a DHCPv6 relay agent. IPv6 CPEs are either IPv6 routers (Rtr CPE) or IPv6 bridges (Br CPE). If the customer premises uses a bridge CPE, then a router (Cust Rtr) is needed. All hosts reside behind a router CPE or a customer router. No NS to resolve any address other that that of the default router Singh & Beebee Expires July 21, 2008 [Page 7] Internet-Draft ND On-link Determination January 2008 will reach the aggregation router from any device on the customer side of the aggregator. CPEs do not communicate with each other in this deployment model since a CPE does not run any applications that need to communicate with other CPEs. Hosts do communicate with each other, but every host is off-link to any other host on the aggregation router. 4. Redirect Clarifications Redirects to indicate destinations are on-link are not sent by aggregation routers except when two hosts behind the same bridge CPE, with no router between the host and the aggregation router, communicate with each other. The aggregation router sends a Redirect to a source host which communicates with a destination host behind the same bridge CPE if the router can make a determination that the two hosts lie behind the same bridge CPE. The ICMP field of the Redirect message has a Target Address field. In the presence of a Target Link-Layer Address Option (TLLAO) included in the Redirect, the host should not issue an NS to resolve the destination unless the entry has been garbage collected. In the absence of any TLLAO included in the Redirect, host behavior depends upon the type of the target. If the target is a router, that router's link-local address is the Target Address. The source IP address of a Redirect is always a link-local address. If the target link-local address matches the source IP address, then the L2 header of the Redirect message tells the host the link-layer address of the target. A host may inspect the L2 header to avoid sending an NS to resolve the destination. The purpose of such a Redirect message is to tell a host that a destination which the host assumes to be on-link is in fact off-link. If the target address does not match the source IP address, then the Redirect target is another router than the router that issued the Redirect. In this case, the host will issue an NS to resolve the link-local address of the target if the host does not already have this address in its neighbor cache. This Redirect indicates that the destination is off-link, but the host needs to use a different router than the one issuing the Redirect in order to reach the destination. In summary, if the target of a Redirect is a router, then the destination is off-link and the host MUST NOT issue an NS to resolve a destination other than a link-local address. If the target is a host, the target address is the same value as the ICMP Destination address. On receiving this Redirect, the source host will issue an NS to resolve a non-link-local destination if the host does not already have this information in its neighbor cache. Singh & Beebee Expires July 21, 2008 [Page 8] Internet-Draft ND On-link Determination January 2008 Once the destination host responds to the NS, the source host will thereafter send packets directly to the destination host. 5. Security Considerations The Host Models section of this document describes valid host behavior in response to a security threat where a rogue node can send RAs with a Valid Lifetime of zero. Host Models also describes a problem with section 5.4 of RFC 4862 [ADDRCONF] that can allow two hosts with the same address to avoid DAD and come online on the same link. 6. IANA Considerations None. 7. Acknowledgements Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh Krishnan, Josh Littlefield, Madhu Sudan, Jinmei Tatuya, Bernie Volz, and Vlad Yasevich for their consistent input, ideas and review during the production of this document. 8. References 8.1. Normative References [PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. 8.2. Informative References [ADDRCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [I.D.nd-implementation-problems] Singh, H. and W. Beebee, "Known ND Implementation Problems", draft-wbeebee-nd-implementation-problems-00 (Work In Progress), September 2007. [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, Singh & Beebee Expires July 21, 2008 [Page 9] Internet-Draft ND On-link Determination January 2008 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007. [RFC.ietf-v6ops-onlinkassumptions] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007. [SEND] Nikander, Ed., P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Appendix A. CHANGE HISTORY [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] Changes in draft-wbeebee-on-and-off-link-determination-01.txt since -00.txt are: o Made global changes in document to replace RFC 2461 and RFC 2462 with RFC 4861 and RFC 4862 respectively. Removed text related to 2461bis-11 and 2462bis-08. o Inserted new bullet item to section 2 that explains off-link and on-link default behavior. o On-link behavior has been replaced with on-link determination. o At the end of sections 2.1 and 2.2.1, the last paragraph related to Redirects has been reworded to place more details in the Redirect section. o Section 2.2 has all text removed and then new text has been added. o The Redirect Clarifications section has been rewritten to explain an extra case when the Redirect does not include the Target Link- Layer Address Option. This section has been revised to restrict the scope of the Redirects sent from aggregation routers mentioned to those with on-link destinations. o Jinmei Tatuya has been added to the list of people in the Acknowledged section for his valuable feedback on the -00 draft. o Two bis draft references in the References section have been removed. Singh & Beebee Expires July 21, 2008 [Page 10] Internet-Draft ND On-link Determination January 2008 Authors' Addresses Hemant Singh Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 1622 Email: shemant@cisco.com URI: http://www.cisco.com/ Wes Beebee Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 2030 Email: wbeebee@cisco.com URI: http://www.cisco.com/ Singh & Beebee Expires July 21, 2008 [Page 11] Internet-Draft ND On-link Determination January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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 in BCP 78 and BCP 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 at http://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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Singh & Beebee Expires July 21, 2008 [Page 12]