Network Working Group H. Singh Internet-Draft W. Beebee Intended status: Standards Track Cisco Systems, Inc. Expires: January 21, 2008 July 20, 2007 Data Forwarding and ND Resolution Implementation Pitfalls draft-wbeebee-nd-implementation-pitfalls-02 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 January 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract RFC 2461 [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 2461 [ND]. In particular, hosts incorrectly implement on- vs. off-link data forwarding. This document clarifies host behavior and associated router behavior to define explicitly address resolution and data forwarding models. The set of new requirements beyond what has been specified in RFC 2461 [ND] and RFC 2462 [ADDRCONF] is restricted to clarifications deemed Singh & Beebee Expires January 21, 2008 [Page 1] Internet-Draft ND Implementation Pitfalls July 2007 necessary to facilitate correct implementation. The intention of this document is to incorporate normative changes into draft-ietf-ipv6-rfc2461bis-11 [NDbis] and draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]. After this has been accomplished, this document will be on track to become an Informational RFC. Following the same model as RFC 2525 [TCPProb], a section of this document collects known IPv6 ND implementation problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Host Models . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RA Sets the M bit but does not Include the Prefix Information Option (PIO) . . . . . . . . . . . . . . . . . 6 2.2. RA Advertises a Prefix with the On-link(L) Bit Set . . . . 7 2.2.1. When the Valid Lifetime Expires . . . . . . . . . . . 8 2.3. RA Advertises a Prefix with the On-link(L) Bit Clear . . . 8 3. Router Models . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Aggregation Router Deployment Model . . . . . . . . . . . 9 4. Redirect Clarifications . . . . . . . . . . . . . . . . . . . 10 5. Changes to draft-ietf-ipv6-rfc2461bis-11 . . . . . . . . . . . 10 6. Changes to draft-ietf-ipv6-rfc2462bis-08 . . . . . . . . . . . 14 7. Known IPv6 ND Implementation Problems . . . . . . . . . . . . 16 7.1. Incorrect host data forwarding behavior after receiving an RA with no PIO . . . . . . . . . . . . . . . 16 7.2. A DHCPv6 host sending excessive NS(DAD)s . . . . . . . . . 20 7.3. Incorrect host behavior after automatic insertion of a directly connected route during address acquisition . . . 22 7.4. Aggregation router sending Redirects when hosts communicate to each other from behind different modems . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Singh & Beebee Expires January 21, 2008 [Page 2] Internet-Draft ND Implementation Pitfalls July 2007 1. Introduction IPv6 host data forwarding and address resolution is complex. For example, RFC 2461 [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 2461 [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 2461 [ND] need to be made explicit. Failure of host implementations to comply can result in lack of IPv6 connectivity. One example, included in the Known IPv6 ND Implementation Problems section of this document, 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. Fourth, proposed changes to draft-ietf-ipv6-rfc2461bis-11 [NDbis] and draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] are presented. Finally, known IPv6 ND implementation problems are described which motivate the Host and Router Models rules. Where behavior has not changed between RFC 2461 [ND] and draft-ietf-ipv6-2461bis-11 [NDbis] and behavior has not changed between RFC 2462 [ADDRCONF] and draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis], this document only refers to RFC 2461 [ND] and RFC 2462 [ADDRCONF] respectively. Where behavior has changed, this document refers to both the original and the new version. 2. Host Models A correctly implemented IPv6 host MUST adhere to the following rules: Singh & Beebee Expires January 21, 2008 [Page 3] Internet-Draft ND Implementation Pitfalls July 2007 1. On-link determination and addresses acquired using DHCPv6 SHOULD NOT persist across IPv6 interface initializations. Note that section 5.7 of draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] 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 draft-ietf-ipv6-2461bis-11 [NDbis] 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 document. Note that the on-link definition as specified by draft-ietf-ipv6-2461bis-11 [NDbis] 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 draft-ietf-ipv6-2461bis-11 [NDbis]. 4. 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 the prefix to be off-link, as suggested by the PIO paragraph of section 6.3.4 of draft-ietf-ipv6-2461bis-11 [NDbis]. However, if the RA advertises a prefix with the on-link bit set, the host MAY ignore the on-link indication from the RA and treat the prefix as off-link. Subsections which follow describe this behavior in further detail. 5. Newer host implementations MUST issue NS(DAD)s for all of its acquired unicast addresses except when the host interface has DupAddrDetectTransmits variable set to zero. Section 5.4 of RFC 2462 [ADDRCONF] erroneously relaxes this requirement and suffers from a manual configuration problem as illustrated by the following example: Host1 uses EUI-64 to configure a Link Local Address (LLA) using MAC1 and manually configures a Global Unicast Address (GUA) that is equal to an address configured using EUI-64 and MAC2. Host1 completes an NS(DAD) for both its LLA and GUA in compliance with RFC 2462 [ADDRCONF]. Then, Host2 uses EUI-64 to configure both a LLA and a GUA using MAC2. Host2 completes an NS(DAD) for the LLA and does not send an NS(DAD) for its GUA in compliance with RFC 2462 [ADDRCONF]. Now Host1 and Singh & Beebee Expires January 21, 2008 [Page 4] Internet-Draft ND Implementation Pitfalls July 2007 Host2 have the same GUA on the same link. Therefore, this exception in section 5.4 of RFC 2462 [ADDRCONF] SHOULD be ignored. Note that draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] refers to an extensibility concern with new implementations and states in section 5.4: "Whereas this document does not invalidate such implementations, this kind of 'optimization' is NOT RECOMMENDED, and new implementations MUST NOT do that optimization." The "Changes to draft-ietf-ipv6-rfc2462bis-08" section in this document describes the corresponding changes to draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]. 6. The host SHOULD issue only a single NS(DAD) for each address. The default value for DupAddrDetectTransmits variable is specified as one in section 5.1 of RFC 2462 [ADDRCONF]. Note, however, that link-specific documents can modify this default. For instance, PPP specifies DupAddrDetectTransmits to be zero in RFC 2472 [PPPv6]. 7. Newer implementations, which are compliant with draft-ietf-ipv6-rfc2461bis-11 [NDbis] MUST adhere to the following rules. Older implementations, which are compliant with RFC 2461 [ND] but not draft-ietf-ipv6-rfc2461bis-11 [NDbis] 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 has failed. As specified in the last paragraph of section 7.2.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis], when address resolution fails, the host SHOULD send an ICMPv6 Destination Unreachable message. 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. draft-ietf-v6ops-onlinkassumption-04 Singh & Beebee Expires January 21, 2008 [Page 5] Internet-Draft ND Implementation Pitfalls July 2007 [I.D.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 Prefix Information Option (PIO) Section 3.1 of RFC 2461 [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." An IPv6 router sends an RA with no prefix advertised and the M bit set, does not send any Redirects, nor any NA or ND messages for non- link local addresses. On receipt of the RA, the host uses DHCPv6 to acquire an IPv6 address. After completing IPv6 address acquisition, the host MUST obey RFC 2461 [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 behavior of the destination addresses of the original packets for which the Redirects were sent change from what is specified in the rules above. These destination addresses are considered to be on-link and the host MAY now send non-link-local traffic destined to the destination addresses directly without sending it first to the default router. Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve a destination other than a link-local address. Singh & Beebee Expires January 21, 2008 [Page 6] Internet-Draft ND Implementation Pitfalls July 2007 2.2. RA Advertises a Prefix with the On-link(L) Bit Set Security consequences of RFC 2461 [ND] imply that hosts MAY send all traffic to the default router without performing address resolution first even when a PIO has been received advertising an on-link prefix, regardless of whether the host performs DHCPv6 and/or stateless autoconfiguration. Section 4.6.2 of RFC 2461 [ND] defines the Valid Lifetime in the PIO as: "The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination." Section 11 of RFC 2461 [ND] mentions the following denial of service attack: "An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send 'forged' Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes." The same security risk is also described in section 5.5.3 of RFC 2462 [ADDRCONF]. This section allows hosts to ignore the Valid Lifetime stored in an RA in order to prevent denial of service attacks. Section 6.3.4 of RFC 2461 [ND] mentions that hosts MAY send all traffic to the default router without performing address resolution first: "Stateless address autoconfiguration RFC 2462 [ADDRCONF] may in some circumstances increase the 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." Consider the following scenario with one rogue node and two other hosts on the same link. The rogue sends a malicious RA with an on- link prefix with a Valid Lifetime of zero. Host1 correctly implements section 5.5.3 of RFC 2462 [ADDRCONF] and resets its StoredLifetime (or RemainingLifetime in draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]) to two hours and avoids the denial of service attack. Singh & Beebee Expires January 21, 2008 [Page 7] Internet-Draft ND Implementation Pitfalls July 2007 Host1 tries to send traffic to Host2, but cannot trust its own two hour StoredLifetime. For instance, a legitimate operator may have tried to time out the prefix due to an impending renumbering. Host1 decides to send all of its traffic to the on-link authority, the default router, even though the destination prefix is on-link. IF the host decides to send all traffic (including on-link traffic) to the default router, then the host MUST follow the following rule: 1. The host MUST NOT issue an NS to resolve a destination other than a link-local address. 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. In the presence of Redirects, only the on-link behavior of the destination addresses of the original packets for which the Redirects were sent change from what is specified in the rules above. These destination addresses are considered to be on-link and the host MAY now send non-link-local traffic destined to the destination addresses directly without sending it first to the default router. Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve a destination other than a link-local address. 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 draft-ietf-ipv6-rfc2461bis-11 [NDbis]": "...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 January 21, 2008 [Page 8] Internet-Draft ND Implementation Pitfalls July 2007 3. Router Models The Redirect Clarifications section clarifies RFC 2461 [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 are on the same link. 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 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 Singh & Beebee Expires January 21, 2008 [Page 9] Internet-Draft ND Implementation Pitfalls July 2007 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 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. Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve the destination contained within the Redirect. 5. Changes to draft-ietf-ipv6-rfc2461bis-11 Proposed changes to draft-ietf-ipv6-rfc2461bis-11 [NDbis] follow: o The following paragraph from section 3.1 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] describes intended behavior when a host receives an RA without an advertised prefix and needs to add a reference to section 6.3.4 where the case is described in more detail: "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." to add the following sentence at the end of the paragraph: See Section 6.3.4 of this document for more details when no prefix is advertised in the Router Advertisement. o Section 2.1 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should include the following sentence in the on-link definition: Manual configuration of a host introduces its own set of security considerations and is beyond the scope of this on-link definition. Singh & Beebee Expires January 21, 2008 [Page 10] Internet-Draft ND Implementation Pitfalls July 2007 o Section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should include the following paragraph (after the first paragraph): The on-link definition in section 2.1 describes the only means for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for on-link determination. o Section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should include the following paragraph (before the PIO on-link paragraph): Without advertised prefixes, manual configuration, Redirects, or on-link information from Neighbor Advertisements or other Neighbor Discovery Messages, hosts MUST NOT assume a default prefix length, MUST send all non-link-local traffic to the default router, and MUST NOT issue an NS to resolve any destination other than a link-local address. Additional on- link information can only indicate that certain specific prefixes or addresses are on-link, and does not change this off-link default. o At the end of the PIO on-link paragraph of section 6.3.4, the following text should be added: If the RA advertises a prefix with the on-link bit set, the host MAY ignore the on-link indication from the RA and treat the prefix as off-link. If the host decides to send all traffic (including on-link traffic) to the default router, then the host MUST NOT issue an NS to resolve a destination other than a link-local address. 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. In the presence of Redirects, only the on-link behavior of the destination addresses of the original packets for which the Redirects were sent change from what is specified in the rules above. These destination addresses are considered to be on- Singh & Beebee Expires January 21, 2008 [Page 11] Internet-Draft ND Implementation Pitfalls July 2007 link and the host MAY now send non-link-local traffic destined to the destination addresses directly without sending it first to the default router. Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve a destination other than a link-local address. o Section 6.3.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should include the following variable at the end of section. We have brought this variable from section 5.1 in draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] to draft-ietf-ipv6-rfc2461bis-11 [NDbis] so that implementers are aware that the default value of this variable is 1. DupAddrDetectTransmits The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. The default value of this variable is 1. o Section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should include the following paragraph (after the paragraph that begins with "For each Prefix Information option with the on-link flag set, a host does the following:"): 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. This behavior can lead to incorrectly adding a prefix to the Prefix List and incorrect on-link determination by the host. o Section 5.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should add the following paragraph (after the second paragraph): Newer implementations, which are compliant with draft-ietf-ipv6-rfc2461bis-11 [NDbis] MUST adhere to the following rules. Older implementations, which are compliant with RFC 2461 [ND] but not draft-ietf-ipv6-rfc2461bis-11 [NDbis] 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 Singh & Beebee Expires January 21, 2008 [Page 12] Internet-Draft ND Implementation Pitfalls July 2007 (since the Default Router List is empty), address resolution has failed. As specified in the last paragraph of section 7.2.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis], when address resolution fails, the host SHOULD send an ICMPv6 Destination Unreachable message. 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. draft-ietf-v6ops-onlinkassumption-04 [I.D.ietf-v6ops-onlinkassumptions] provides justification for these rules. o Section 4.5 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should have the following text added (in the first paragraph after the sentence "Routers send Redirect packets to inform...": Since the Redirect contains all the information necessary to resolve the address of the destination host, the source host MUST NOT issue an NS to resolve the destination contained within the Redirect. o A new section titled On-link and Off-link Decision Rules needs to be added to draft-ietf-ipv6-rfc2461bis-11 [NDbis] as an Appendix or as a section below section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis]. This section clarifies both on-link and off-link determination through providing a complete set of rules that decides in all cases whether an address is on or off-link. 1. 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 the prefix to be off-link. However, if the RA advertises a prefix with the on-link bit set, the host MAY ignore the on-link indication from the RA and treat the prefix as off-link. 2. If an IPv6 router sends an RA with no prefix advertised and the M bit set and does not send any Redirects, the host assumes destinations with non-link-local traffic are off- link. 3. On-link determination and addresses acquired using DHCPv6 SHOULD NOT persist across IPv6 interface initializations. Note that stable storage can be used for addresses acquired Singh & Beebee Expires January 21, 2008 [Page 13] Internet-Draft ND Implementation Pitfalls July 2007 with stateless address autoconfiguration. However, the Preferred and Valid Lifetimes must be retained if this approach is used. 4. A prefix is on-link if it is covered by one of the link's prefixes, specified as the target of a Redirect message, or a Neighbor Advertisement or any Neighbor Discovery message is received for the address. No other information can be used for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for off-link determination. Manual configuration of a host introduces its own complications for on-link determination and is beyond the scope of this section. 5. 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. 1. The host MUST NOT perform address resolution for non-link-local addresses. 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 has failed. When address resolution fails, the host SHOULD send an ICMPv6 Destination Unreachable message. 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. 6. Changes to draft-ietf-ipv6-rfc2462bis-08 Proposed changes to draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] follow: o The following paragraph from section 5.4 of draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] needs to change: "Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local Singh & Beebee Expires January 21, 2008 [Page 14] Internet-Draft ND Implementation Pitfalls July 2007 address and skip the test for the global address using the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of 'optimization' is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. This optimization came from the assumption that all of an interface's addresses are generated from the same identifier. However, the assumption does actually not stand; new types of addresses have been introduced where the interface identifiers are not necessarily the same for all unicast addresses on a single interface [RFC3041] [RFC3972]. Requiring to perform Duplicate Address Detection for all unicast addresses will make the algorithm robust for the current and future such special interface identifiers." to read as follows: Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address using the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of 'optimization' is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. This optimization came from the assumption that all of an interface's addresses are generated from the same identifier. However, even with this assumption, skipping DAD for non-link- local addresses with manual configuration creates an additional problem. This optimization allows an interface to claim a duplicate address in a way that would not be detected. Further, new types of addresses have been introduced where the interface identifiers are not necessarily the same for all unicast addresses on a single interface [RFC3041] [RFC3972]. Requiring an interface to perform DAD for all unicast addresses will make the algorithm more robust. o Section 5.5.3 of draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] has the following paragraph: "Note that a future revision of the address architecture and a future link-type specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents. Thus, an implementation should not assume a particular constant. Rather, it should expect any lengths of interface identifiers." Singh & Beebee Expires January 21, 2008 [Page 15] Internet-Draft ND Implementation Pitfalls July 2007 The "should not" should be replaced with "SHOULD NOT" and also the "should" should be replaced with "SHOULD". o Section 5.7 of draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] should have the following sentence added (at the end of the first paragraph): On-link determination and addresses acquired using DHCPv6 SHOULD NOT persist across IPv6 interface initializations. 7. Known IPv6 ND Implementation Problems This section catalogs a number of known IPv6 ND implementation problems. The goal in doing so is to enhance the quality of current IPv6 ND implementations, and motivate the models presented in previous sections of this document. It is hoped that this will provide greater interoperability between IPv6 ND implementations. Each problem description is modelled after the problem description format from section 1 of RFC 2525 [TCPProb]. 7.1. Incorrect host data forwarding behavior after receiving an RA with no PIO Name of problem Incorrect host data forwarding behavior after receiving an RA with no PIO. Classification Potential network connectivity loss. Description An IPv6 host has received an RA with M bit set and no PIO. Since no on-link information was provided, the host has to assume all non-link-local destinations are off-link and send all non-link-local traffic to the default router and allow the router to issue any Redirects if necessary. The host completes DHCPv6 and then, when the host is asked to ping an address, the host issues an NS to resolve the ping destination address instead of forwarding the ping packet to the default router. Singh & Beebee Expires January 21, 2008 [Page 16] Internet-Draft ND Implementation Pitfalls July 2007 Significance An IPv6 default router for this source host and the destination host may not respond to the address resolution NS sent out by the source host when asked to ping a destination, and the source host may lose IPv6 network connectivity as a result. Implications If the router and the destination host do not respond to the NS, the host layer 2 driver will hold the IPv6 packet, resulting in lack of IPv6 connectivity as per section 4.2.5 of RFC 3756 [SEND]. Relevant RFCs draft-ietf-ipv6-2461bis-11 [NDbis] describes correct host behavior for this scenario. RFC 3756 [SEND] describes host behavior during address resolution. Trace file demonstrating it A packet capture showing RA with no PIO and NS from host. No. Time Source Destination 19 11.614198 fe80::203:adff:fe47:f1c6 ff02::1 Protocol Info ICMPv6 Router advertisement Frame 19 (86 bytes on wire, 86 bytes captured) Arrival Time: May 11, 2007 12:09:03.400545000 [Time delta from previous captured frame: 2.000110000 seconds] [Time delta from previous displayed frame: 2.000110000 seconds] [Time since reference or first frame: 11.614198000 seconds] Frame Number: 19 Frame Length: 86 bytes Capture Length: 86 bytes [Frame is marked: True] [Protocols in frame: eth:ipv6:icmpv6] [Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] Ethernet II, Src: EmersonE_47:f1:c6 (00:03:ad:47:f1:c6), Singh & Beebee Expires January 21, 2008 [Page 17] Internet-Draft ND Implementation Pitfalls July 2007 Dst: IPv6-Neighbor-Discovery_00:00:00:01 (33:33:00:00:00:01) Destination: IPv6-Neighbor-Discovery_00:00:00:01 (33:33:00:00:00:01) Address: IPv6-Neighbor-Discovery_00:00:00:01 (33:33:00:00:00:01) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: EmersonE_47:f1:c6 (00:03:ad:47:f1:c6) Address: EmersonE_47:f1:c6 (00:03:ad:47:f1:c6) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IPv6 (0x86dd) Internet Protocol Version 6 0110 .... = Version: 6 .... 1110 0000 .... .... .... .... .... = Traffic class: 0x000000e0 .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 Payload length: 32 Next header: ICMPv6 (0x3a) Hop limit: 255 Source: fe80::203:adff:fe47:f1c6 (fe80::203:adff:fe47:f1c6) Destination: ff02::1 (ff02::1) Internet Control Message Protocol v6 Type: 134 (Router advertisement) Code: 0 Checksum: 0xe956 [correct] Cur hop limit: 64 Flags: 0xc0 1... .... = Managed .1.. .... = Other ..0. .... = Not Home Agent ...0 0... = Router preference: Medium Router lifetime: 1800 Reachable time: 0 Retrans timer: 0 ICMPv6 Option (Source link-layer address) Type: Source link-layer address (1) Length: 8 Link-layer address: 00:03:ad:47:f1:c6 ICMPv6 Option (MTU) Type: MTU (5) Length: 8 MTU: 1500 No. Time Source 22 15.721935 2001:420:3800:809:a98b:2df5:f45b:1cc2 Destination Protocol Info Singh & Beebee Expires January 21, 2008 [Page 18] Internet-Draft ND Implementation Pitfalls July 2007 ff02::1:ff7f:d18d ICMPv6 Neighbor solicitation Frame 22 (86 bytes on wire, 86 bytes captured) Arrival Time: May 11, 2007 12:09:07.508282000 [Time delta from previous captured frame: 0.107631000 seconds] [Time delta from previous displayed frame: 0.107631000 seconds] [Time since reference or first frame: 15.721935000 seconds] Frame Number: 22 Frame Length: 86 bytes Capture Length: 86 bytes [Frame is marked: True] [Protocols in frame: eth:ipv6:icmpv6] [Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] Ethernet II, Src: AmbitMic_b5:aa:3a (00:d0:59:b5:aa:3a), Dst: IPv6-Neighbor-Discovery_ff:7f:d1:8d (33:33:ff:7f:d1:8d) Destination: IPv6-Neighbor-Discovery_ff:7f:d1:8d (33:33:ff:7f:d1:8d) Address: IPv6-Neighbor-Discovery_ff:7f:d1:8d (33:33:ff:7f:d1:8d) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: AmbitMic_b5:aa:3a (00:d0:59:b5:aa:3a) Address: AmbitMic_b5:aa:3a (00:d0:59:b5:aa:3a) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IPv6 (0x86dd) Internet Protocol Version 6 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000 .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 Payload length: 32 Next header: ICMPv6 (0x3a) Hop limit: 255 Source: 2001:420:3800:809:a98b:2df5:f45b:1cc2 (2001:420:3800:809:a98b:2df5:f45b:1cc2) Destination: ff02::1:ff7f:d18d (ff02::1:ff7f:d18d) Internet Control Message Protocol v6 Type: 135 (Neighbor solicitation) Code: 0 Checksum: 0xa900 [correct] Target: 2001:420:3800:809:4cb9:d617:547f:d18d ICMPv6 Option (Source link-layer address) Type: Source link-layer address (1) Length: 8 Link-layer address: 00:d0:59:b5:aa:3a Singh & Beebee Expires January 21, 2008 [Page 19] Internet-Draft ND Implementation Pitfalls July 2007 Followed by multiple NS's like frame 22, but no ICMPv6 echo from the IPv6 host. Figure 2. How to detect On the host, the ping may fail. With a packet capture tool, one can observe the NS sent by the host where the target address in the NS matches the ping destination. The packet capture also demonstrates that no ping packet has been sent from the host. How to fix The host should assume all non-link-local destinations to be off-link, and send non-link-local traffic to the default router. 7.2. A DHCPv6 host sending excessive NS(DAD)s Name of problem A DHCPv6 host sending excessive NS(DAD)s. Classification Congestion control. Description An IPv6 host was asked by the aggregation router to perform DHCPv6 (through setting the M bit in the RA). During the course of Link-local DAD and DHCPv6 DAD, the host sent 4 DADs for its link-local address and five DADs for its DHCPv6 acquired address. In an aggregation router deployment, especially during an aggregation router reload, when more than 100,000 hosts can register with the aggregation router, sending nine DADs can congest the upstreams. In some aggregator deployments where upstream bandwidth is much less than downstream bandwidth, sending nine DADs for every host during host registration would waste upstream bandwidth and decrease the registration rate. This host behavior is compliant with the ND protocol and DAD, however, for an aggregator deployment with limited upstream bandwidth this behavior is not desirable. Also, link-type specific Singh & Beebee Expires January 21, 2008 [Page 20] Internet-Draft ND Implementation Pitfalls July 2007 standards for aggregator networks should define the number of DADs to be sent by hosts serviced by the aggregation router. Significance Performance of an aggregation router suffers when hosts register in a congested aggregator deployment where upstream bandwidth is limited. Implications This behavior decreases the registration rate of all hosts on the aggregator. VoIP could be deployed with such hosts and slower host registration can delay or prevent VoIP call recovery after an unexpected aggregation router reload. Relevant RFCs The default value for DupAddrDetectTransmits variable is specified as one in section 5.1 of RFC 2462 [ADDRCONF]. RFC 2462 [ADDRCONF] also mentions defining a different value of DupAddrDetectTransmits for a specific link-type. Trace file demonstrating it ND message debugging should be enabled on the aggregation router. This debug log shows the nine DAD's from a host during the time the host registers with the aggregation router. Alternatively, a packet capture tool could have been used to capture DAD messages between the host and the aggregation router. Singh & Beebee Expires January 21, 2008 [Page 21] Internet-Draft ND Implementation Pitfalls July 2007 show monitor event-trace ipv6 nd all | i FE80::211:E6FF:FEF4:3A5 Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on Entry FE80::211:E6FF:FEF4:3A5 State DELETE -> INCMP Tx NS to FE80::211:E6FF:FEF4:3A5 on Rx NA from FE80::211:E6FF:FEF4:3A5 to FE80::211:E6FF:FEF4:3A5 on Entry FE80::211:E6FF:FEF4:3A5 State INCMP -> REACH Rx NS from FE80::211:E6FF:FEF4:3A5 to FE80::20F:86FF:FECF:B270 on Rx NA from FE80::211:E6FF:FEF4:3A5 to 2001:420:3800:809:594C:3B39: Entry FE80::211:E6FF:FEF4:3A5 State REACH -> STALE trace ipv6 nd all | i 2001:420:3800:809:594C:3B39:A263:3BB5 Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on Entry 2001:420:3800:809:594C:3B39:A263:3BB5 State DELETE Tx NS to 2001:420:3800:809:594C:3B39:A263:3BB5 on Entry 2001:420:3800:809:594C:3B39:A263:3BB5 State INCMP Entry 2001:420:3800:809:594C:3B39:A263:3BB5 State REACH Figure 3. How to detect Enable ND message debugging on the aggregation router and capture DADs from the host or use a packet capture tool between the aggregation router and the host to capture DAD messages. How to fix A new link-type document for aggregator deployment should define a new value for DupAddrDetectTransmits. Alternatively, the default of one specified in section 5.1 of RFC 2462 [ADDRCONF] should be used. 7.3. Incorrect host behavior after automatic insertion of a directly connected route during address acquisition Singh & Beebee Expires January 21, 2008 [Page 22] Internet-Draft ND Implementation Pitfalls July 2007 Name of problem Incorrect host behavior after automatic insertion of a directly connected route during address acquisition. Classification Reliability. Description The router sends an RA with M bit set, and no PIO. After address acquisition, a host incorrectly adds a directly connected route to the host's forwarding tables using an invented prefix (assuming a default prefix length) that is partially derived from the acquired address. This host behavior does not follow on-link determination rules, and is independent of possible on-link information sent in the RA. This behavior causes the host to add an entry to the Prefix List of the host inappropriately. 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 draft-ietf-ipv6-2461bis-11 [NDbis]. Significance Host may not be able to send IPv6 traffic. Implications After a host inappropriately adds a prefix to the Prefix List, when the host attempts to send a data packet with a destination which matches the Prefix List entry, the host will incorrectly assume the destination is on-link and it will issue an NS to resolve the destination. A router and the destination host may not respond to this NS and the host may not send the data packet. Relevant RFCs This document describes correct host behavior for this scenario. Singh & Beebee Expires January 21, 2008 [Page 23] Internet-Draft ND Implementation Pitfalls July 2007 Host data forwarding table shows problem A CLI that is available on the host to lookup the data routing/forwarding table demonstrates that the host added the route. Client IP Configuration Ethernet adapter Local Area Connection: IPv6 Address. . . . . . . . . . . : 2001:420:3800:809:38d5:bb15:291c:1e4a Link-local IPv6 Address . . . . . : fe80::5cc5:6c11:1f71:5ecd%9 Default Gateway . . . . . . . . . : fe80::203:afff:fed3:52c6%9 IPv6 Route Table ========================================================================= Active Routes: If Metric Network Destination Gateway 9 286 ::/0 fe80::203:afff:fed3:52c6 1 306 ::1/128 On-link 9 286 2001:420:3800:809::/64 On-link <---- Automatically added /64 9 286 2001:420:3800:809:38d5:bb15:291c:1e4a/128 On-link 9 286 fe80::/64 On-link 9 286 fe80::5cc5:6c11:1f71:5ecd/128 On-link 1 306 ff00::/8 On-link 9 286 ff00::/8 On-link ========================================================================= Persistent Routes: None Figure 4. Singh & Beebee Expires January 21, 2008 [Page 24] Internet-Draft ND Implementation Pitfalls July 2007 How to detect Inspect the host's routing/forwarding tables after host address acquistion completes. How to fix The host MUST follow the rules defined in this document. 7.4. Aggregation router sending Redirects when hosts communicate to each other from behind different modems Name of problem Aggregation router sending Redirects when hosts communicate to each other from behind different modems. Classification Reliability. Description Due to scability and security concerns, hosts behind different modems in an aggregation network cannot communicate directly with each other. If this aggregation router issues a Redirect to any pair of hosts behind different modems that are on the same link of this router, the aggregation router falsely indicates to the hosts that they can talk directly to each other. In this aggregation network, a pair of hosts behind different modems on the same link can only communicate with each other by sending their traffic to the aggregation router. Significance The aggregation router is providing incorrect information to the host that the host can communicate directly to another host when the pair of hosts can only communicate with each other via the aggregation router. Implications There are two hosts behind different modems on the same link of an aggregation router. If a ping is issued from one host to the other and the aggregation router sends a Redirect to one of the hosts, the host receiving the Redirect may Singh & Beebee Expires January 21, 2008 [Page 25] Internet-Draft ND Implementation Pitfalls July 2007 attempt direct communication with the other host, and fail. Relevant RFCs This document describes correct host behavior for this scenario. Trace file demonstrating it A packet capture tool can demonstrate that Redirects are being issued by the router. Alternatively, debug commands on the aggregation router can demonstrate that the router is sending Redirects, as shown below. ICMPv6: Sending REDIRECT for 2001:420:3800:809:4EF:E3B1:1569:27B5, target 2001:420:3800:809:4EF:E3B1:1569:27B5 on ICMPv6: Sending REDIRECT for 2001:420:3800:809:65E8:C4A9:8828:F5BC, target 2001:420:3800:809:65E8:C4A9:8828:F5BC on Figure 5. How to detect During the ping, one can use a network capture of Redirects being issued by the router, or debug output on the router. How to fix The aggregation router MUST block sending any Redirects to hosts behind different modems. 8. 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 2462 [ADDRCONF] that can allow two hosts with the same address to avoid DAD and come online on the same link. Singh & Beebee Expires January 21, 2008 [Page 26] Internet-Draft ND Implementation Pitfalls July 2007 9. IANA Considerations None. 10. Acknowledgements Thanks (in alphabetical order) to Adeel Ahmed, Ralph Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Josh Littlefield, Madhu Sudan, Bernie Volz, and Vlad Yasevich for their consistent input, ideas and review during the production of this document. 11. References 11.1. Normative References [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address autoconfiguration (IPv6)", RFC 2462, December 1998. [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. 11.2. Informative References [ADDRCONFbis] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Address autoconfiguration (IPv6)", draft-ietf-ipv6-rfc2462bis-08 (Work In Progress), May 2005. [I.D.ietf-v6ops-onlinkassumptions] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (IPv6)", draft-ietf-v6ops-onlinkassumption-04 (Work In Progress), January 2007. [NDbis] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", draft-ietf-ipv6-2461bis-11 (Work In Progress), March 2007. [SEND] Nikander, Ed., P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", Singh & Beebee Expires January 21, 2008 [Page 27] Internet-Draft ND Implementation Pitfalls July 2007 RFC 3756, May 2004. [TCPProb] Paxon, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known TCP Implementation Problems (IPv6)", RFC 2525, March 1999. Appendix A. CHANGE HISTORY [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] Changes in draft-wbeebee-nd-implementation-pitfalls-01.txt since -00.txt are: o Removed the word "corrections" from the abstract when referring to the proposed changes for the two drafts. o Added to the abstract declaration of intent for this document. o Corrected the introduction to say "the host must send all non- link-local data to the default router" instead of the incorrect "the host must send all data to the router", which is implied by the specification, but not explicitly stated. o Added the proposed changes to 2461bis section and appropriate reference in the introduction. o Changed "the host MUST issue NS(DAD)s" to "newer host implementations MUST issue NS(DAD)s" to match the current state of 2462bis. o Changed "security problem" to "manual configuration problem" to emphasize that manual configuration of a compliant host combined with the NS(DAD) optimization of a compliant host can cause problems. o Changed recommendation that the exception in section of 5.4 MUST be ignored to SHOULD be ignored. o Removed sentence which invalidates existing implementations. o Changed "the host MUST send all traffic to the default router" to "the host MUST send all non-link-local traffic to the default router". o Changed "the host MUST NOT issue an NS to resolve a destination other than the Link-Local address of the default router" to "the host MUST NOT issue an NS to resolve a destination other than a Singh & Beebee Expires January 21, 2008 [Page 28] Internet-Draft ND Implementation Pitfalls July 2007 link-local address". o Removed MUST NOT and MAY language with respect to Redirects used in the aggregation router model, as these are properties of a correct implementation rather than normative requirements. Note that a clause was added that states that a router can send a Redirect "if the router can make a determination that the two hosts lie behind the same bridge CPE". o Changed the 2462bis changes section to reflect that existing implementations are not required to change, but may suffer from the manual configuration problem described in this draft. o Added Josh Littlefield to the Acknowledgements section to recognize his extremely insightful and useful comments on this draft. Changes in draft-wbeebee-nd-implementation-pitfalls-02.txt since -01.txt are: o Added a new sentence to the abstract and changed the third paragraph of the Introduction to include references to the new Known IPv6 ND Implementation Problems section. o Reworded second paragraph of Introduction. o The requirement listed in the first bullet in Host Models section changed from MUST NOT to sHOULD NOT. To clarify this change, some more text related to DHCPv6 and Valid LifeTimes has been added to this bullet. o Bullet 2 of Host Models section includes a stricter definition of on-link. Also new text was added to the bullet relating to manual configuration, which is not mentioned in the on-link definition in the Terminology section of RFC 2461 [ND]. o The new bullet 4 was inserted in the Host Models section, which relates to off-link determination. o The new bullet 6 has added details. o The new bullet 7 was revamped with stricter terminology. o The second paragraph of section 2.1 has stricter terminology. o A new paragraph was added to the end of section 2.1 relating to Redirects and the problem described in this section. Singh & Beebee Expires January 21, 2008 [Page 29] Internet-Draft ND Implementation Pitfalls July 2007 o A new section, 2.2.1, was added to the document to describe rules for off-link determination. o Section 2.3 was changed to fix mistakes in the earlier version of this section. o SHOULD NOT in the second paragraph of Section 3 was changed to lower case to avoid normative language. o SHOULD NOT in the second paragraph of Section 3.1 was changed to lower case to avoid normative language. o In section 4 the word "need" was replaced by "necessary". o Section 5 is now complete. In the previous version of this document, the locations in draft-ietf-ipv6-2461bis-11 [NDbis] where text was to be modified or added were not yet identified. o Section 6 has minor changes. We reduced the number of changes to draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] described in the paragraph. Two new proposed changes have also been added to this section. o Sections 5 and 6 now have improved formatting. o A new section 7 titled "Know IPv6 ND Implementation Problems" was added to the document. This section is modeled after RFC 2525 [TCPProb]. Four known bugs were described in sub-sections of this section. o Added Vlad Yasevich to the Acknowledgements section to recognize his extremely insightful and useful comments on this draft. We also changed the list of names to be alphabetically listed via last names instead of first names. 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/ Singh & Beebee Expires January 21, 2008 [Page 30] Internet-Draft ND Implementation Pitfalls July 2007 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 January 21, 2008 [Page 31] Internet-Draft ND Implementation Pitfalls July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 January 21, 2008 [Page 32]