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

[Sathya Narayanan <[e-mail]>]

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


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


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

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



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


> Missing things: I did not see a discussion of how prefixes or routers get
> 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?



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

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.


>
>  6.3  Tentative options
>>
> 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.


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

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