Jinmei,
Did you get a chance to review our responses to your comments? We need
closure from you on our responses so that we can see when to publish a
newer revision of this draft. Please see attached .txt file where we
have incorporated responses to your comments in a new version - this
version is not posted to IETF yet. It's sent out only to help you read a
completed version that has incorporated responses to your comments.
Anyone else is welcome to review our drafts. We'll wait for a week or
two if anyone else has any comments on our two drafts before we publish
any newer version.
http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d
etermination-00.txt
http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d
etermination-00.txt
Thanks.
Hemant
-----Original Message-----
From: Hemant Singh (shemant)
Sent: Tuesday, October 30, 2007 5:03 PM
To: [EMAIL PROTECTED]; Wes Beebee (wbeebee)
Cc: [email protected]
Subject: RE: comments on
draft-wbeebee-on-link-and-off-link-determination-00
Hi Jinmei,
Thanks very much for the review of this draft. Please see in line below
for our responses that are preceded by "<hs>" and ended by "</hs>".
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 1:45 AM
To: Hemant Singh (shemant); Wes Beebee (wbeebee)
Cc: [email protected]
Subject: comments on draft-wbeebee-on-link-and-off-link-determination-00
I've read the draft. Here are my comments on it.
- General
According to the title and introduction, this draft apparently focuses
on issues about on/off-link determination, but there also seem to be
other topics, such as address configuration issues or issues about DAD.
If the intent is to cover these broader topics, I think the title,
abstract, introduction (and perhaps some other part) should be changed
accordingly.
<hs> We'll keep the title, abstract, introduction etc. as is and move
bullets 5 and 6 from section 2 of this draft to the nd-updates draft.
</hs>
- Section 1
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.
2461bis and 2462bis have been published as RFCs. The references should
be updated.
<hs> Will do. We had written these drafts when 2461bis and 2462bis were
not RFCs yet.
</hs>
- Section 2, bullet 1
1. On-link determination and addresses acquired using DHCPv6 SHOULD
NOT persist across IPv6 interface initializations.
I'm not sure if I understand what this means. Does this mean, for
example, a node should not keep using addresses configured via DHCPv6
after the node reboots (even if it records the lifetimes in a volatile
storage and they do not expire)?
<hs> Yes. We have assumed if a node reboots, a node has to perform a new
DHCPv6 address acquisition that can change the DHCPv6 address.
</hs>
If so, while I'm not necessarily opposing to the restriction, but I
don't see a strong reason for that either. In fact, the sense of the
following part of RFC4862 seems to be applicable to addresses configured
via DHCPv6:
Assuming the lifetimes used are
reasonable, this technique implies that a temporary outage (less than
the valid lifetime) of a router will never result in losing a global
address of the node even if the node were to reboot.
(BTW: this seems to be an out-of-scope thing - see the general comment
above).
<hs> We agree DHCPv6 is out of scope of this draft. We will remove the
mention of DHCPv6 from bullet 1. However, we have bullet 1 from this
draft included in our nd-updates draft so we don't lose the DHCPv6
context we wanted to preserve.
</hs>
- Section 2, bullet 2
While I personally agree with this policy, we should note that there are
other (probably a non-negligible number of) people who want to introduce
a DHCPv6 option specifying on-link prefix information. In my
understanding it's still an ongoing issue and the result of the
discussion may affect this bullet.
<hs> Our drafts have been written based on RFCs up till 4861 and 4862
which still make no mention of DHCPv6 carrying on-link prefix
information. One should not confuse our drafts which are dealing with
clarifications related to existing ND RFCs up to 4861 and 4862 with
existing tentative discussions currently taking place in the DHCPv6 WG.
One cannot expect new DHCPv6 WG items and impacting ND just yet. We
personally haven't even agreed to the DHCPv6 WG item in this regard.
</hs>
- Section 2, bullet 6
(just as a comment) Optimistic DAD (RFC4429) implicitly indicates
possible benefit of using a larger DupAddrDetectTransmits value:
These problems exist, and are not gracefully recoverable, in Standard
DAD. Their probability in both Optimistic and Standard DAD can be
reduced by increasing the RFC 2462 DupAddrDetectTransmits variable to
greater than 1.
<hs> True. All we wanted to highlight here was that default for
DupAddrDetectTransmits is one. Some new implementors to IPv6 who are
developing RFC 2461 or RFC 4861 protocol don't see a value of this
variable in the RFC 2461 or 4861. These folks don't look into RFC 2462
or 4862 where the default is defined. Also, as described above, we'll
move this bullet to the nd-updates draft.
</hs>
- Section 2, bullet 7
Point 2 and 3 seem to contradict each other, or at least be confusing.
Point 2 states address resolution must not be performed:
2. The host MUST NOT perform address resolution for non-link-
local addresses.
while point 3 talks about the case where address resolution fails:
3. [...], address resolution has
failed. As specified in the last paragraph of section 7.2.2
I think this is just a matter of wording. Maybe we should use a
different term than "address resolution" in point 3.
<hs> You are correct. We will change wording of point 3 as follows:
"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 (RFC 4861) [RFC4861]: 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."
</hs>
- Section 2, bullet 7 (point 3)
[...]. 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.
Section 7.2.2 of [NDbis] does not actually cover this case: it only
talks about the actual address resolution fails after a number of
transmissions of NS without any NA replied. If this tries to suggest an
analogous behavior, that might be fine, but then saying "As specified
in..." is not appropriate.
<hs> Our intent was to suggest analogous behavior. See changed text if
item 3 above.
</hs>
Also, I actually don't necessarily think sending an ICMPv6 error in this
case is the best way. Since this is a synchronous error, the protocol
stack (depending on the implementation details, though) can return an
immediate error to the caller (e.g., a failure of a system call). In my
understanding BSD and Linux would behave that way rather than sending an
ICMPv6 error.
<hs> That is why the changed text specifies MAY. However, in general,
the way a particular implementation's API is currently laid out should
not dictate protocol design.
</hs>
- Section 2, bullet 7
[I.D.ietf-v6ops-onlinkassumptions] has been published as RFC4943.
<hs> Right - this draft became an RFC after we published our drafts. We
will make that change.
</hs>
- Section 2.1
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.
First of all, I couldn't parse this sentence.
<hs> We can reword this to "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."
</hs>
But in any event, this seems to talk about the case where a host
configures its addresses via DHCPv6 and RA does not provide any on-link
information. While 'no prefix advertised' is included in this scenario,
I think it should be a more general form, that is, RA does not contain a
prefix information option with the L flag being on.
<hs> We discuss the L bit clear case in section 2.3 </hs>
[...] On receipt of the RA, the host uses DHCPv6 to
acquire an IPv6 address.
I would rephrase this to "the host can use DHCPv6 to acquire an IPv6
address" because our latest interpretation of the M bit just indicates
the availability of a DHCPv6 server for address configuration, and does
not necessarily specify the host's behavior.
<hs> We can reword this to "On receipt of the RA, the host in this
example chooses to use DHCPv6 to acquire its IPv6 address."
</hs>
[...] 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.
This does not make sense since Redirect does not always include target
link-layer address option; then the host MUST rather perform address
resolution.
<hs> We have re-worded the entire Redirect text to make several Redirect
cases clear.
1. At the end of sections 2.1 and 2.2.1, the last paragraph is the same
as below.
"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."
The paragraph above has been changed to
"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. For changes
to the on-link behavior in the presence of Redirects, see the Redirect
Clarifications section."
2. See new section 4 below.
"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.
The ICMP field of the Redirect message has a Target Address field. In
the presence of a Target link-layer option included in the Redirect, the
host MUST NOT issue an NS to resolve the destination. In the absence of
any Target link-layer option 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. 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 MUST 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 MUST 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
MUST issue an NS to resolve a non-link-local destination if the host
does not already have this information in its neighbor cache. Once the
destination host responds to the NS, the source host will thereafter
send packets directly to the destination host."
</hs>
- Section 2.2
Consider the following scenario with one rogue node and two other
hosts on the same link. [...]
[...] Host1
decides to send all of its traffic to the on-link authority, the
default router, even though the destination prefix is on-link.
I don't understand what this paragraph tries to indicate. Please
elaborate.
<hs> What we are saying is that even with the On-Link bit set, the host
MAY still decide to send all its non-link-local traffic to the default
router.
Setting the on-link bit does NOT guarantee that a host will always
perform address resolution. Our paragraph describes an example of a
situation where the host decides to send traffic to the default router
even when the address has been specified to be on-link. The reason why
the host may do this is because the host knows that only the router is
the authoritative source of on-link information, and the host's own
on-link cache cannot be trusted.
</hs>
- Section 2.2.1
[...] 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.
This doesn't make sense (see comment about Section 2.1).
<hs> See our explanation above in response to your comment about Section
2.1.
</hs>
- Section 4
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.
This doesn't make sense (see comment about Section 2.1).
<hs> See our explanation above in response to your comment about Section
2.1.
</hs>
Thanks.
Hemant & Wes
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba
Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Network Working Group H. Singh
Internet-Draft W. Beebee
Intended status: Standards Track Cisco Systems, Inc.
Expires: May 3, 2008 October 31, 2007
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 May 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 May 3, 2008 [Page 1]
Internet-Draft ND On-link Determination October 2007
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 . . . . . . . . . . . 7
2.3. RA Advertises a Prefix with the On-link(L) Bit Clear . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Singh & Beebee Expires May 3, 2008 [Page 2]
Internet-Draft ND On-link Determination October 2007
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 May 3, 2008 [Page 3]
Internet-Draft ND On-link Determination October 2007
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. 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 Prefix Information
Option (PIO) paragraph of section 6.3.4 of RFC 4861 [ND].
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 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
[RFC.ietf-v6ops-onlinkassumptions] provides justification for
these rules.
The type of RA received can further determine host behavior.
Singh & Beebee Expires May 3, 2008 [Page 4]
Internet-Draft ND On-link Determination October 2007
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 behavior 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 behavior in the presence of Redirects, see the
Redirect Clarifications section.
2.2. RA Advertises a Prefix with the On-link(L) Bit Set
Security consequences of RFC 4861 [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 4861 [ND] defines the Valid Lifetime in the PIO
as:
Singh & Beebee Expires May 3, 2008 [Page 5]
Internet-Draft ND On-link Determination October 2007
"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 4861 [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 4862
[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 4861 [ND] mentions that hosts MAY send all
traffic to the default router without performing address resolution
first:
"Stateless address autoconfiguration RFC 4862 [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 4862 [ADDRCONF] and resets its
StoredLifetime (or RemainingLifetime in RFC 4862 [ADDRCONF]) to two
hours and avoids the denial of service attack. 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.
Singh & Beebee Expires May 3, 2008 [Page 6]
Internet-Draft ND On-link Determination October 2007
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. For
changes to the on-link behavior in the presence of Redirects, see the
Redirect Clarifications section.
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]."
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
Singh & Beebee Expires May 3, 2008 [Page 7]
Internet-Draft ND On-link Determination October 2007
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
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 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.
Singh & Beebee Expires May 3, 2008 [Page 8]
Internet-Draft ND On-link Determination October 2007
The ICMP field of the Redirect message has a Target Address field.
In the presence of a Target link-layer option included in the
Redirect, the host MUST NOT issue an NS to resolve the destination.
In the absence of any Target link-layer option 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. 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 MUST 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 MUST 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 MUST issue an NS to resolve a non-link-local destination if the
host does not already have this information in its neighbor cache.
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.
Singh & Beebee Expires May 3, 2008 [Page 9]
Internet-Draft ND On-link Determination October 2007
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, Bernie Volz, Jinmei Tatuya,
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,
"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.
Singh & Beebee Expires May 3, 2008 [Page 10]
Internet-Draft ND On-link Determination October 2007
Authors' Addresses
Hemant Singh
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 1622
Email: [EMAIL PROTECTED]
URI: http://www.cisco.com/
Wes Beebee
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 2030
Email: [EMAIL PROTECTED]
URI: http://www.cisco.com/
Singh & Beebee Expires May 3, 2008 [Page 11]
Internet-Draft ND On-link Determination October 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
[EMAIL PROTECTED]
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Singh & Beebee Expires May 3, 2008 [Page 12]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
