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

From: Subba Reddy <[email-masked]>
Date: Fri, 03 Jun 2005 19:15:31 +0530

Hi,

   Here are few comments and questions on host BCP document.

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

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

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.

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

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

Regards
Subba Reddy

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 03 Jun 2005 10:50:50 -0400

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

>   using in the stored list of prefixes, a host MAY conclude that it is
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.

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

>    sure whether RS host sent was received by router or not amd hence
;-) Thanks for the catch. I will change it.

>   link, they SHOULD treat their addresses as if they were.  This means
The following line tries to explain the meaning.

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

>   option to one its peers (which also uses SEND). ...."
Thanks again.

regards,
Sathya