Network Working Group H. Singh Internet-Draft W. Beebee Intended status: Informational Cisco Systems, Inc. Expires: March 4, 2008 September 2007 Known ND Implementation Problems draft-wbeebee-nd-implementation-problems-00 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 March 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract RFC 2461 [ND] describes host data forwarding and address resolution. This document collects known ND implementation problems, following the same model as RFC 2525 [TCPProb]. Singh & Beebee Expires March 4, 2008 [Page 1] Internet-Draft Known ND Implementation Problems September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Known IPv6 ND Implementation Problems . . . . . . . . . . . . 3 2.1. Incorrect host data forwarding behavior after receiving an RA with no Prefix Information Option (PIO) . 3 2.2. A DHCPv6 host sending excessive NS(DAD)s . . . . . . . . . 7 2.3. Incorrect host behavior after automatic insertion of a directly connected route during address acquisition . . . 9 2.4. Aggregation router sending Redirects when hosts communicate to each other from behind different modems . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Singh & Beebee Expires March 4, 2008 [Page 2] Internet-Draft Known ND Implementation Problems September 2007 1. Introduction This document catalogs a number of known IPv6 ND implementation problems. The goal in doing so is to enhance the quality of current IPv6 ND implementations. 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]. 2. Known IPv6 ND Implementation Problems 2.1. Incorrect host data forwarding behavior after receiving an RA with no Prefix Information Option (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. 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. Singh & Beebee Expires March 4, 2008 [Page 3] Internet-Draft Known ND Implementation Problems September 2007 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), 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) Singh & Beebee Expires March 4, 2008 [Page 4] Internet-Draft Known ND Implementation Problems September 2007 .... ...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 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 Singh & Beebee Expires March 4, 2008 [Page 5] Internet-Draft Known ND Implementation Problems September 2007 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 Followed by multiple NS's like frame 22, but no ICMPv6 echo from the IPv6 host. Figure 2. Singh & Beebee Expires March 4, 2008 [Page 6] Internet-Draft Known ND Implementation Problems September 2007 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. 2.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 standards for aggregator networks should define the number of DADs to be sent by hosts serviced by the aggregation router. Singh & Beebee Expires March 4, 2008 [Page 7] Internet-Draft Known ND Implementation Problems September 2007 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 March 4, 2008 [Page 8] Internet-Draft Known ND Implementation Problems September 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. 2.3. Incorrect host behavior after automatic insertion of a directly connected route during address acquisition Singh & Beebee Expires March 4, 2008 [Page 9] Internet-Draft Known ND Implementation Problems September 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 March 4, 2008 [Page 10] Internet-Draft Known ND Implementation Problems September 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 March 4, 2008 [Page 11] Internet-Draft Known ND Implementation Problems September 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. 2.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 March 4, 2008 [Page 12] Internet-Draft Known ND Implementation Problems September 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. 3. Security Considerations None. 4. IANA Considerations None. Singh & Beebee Expires March 4, 2008 [Page 13] Internet-Draft Known ND Implementation Problems September 2007 5. Acknowledgements Thanks (in alphabetical order) to Jari Arkko, Ralph Droms, Suresh Krishnan, Madhu Sudan, and Bernie Volz for their consistent input, ideas and review during the production of this document. 6. References 6.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. 6.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. [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", 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. Singh & Beebee Expires March 4, 2008 [Page 14] Internet-Draft Known ND Implementation Problems September 2007 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 March 4, 2008 [Page 15] Internet-Draft Known ND Implementation Problems September 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 March 4, 2008 [Page 16]