One document matched: draft-wbeebee-nd-updates-00.txt
Network Working Group H. Singh
Internet-Draft W. Beebee
Intended status: Standards Track Cisco Systems, Inc.
Expires: March 4, 2008 September 2007
Data Forwarding and Address Resolution Updates to 2461bis and 2462bis
draft-wbeebee-nd-updates-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.
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. The set of
new requirements beyond what has been specified in RFC 2461 [ND] and
RFC 2462 [ADDRCONF] is restricted to clarifications deemed necessary
to facilitate correct implementation. The intention of this document
is to incorporate normative changes into
Singh & Beebee Expires March 4, 2008 [Page 1]
Internet-Draft ND Updates September 2007
draft-ietf-ipv6-rfc2461bis-11 [NDbis] and
draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] when new work on these
documents can be accepted.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changes to draft-ietf-ipv6-rfc2461bis-11 . . . . . . . . . . . 3
3. Changes to draft-ietf-ipv6-rfc2462bis-08 . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Singh & Beebee Expires March 4, 2008 [Page 2]
Internet-Draft ND Updates September 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
draft-wbeebee-nd-implementation-problems-00
[I.D.nd-implementation-problems], follows: a host receives an RA with
no prefix advertised and incorrectly decides to perform address
resolution when the host should have sent all traffic to the default
router. The router does not respond to the address resolution and
the layer 2 driver of the host stops transmitting IPv6 packets.
Proposed changes to draft-ietf-ipv6-rfc2461bis-11 [NDbis] and
draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] are presented.
2. 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:
Singh & Beebee Expires March 4, 2008 [Page 3]
Internet-Draft ND Updates September 2007
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.
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 Prefix Information
Option (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:
Singh & Beebee Expires March 4, 2008 [Page 4]
Internet-Draft ND Updates September 2007
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.
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
Singh & Beebee Expires March 4, 2008 [Page 5]
Internet-Draft ND Updates September 2007
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
[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
Singh & Beebee Expires March 4, 2008 [Page 6]
Internet-Draft ND Updates September 2007
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
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.
Singh & Beebee Expires March 4, 2008 [Page 7]
Internet-Draft ND Updates September 2007
3. 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
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.
Singh & Beebee Expires March 4, 2008 [Page 8]
Internet-Draft ND Updates September 2007
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."
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.
4. Security Considerations
The "Changes to draft-ietf-ipv6-rfc2461bis-11" 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.
The "Changes to draft-ietf-ipv6-rfc2462bis-08" section 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.
5. IANA Considerations
None.
6. Acknowledgements
Thanks to Madhu Sudan for his consistent input, ideas and review
during the production of this document.
7. References
Singh & Beebee Expires March 4, 2008 [Page 9]
Internet-Draft ND Updates September 2007
7.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.
7.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.
[I.D.nd-implementation-problems]
Singh, H. and W. Beebee, "Known ND Implementation Problems
(IPv6)", draft-wbeebee-nd-implementation-problems-00 (Work
In Progress), September 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",
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 10]
Internet-Draft ND Updates 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 11]
Internet-Draft ND Updates 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 12]
| PAFTECH AB 2003-2026 | 2026-04-23 19:36:27 |