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

From: Sathya Narayanan <[email-masked]>
Date: Sat, 31 Oct 2009 15:50:45 -0700

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 <[email-masked]> 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://[email-masked] <=== Please note new email address

---

From: Sathya Narayanan <[email-masked]>
Date: Wed, 25 Nov 2009 11:33:40 -0800

Jari

I have incorporated your comments in the document. I am going to submit the
modified draft to IETF so that we have a current draft for everybody to
review.

Few followups:

 Even though this
> I felt that this extensibility confused the document a little bit. Could
The non-prefix link identifier: if my memory serves me right, we added this
to allow for the possibility of using other identifiers from underlying
technologies (in particular WiMAX, I think). I removed the reference to
non-prefix link identifiers from the document.

> the link as the rate limit defined in RFC 4861.
I added an explicit sentence "This modified mechanism replaces the rate
limit on responses to RS required by <xref target='RFC4861 />" - Is this
what you had in mind? I also replaced all reference to 2461 with 4861; since
I haven't been involved in IETF for couple of years now, I just want to make
sure that the changes from 2461 to 4861 is not going to affect the original
thinking of the DNA design. If somebody could comment on that, that would be
great.

> not directly in the RA header.
If my memory serves me right, we explicitly removed any specific packet
format or option format information from this memo to avoid any confusion in
terms of its readiness to be implemented. If we are going to publish this as
an 'experimental' or 'informational' RFC,  is it ok to include packet
formats in the document. For now, I just included a single sentence:  The
flags and the options MUST be implemented using Router Advertisement Flags
option specified in RFC 5075 <xref target='RFC5075' />.

> autoconfiguration come from RAs.
Hmmm ... I am not sure what you want me to do here. I just added this
sentence at the end of the previous para. "Although, at the time of the
writing of this memo, prefixes used even for stateful address
autoconfiguration come from RAs."

> breaks when use just the landmark option?
Again, if my memory serves me right :-), we do need both of them: the idea
was to allow LO as an efficient way of asking "Am I still on the link with
this Landmark?" and get an answer "yes/no" - while Complete RA had other
advantages (backward compatible with non-DNA hosts is the most important of
them, I think) - so if the complete RA is being broken up we need to have
something common across the RAs to avoid uncessary link change detection.

> removed from the host or router data structures.
Evey data structure suggested has an associated expiry time through which
the content will be removed. We don't have any specific text to that end, do
you think we need to add something?

> presented in Section 5.2.7.3 according to the current understanding of the

I changed references to 2461 to 4861 and removed the specific section
number. I am not sure I know the answer to your question - I don't know what
is the current understanding of M&O bits - I am hoping somebody can respond
to this; I will also look into it.

> If you refer to draft-ietf-dna-tentative, do you need this section?

I am not sure - for now I am leaving the section in.

> re-attached to the same link... I would not run DAD.

I need clarification on this point: if we decide not to run DAD, we have to
make changes in other places: particularly Section 5.2.7. says
"If the host determines from the received RAs that it has not moved to

   a new link (i.e. the link has not changed) and the previous state of
   an address was "Optimistic", then the host MUST send an NS to confirm
   that the address is unique on the link.  This is required because

   optimistic Duplicate Address Detection may not have completed on the
   previous point of attachment, so the host may not have confirmed
   address uniqueness.
"

 Do you want to me change this as well? There is reason given here for doing
oDAD, which we need to be careful about?

Sathya