Re: [dna] Comments on draft-ietf-dna-protocol

[Sathya Narayanan <[e-mail]>]

Jari

Thanks for the detailed comments.

I wanted to acknowledge the email and let you know that this is on my to-do
list; I will work on incorporating your comments on to the document over the
next couple of weeks. Worst case, I will need to move it until Thanksgiving
break at which point I am likely to have more time to devote to this. Hope
that is alright.

best
Sathya

On Thu, Oct 29, 2009 at 2:57 PM, Jari Arkko <[e-mail]> wrote:

> Sathya,
>
> Here are a few comments on draft-ietf-dna-protocol. Overall, this is a
> complex scheme and having read this again after a long break, I'm now even
> more glad that we got the dna-simple document moving forward. However, I
> think we should publish even dna-protocol as an RFC. It is an interesting
> design worth a permanent record. I do have a long list of comments, though,
> and I hope you can publish a new draft version so that the document can be
> taken forward. I'm thinking of Historical or Experimental as the proper
> designation for the document.
>
> Detailed comments:
>
> The document needs to be resubmitted as it is currently expired.
>
>  Design document for Detecting Network Attachment in IPv6 Networks (DNAv6
>>                                Design)
>>
>>
> Might be better as "Design Alternative for Detecting ..."
>
> Abstract is too long. Maybe you should just keep this part:
>
>  In this memo, a mechanism
>  that was developed for detection of network attachment is documented
>  for future reference.  This memo is an informational document and
>  thus does not define a new standard.  The mechanism proposed in this
>  informational RFC requires the hosts to monitor all the prefixes
>  advertised on the link and use it for link identification in the
>  presence of non-DNAv6 routers is presented.  A more efficient link-
>  identification mechanism requiring the DNAv6 routers to monitor the
>  link for advertised prefixes to assist the hosts in link
>  identification combined with a fast router advertisement mechanism
>  that selects the order of response for the router deterministically
>  is also presented.
>
> Run spell on the document.
>
>  This memo also defines a mechanism to exchange Source Link-Layer Address
>> without affecting the neighbor caches when the host is performing Optimistic
>> DAD.
>>
>>
>
> Wasn't this already in draft-ietf-dna-tentative?
>
>  Even though this
>>   document recommends the use of a prefix as the representative of the
>>   link, future specifications can use the Learned Prefix Option to
>>   include a non-prefix identifier as long as this identifier is 128 bit
>>   long to avoid collision with any currently assigned prefix.  So, any
>>   future non-prefix link identifier MUST be 128 bits long.
>>  5.1.6.3.1  Using non-prefix identifier as common prefix
>>
>
> I felt that this extensibility confused the document a little bit. Could
> this be removed?
>
>    DNAv6 avoids this delay by using a different mechanism to ensure that
>>   two routers will not respond at exactly the same time while allowing
>>   one of the routers on the link to respond immediately. The results of
>> that function are then compared to create
>>   a ranking, and the ranking determines the delay each router will use
>>   when responding to the RS.  The router which is ranked as #0 will
>>   respond with a zero delay.
>>
>>
>
> Do I understand correctly that there will still be several responses to a
> single RS? Perhaps this should be highlighted. Note that that your scheme
> does not provide the same overall limit on the number of RAs appearing on
> the link as the rate limit defined in RFC 4861.
>
>  4.1  New Flags
>>
>>   This document defines two new flags to be exchanged between the
>>   router and hosts.
>>
> I'd like to see these flags in the extension option defined in RFC 5075,
> not directly in the RA header.
>
>  the following information MUST be stored:
>>
>> 1.  Link-local source address of advertising router
>>
>> 2.  Token equal to the first 64 bits of an SHA-1 hash of the above address
>>
>>
> It seems a bit silly to have a MUST requirement to store X and f(X)...
>
>    Each router MUST include itself in the DNARouterList and generate a
>>   token for itself as described above based on the link-local address
>>   used in its RA messages.
>>
>>
> As above.
>
>    an abbreviated Router Advertisement.This abbreviated advertisement
>>
>
> Missing space
>
>    A CompleteRA is formed as follows:
>>
>
> Missing space
>
>  Note that this smallest prefix
>>   is the smallest of all the prefixes configured on the routers on the
>>   link and may not be the smallest prefix used in the link through
>> stateful address configuration.
>>
>>
>
> Although, at least currently, prefixes used even for stateful address
> autoconfiguration come from RAs.
>
>
>  When a router receives a new prefix in PIO, if the prefix is smaller
>>   than the current common prefix and has valid lifetime greater than
>>   LEAST_VALID_LIFETIME, the router selects that new prefix as a new
>>   common prefix.
>>
> But it is also possible that the new smallest prefix comes through
> configuration in THIS router. In that case it is not the reception of the
> PIO that triggers this selection.
>
>    Whenever a router sends an RA, whether solicited or unsolicited, it
>>   MUST include the common prefix in it.  Hence, all RAs MUST carry the
>>   common prefix except the abbreviated RA message sent in response to a
>>   RS with LO.
>>
>
> I guess I am missing the point of having BOTH the landmark AND the common
> prefix. Is there some difference in use that prevents just selecting one,
> and sticking to that?
>
> And if the RAs responding to LO can skip the common prefix, why is it so
> important to include the common prefix in other RAs? Important enough that a
> MUST is needed? Or, if the MUST is really needed, is there something that
> breaks when use just the landmark option?
>
>    Sinice information from the Learned Prefix Option is only stored in
>>
> typo
>
>    IF (Receive RA is a CompleteRA) THEN
>>
>>   {
>>
>>      /* We already checked if there are any matching prefix before.
>>      Since this is a CompleteRA, implies link-change.*/
>>
>>      Link change has occured.
>>
>>      RETURN; // Don't have to do the following checks.
>>
>>   }
>>
>>   {
>>
>>      Link change has occured.
>>
>>      RETURN; // Don't have to do the following checks.
>>
>>   } -->
>>
>>   IF (DNAHostPrefixList is marked as complete (i.e. the completeness
>>   criteria is already met)) THEN
>>
>>
>
> The code seems broken. Is there an IF missing around the braces above?
> There seems to be a RETURN followed by some further code, which does not
> make sense.
>
>    Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done
>>   since the previous link UP event (Previous link UP event here refers
>>   to the link UP received before the current link UP event that lead to
>>   this processing).
>>
>>   IF (One of the received RA contains a prefix matching a prefix in
>>   DNAHostPrefixList from before the current link UP event), THEN No
>>   link change has occured ELSE link change has occured.
>>
>>
>
> Pseudo-code style changed here. Please use the same style, braces etc.
>
>    Note that this procedure does not prevent a MN from sending packets
>>
> s/MN/host/
>
>
> Missing things: I did not see a discussion of how prefixes or routers get
> removed from the host or router data structures.
>
>    received RAs as in Section 5.5.3 of RFC 2461 [3].  That is, if an RA
>>
>
> It seems weird that you refer to the old 2461 here. Also, is the procedure
> presented in Section 5.2.7.3 according to the current understanding of the
> M&O bits?
>
>  6.3  Tentative options
>>
> If you refer to draft-ietf-dna-tentative, do you need this section?
>
>    SEND says that DAD defenses MAY be accepted even from non SEND nodes
>>
>
> ... according to the SEND specification (RFC 3971 Section N.N) DAD defenses
> ...
>
>  SEND says that DAD defenses MAY be accepted even from non SEND nodes
>> for the first configured address [4].
>>
>> While deconfiguring the address is a valid action in the case where a
>> host collides with another address owner after arrival on a new link,
>> In the case that the host returns immediately to the same link, such
>> a DAD defense NA message may be a denial-of-service attempt.
>>
>>
> It seems that there are two separate cases. I believe 3971 & 3972 still
> hold: whenever you create a new address, you should not accept collisions
> beyond a certain collision count. However, IF you have confirmed that you
> re-attached to the same link... I would not run DAD.
>
>  10.  Informative References
>>
>
> You need to split references to normative and informative.
>
>    [3]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
>>         for IP Version 6 (IPv6)", RFC 2461, December 1998.
>>
>>
>
> Refer to the new one instead.
>
> Jari
>
>


-- 
Sathya Narayanan
mailto://[e-mail] <=== Please note new email address