RE: comments on draft-wbeebee-on-link-and-off-link-determination-00

["Hemant Singh (shemant)" <[e-mail]>]

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: [e-mail]; Wes Beebee (wbeebee)
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]

Sent: Monday, October 29, 2007 1:45 AM
To: Hemant Singh (shemant); Wes Beebee (wbeebee)
Cc: [e-mail]
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.
					[e-mail]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------