Re: [DNA] comments on draft-ietf-dna-hosts-00

[Sathya Narayanan <sathya@research.panasonic.com>]

Subba Reddy wrote:

>   Here are few comments and questions on host BCP document.
>  
>
Thanks for your comments. I was hoping to receive some feedback before I
created another version of the draft - targetting for mid-to-late June.

>1. In Section 4.1,
>
>   ".....When a host attaches itself to a new L2 link, if the
>   corresponding stored prefix list doesn't contain the prefix it is
>   using, the host SHOULD conclude that it has changed link and initiate
>   new configuration procedure.  If the host finds the prefix it is
>   using in the stored list of prefixes, a host MAY conclude that it is
>   on the same link...."
>
>  
>
In section 4.1, we are suggesting that hosts could maintain a cache
history of all its previous L2-L3 mapping information and use the stored
information to make link change detection. Since, mapping information is
not guaranteed to be correct (there is no lifetime associated to it by
the standards), we want to be conservative - i.e. its OK to conclude
link-change erroneously as during the configuration procedure you will
figure it out, hence the SHOULD - while we don't want to make strong
recommendation on concluding same-link - hence the MAY.

>   I think here "SHOULD" and "MAY" need to be swapped. In section 4.3.1,
>   it is correctly mentioned as follows
>
>   "....   A host SHOULD conclude that it is on the same link if any of the
>   following events happen.
>
>      Reception of a RA with a known prefix on the link...."
>  
>
In section 4.3.1, we are refering to the current list of know prefixes
with their associated lifetime - I guess this difference is not clear -
I will try to make it better in the next version.

>2. In section 4.5, in the table, for RS/multicast RA case, I think Upstream
>is N and
>    Downstream is Y. Downstream is Y because we received multicast RA. We
>are not
>    sure whether RS host sent was received by router or not amd hence
>Upstream is N.
>
>  
>
;-) Thanks for the catch. I will change it.

>3. In section 4.2,
>    "...   While hosts performing DNA do not know if they have arrived on a
>new
>   link, they SHOULD treat their addresses as if they were.  This means
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   that link-local addresses SHOULD be treated as either optimistic or
>   tentative, and globally unique addresses SHOULD NOT be used in a way
>   which creates neighbor cache state on their peers, while DNA
>   procedures are underway.  The different treatment of IP addressing
>   comes from the fact that on the global addresses cannot have an
>   address conflict if they move to a topologically incorrect network
>  where link-local addresses may.  Even though global addresses will
>   not collide, the incorrect creation of neighbor cache entries on
>   legacy peers may cause them some harm...."
>
> Can you please elaborate as what "SHOULD treat their addresses
> as if they were" underlined above means?
>  
>
The following line tries to explain the meaning.

> I am little confused with this line. Also IMHO, this paragraph is a bit
>difficult to understand. It may be better to rephrase it in simple terms.
>  
>
Sure. We will try to improve this section for the next version.

>4.
>Some typos
>
>1. In section 4.5, last paragraph bracket is not closed.
>   "...   Whenever a host receives a hint (see Section 5, after identifying
>the
>   link, it SHOULD verify partial reachability from its default router
>   to itself."
>
>2. In section 6,
>"....       Invalidationof router and prefix list ..."
>
>s/Invalidation of/Invalidationof
>
>3. In section 7.2,
>".......If a host is changing is IPv6 link, the new
>                      ^^^
>   router on that link may have a different configuration and may
>   introduce more delay than the previous default router of the host...."
>
>s/its/is
>
>4.In section 8.2,
>"....   If a non-SEND node forges a DAD defense for an address which is
>still
>   in peers' neighbor cache entries, a host may send a SEND protected
>   unicast neighbor solicitation without a source link-layer address
>   option to one its peers (which also uses SEND). ...."
>                   ^^^^^^^^^
>s/one of its/one its
>
>  
>
Thanks again.

regards,
Sathya