One document matched: draft-wbeebee-nd-implementation-problems-00.txt
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
<rtr-prompt>show monitor event-trace ipv6 nd all | i FE80::211:E6FF:FEF4:3A5
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Entry FE80::211:E6FF:FEF4:3A5 <router interface> State DELETE -> INCMP
Tx NS to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NA from FE80::211:E6FF:FEF4:3A5 to FE80::211:E6FF:FEF4:3A5 on
Entry FE80::211:E6FF:FEF4:3A5 <router interface> 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 <router interface> State REACH -> STALE
<rtr-prompt>
<rtr-prompt>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 <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Entry 2001:420:3800:809:594C:3B39:A263:3BB5 <router interface> State DELETE
Tx NS to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Entry 2001:420:3800:809:594C:3B39:A263:3BB5 <router interface> State INCMP
Entry 2001:420:3800:809:594C:3B39:A263:3BB5 <router interface> State REACH
<rtr-prompt>
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.
<prompt><interface configuration command>
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
<prompt><print routing table command>
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
<prompt>
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 <router interface>
ICMPv6: Sending REDIRECT for 2001:420:3800:809:65E8:C4A9:8828:F5BC,
target 2001:420:3800:809:65E8:C4A9:8828:F5BC on <router interface>
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:30:00 |