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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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.

- 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.

- 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)?  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).

- 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.

- 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.

- 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.

- 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.

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.

- Section 2, bullet 7

[I.D.ietf-v6ops-onlinkassumptions] has been published as RFC4943.

- 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.

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.

   [...]  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.

   [...]  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.

- 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.

- 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).

- 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).

					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
--------------------------------------------------------------------