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

[Jari Arkko <[e-mail]>]

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