One document matched: draft-wbeebee-on-link-and-off-link-determination-01.txt
Differences from draft-wbeebee-on-link-and-off-link-determination-00.txt
Network Working Group H. Singh
Internet-Draft W. Beebee
Intended status: Standards Track Cisco Systems, Inc.
Expires: July 21, 2008 January 18, 2008
ND On-link and Off-link Determination
draft-wbeebee-on-link-and-off-link-determination-01
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 July 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
RFC 4861 [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 4861 [ND]. In particular, hosts
incorrectly implement on- vs. off-link data forwarding. This
document clarifies host behavior and associated router behavior to
define explicitly on-link and off-link determination.
Singh & Beebee Expires July 21, 2008 [Page 1]
Internet-Draft ND On-link Determination January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Host Models . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RA Sets the M bit but does not Include the PIO . . . . . . 5
2.2. RA Advertises a Prefix with the On-link(L) Bit Set . . . . 5
2.2.1. When the Valid Lifetime Expires . . . . . . . . . . . 6
2.3. RA Advertises a Prefix with the On-link(L) Bit Clear . . . 6
3. Router Models . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Aggregation Router Deployment Model . . . . . . . . . . . 7
4. Redirect Clarifications . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Singh & Beebee Expires July 21, 2008 [Page 2]
Internet-Draft ND On-link Determination January 2008
1. Introduction
IPv6 host data forwarding and address resolution is complex. For
example, RFC 4861 [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 4861 [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 4861 [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.
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.
2. Host Models
A correctly implemented IPv6 host MUST adhere to the following rules:
1. On-link determination SHOULD NOT persist across IPv6 interface
initializations. Note that section 5.7 of RFC 4862 [ADDRCONF]
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 RFC 4861 [ND] 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
Singh & Beebee Expires July 21, 2008 [Page 3]
Internet-Draft ND On-link Determination January 2008
document. Note that the on-link definition as specified by RFC
4861 [ND] 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
RFC 4861 [ND].
4. RFC 4861 [ND] assumes that all prefixes are initially off-link
(the host sends data to the default router). RFC 4861 [ND] has
no way to indicate that a prefix is off-link. Only when the
Prefix Information Option (PIO) of an RA has a set L-bit and a
non-zero Valid Lifetime does the on-link status of a prefix
change, and it changes to on-link. A prefix with the L-bit
cleared does not change the on-link status of prefix and is
functionally equivalent to omitting the prefix from the RA.
5. 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
addresses of the prefix to be off-link, as suggested by the PIO
paragraph of section 6.3.4 of RFC 4861 [ND].
6. Newer implementations, which are compliant with RFC 4861 [ND]
MUST adhere to the following rules. Older implementations, which
are compliant with RFC 2461 [ND] but not RFC 4861 [ND] 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 cannot
be performed. This case is analogous to the behavior
specified in the last paragraph of section 7.2.2 of RFC 4861
[ND]: when address resolution fails, the host SHOULD send an
ICMPv6 Destination Unreachable message. The specified
behavior MAY be extended to cover this case where address
resolution cannot be performed.
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. RFC4943
Singh & Beebee Expires July 21, 2008 [Page 4]
Internet-Draft ND On-link Determination January 2008
[RFC.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 PIO
Section 3.1 of RFC 4861 [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."
For example, an IPv6 router can send an RA with no PIO, the M bit
set, does not send any Redirects, and does not send any NA or ND
messages for non-link local addresses. On receipt of the RA, the
host in this example chooses to use DHCPv6 to acquire its IPv6
address. After completing IPv6 address acquisition, the host MUST
obey RFC 4861 [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 determination of the
destination addresses of the original packets for which the Redirects
were sent change from what is specified in the rules above. For
changes to the on-link determination in the presence of Redirects,
see the Redirect Clarifications section.
2.2. RA Advertises a Prefix with the On-link(L) Bit Set
Section 6.3.4 of RFC 4861 [ND] mentions that hosts may ignore the
valid lifetime for stateless address autoconfiguration. However,
this does not apply to on-link determination:
Singh & Beebee Expires July 21, 2008 [Page 5]
Internet-Draft ND On-link Determination January 2008
"Stateless address autoconfiguration [ADDRCONF] may in some
circumstances use a larger 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."
Therefore, when a prefix has been advertised as on-link and the
prefix lifetime value has not expired, in the absence of Redirects,
any destination included in the prefix will be considered to be on-
link, and hosts will issue an NS to resolve the on-link destination.
In the presence of Redirects, only the on-link determination of the
destination addresses of the original packets for which the Redirects
were sent change from what is specified. For changes to the on-link
determination in the presence of Redirects, see the Redirect
Clarifications section.
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.
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 RFC 4861 [ND]":
"...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 July 21, 2008 [Page 6]
Internet-Draft ND On-link Determination January 2008
3. Router Models
The Redirect Clarifications section clarifies RFC 4861 [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 share the same
prefix. Physical connectivity between the aggregation router and the
modems prevents hosts behind modems to communicate directly with each
other. Hosts send their traffic to aggregation router. 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
Singh & Beebee Expires July 21, 2008 [Page 7]
Internet-Draft ND On-link Determination January 2008
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
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 to indicate destinations are on-link 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.
The ICMP field of the Redirect message has a Target Address field.
In the presence of a Target Link-Layer Address Option (TLLAO)
included in the Redirect, the host should not issue an NS to resolve
the destination unless the entry has been garbage collected. In the
absence of any TLLAO included in the Redirect, host behavior depends
upon the type of the target.
If the target is a router, that router's link-local address is the
Target Address. The source IP address of a Redirect is always a
link-local address. If the target link-local address matches the
source IP address, then the L2 header of the Redirect message tells
the host the link-layer address of the target. A host may inspect
the L2 header to avoid sending an NS to resolve the destination. The
purpose of such a Redirect message is to tell a host that a
destination which the host assumes to be on-link is in fact off-link.
If the target address does not match the source IP address, then the
Redirect target is another router than the router that issued the
Redirect. In this case, the host will issue an NS to resolve the
link-local address of the target if the host does not already have
this address in its neighbor cache. This Redirect indicates that the
destination is off-link, but the host needs to use a different router
than the one issuing the Redirect in order to reach the destination.
In summary, if the target of a Redirect is a router, then the
destination is off-link and the host MUST NOT issue an NS to resolve
a destination other than a link-local address.
If the target is a host, the target address is the same value as the
ICMP Destination address. On receiving this Redirect, the source
host will issue an NS to resolve a non-link-local destination if the
host does not already have this information in its neighbor cache.
Singh & Beebee Expires July 21, 2008 [Page 8]
Internet-Draft ND On-link Determination January 2008
Once the destination host responds to the NS, the source host will
thereafter send packets directly to the destination host.
5. 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 4862 [ADDRCONF] that can allow two
hosts with the same address to avoid DAD and come online on the same
link.
6. IANA Considerations
None.
7. Acknowledgements
Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph
Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh
Krishnan, Josh Littlefield, Madhu Sudan, Jinmei Tatuya, Bernie Volz,
and Vlad Yasevich for their consistent input, ideas and review during
the production of this document.
8. References
8.1. Normative References
[PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
8.2. Informative References
[ADDRCONF]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[I.D.nd-implementation-problems]
Singh, H. and W. Beebee, "Known ND Implementation
Problems",
draft-wbeebee-nd-implementation-problems-00 (Work In
Progress), September 2007.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Singh & Beebee Expires July 21, 2008 [Page 9]
Internet-Draft ND On-link Determination January 2008
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
September 2007.
[RFC.ietf-v6ops-onlinkassumptions]
Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
Discovery On-Link Assumption Considered Harmful",
RFC 4943, September 2007.
[SEND] Nikander, Ed., P., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, May 2004.
Appendix A. CHANGE HISTORY
[NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.]
Changes in draft-wbeebee-on-and-off-link-determination-01.txt since
-00.txt are:
o Made global changes in document to replace RFC 2461 and RFC 2462
with RFC 4861 and RFC 4862 respectively. Removed text related to
2461bis-11 and 2462bis-08.
o Inserted new bullet item to section 2 that explains off-link and
on-link default behavior.
o On-link behavior has been replaced with on-link determination.
o At the end of sections 2.1 and 2.2.1, the last paragraph related
to Redirects has been reworded to place more details in the
Redirect section.
o Section 2.2 has all text removed and then new text has been added.
o The Redirect Clarifications section has been rewritten to explain
an extra case when the Redirect does not include the Target Link-
Layer Address Option. This section has been revised to restrict
the scope of the Redirects sent from aggregation routers mentioned
to those with on-link destinations.
o Jinmei Tatuya has been added to the list of people in the
Acknowledged section for his valuable feedback on the -00 draft.
o Two bis draft references in the References section have been
removed.
Singh & Beebee Expires July 21, 2008 [Page 10]
Internet-Draft ND On-link Determination January 2008
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 July 21, 2008 [Page 11]
Internet-Draft ND On-link Determination January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 July 21, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 14:51:46 |