One document matched: draft-wbeebee-nd-implementation-pitfalls-02.txt
Differences from draft-wbeebee-nd-implementation-pitfalls-01.txt
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
<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.
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.
<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 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 <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.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:38:09 |