Optimistic Duplicate Address Detection (DAD) for IPv6
RFC 4429

To: ipv6@ietf.org
From: Thomas Narten
Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' to
Proposed Standard

I've reviewed this document and on the whole think it's fine for PS.

But I do have one general concern. This document requires that an
implementation do what in practice, I think might be "difficult" for
some implementations. While that is OK at one level, I fear that some
implementors will do most of this spec, but not all of it. I wonder if
that would be a good outcome.

For example:

>    * (modifies 7.2.2)  When a node has a unicast packet to send from an
>        Optimistic Address to a neighbor, but does not know the
...snip...
>        the link in the hope that the packet will be redirected.
>        Otherwise it SHOULD buffer the packet until DAD is complete.

will implementations really bother with this? Or will they be tempted
to skip this because it is "too hard" for a particular implementation?

>    * Nodes implementing Optimistic DAD SHOULD additionally implement
>        Secure Neighbor Discovery [SEND].

This seems like gratuitous recommendation. This either requires
justification, or removal. (I'd think the latter.)

>    Tentative Address - an address for which a node has not yet completed
>        DAD is regarded as Tentative: a single Neighbor ...
...snip...
>        using it.
>
>    Deprecated Address - an address which should not be used if an
>        alternative is available.
>

Wouldn't it be better to just use the same definitions as appears in 2462?

Editorial/minor:

>    Optimistic Address - an address which is available for use despite
>        DAD not being fully complete.  This memo places restrictions on
>        the use of Optimistic Addresses.
>

s/which/that/

>    Standard Node - A Standard Node is one which is compliant with RFCs
>        2461 and 2462.
>

s/standard/conventional/? (nodes implementing this spec will be
"standard" too)

>    * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation
>        for an Optimistic Address from the unspecified address.  This NS
>        indicates that the address is a duplicate, and it MUST be
>        deconfigured as per the behaviour specified in RFC2462 for
>        Tentative addresses.

Suggested reword of second sentence::

    Receipt of such an NS indicates that the address is ...

>    The ON will immediately send out a Neighbor Solicitation to determine
>    if its new address is already in use.

s/new/optimistic/

>    router behaviour, eg: that the router includes SLLAOs in RAs, and

s/eg:/e.g.,/


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Ballot discuss]
Need follow up on comments from Jari as per below.

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Wednesday, May 25, 2005 13:34
To: Wijnen, Bert (Bert); Margaret Wasserman;
nick.moore@eng.monash.edu.au
Cc: Aaa-Doctors (E-mail)
Subject: Re: Please Review: documents on IESG Agenda for May 26, 2005
Telechat



>  o draft-ietf-ipv6-optimistic-dad-05.txt
>    Optimistic Duplicate Address Detection for IPv6 (Proposed Standard) - 5 of
>    6
>    Token: Margaret Wasserman
> 
>
Another draft review:

Overall verdict:

I support this work in general. There are optimization efforts
relating to, I believe, all parts of the initial network attachment
or movement stack, and such optimizations are necessary in
order to increase performance of mobile solutions to a level
where real-time services can be used over them.

I also support this specification. The protocol seems solid,
and I can't see any major problems. A couple of technical
issues below, however. Hopefully you can solve them by
more specific requirements and/or adding explanatory text.
Some editorial issues too below.

Technical:

>    * Optimistic DAD SHOULD NOT be used to configure addresses unless the
>        probability of collision is exceedingly small.

I find it very hard to implement this. More guidance would be
needed. Did you mean "... SHOULD NOT when addresses have
been configured manually"?

>    * (modifies 5.5) A host MAY choose to configure a new address as an
>        Optimistic Address.  A host which does not know the SLLAO of its
>        router SHOULD NOT configure a new address as Optimistic.  A
>        router SHOULD NOT configure an Optimistic Address.

There's probably an easy explanation to this, but I don't understand
why we need to prevent optimistic dad when the link layer address
of the router is not known. Presumably an RS/RA is in progress
at the same time (and the RS is sent from the unspecified address).
Can you explain this to me?

>    This memo introduces a new address state, 'Optimistic', that is used
>    to mark an address which is available for use but which has not
>    completed DAD.  Protocols that do not understand this state should
>    treat it equivalently to 'Deprecated', to indicate that the address
>    is available for use but should not be used if another suitable
>    address is available.

I'm having some trouble understanding the word "protocols" above.
Do you mean upper layers? Is there an implication that before an
application can take advantage of the faster setup times, it needs
to support an extended API to the IP stack so that it can check
whether it wants a optimistic address or not. Some text about
this would be useful for the other readers too and not just me,
I think.

Editorial:

>    Optimistic Duplicate Address Detection is an interoperable
>    modification of the existing IPv6 Neighbor Discovery (RFC2461) and

I'd be surprised if this was not interoperable, but I think you
mean s/interoperable/backwards compatible/

>    [SEND]  J. Arkko (Ed.), J. Kempf, B. Sommerfeld, B.Zill, P. Nikander.
>        SEcure Neighbor Discovery (SEND), revision 06.  (draft-ietf-
>        send-ndopt-06).  July 17, 2004.

RFC 3971. Change tag too, to be inline with the rest of the references.

>    [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6,
>        revision 24 (draft-ietf-mobileip-ipv6-24).  June 2003 ...
>        Expired December 2003.

RFC 3775. Tag too.

>    [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6,
>        revision 00 (draft-koodli-mobileip-fastv6-00).  October 2000 ...
>        Expired April 2001.

Hmm... isn't this fmip, and isn't this an RFC already? But I could
be mistaken.

>    When an NA is received from the collidee defending the address, the

"collidee" is not a word according to unix spell.

>    * clearing the 'Override' flag in Neighbor Advertisements for

s/clearing/Clearing/ (I think)

>    * If the ON isn't told the SLLAO of the router in an RA, and it
>        cannot determine this information without breaching the rules
>        above, it MUST wait until DAD completes despite being unable to
>        send any packets to the router.

Indentation is strange here.

>        A host which does not know the SLLAO of its
>        router

Wouldn't s/SLLAO/link layer address" work better here?

[Ballot comment]
Section 3.2 is titled "Modifications to RFC 2461 Neighbor Discovery".  Shouldn't this document thus be identified as updating RFC 2461?  Similar question for Section 3.3 (RFC 2462).

[Ballot comment]
In 4.3, I found this a bit hard to parse:

  Once the Optimistic Address has completed DAD, it acts exactly like a
  normal address, and so interoperation cases only arise while the
  address is Optimistic.

I assume it means that the special rules for Optimistic Addresses aren't
applicable once the Address is marked Preferred or Deprecated.  I think
that is clear enough without saying it again here, but if you do need to,
some other phrasing might be needed.

[Ballot comment]
Possible clarifications from review by Spencer Dawkins:

... it's confusing to new readers that "standard DAD" isn't defined - there's nothing called DAD except optimistic DAD until Section 4.4). Maybe this is OK. I wish the abbreviation was ODAD, though.

In Section 1.1, I would really like to see explicit numbers here - what is the delay before an address can be used when an IPv6 node uses ND or SLAAC, and what is the corresponding delay using optimistic DAD? I've seen enough IETF discussion of fast handoff, etc. to suspect that some people will be hoping this is the 50-ms fast handoff solution... I think I can figure the numbers out from RFC 2641, but you guys already know what you're thinking!

I'm a little confused by the text in 3.2 - up to this point, Optimistic DAD is described as safe, so why is its use SHOULD NOT "unless the probability of collision is exceedingly small"? Just a sentence or two would be good, but there's no discussion of this point until Section 4.2.

In Section 4.2, "the ON will hopefully know all it needs to know about the router from the initial RA" is really informal text, even for a non-normative section. Could you add a phrase detailing the kind of things the ON hopefully knows?

Appendix A is pretty helpful, but I didn't see any reference to it in the rest of the text. A pointer would be nice, especially somewhere near Section 4.2, which discusses collision probability concerns.

Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes



2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?

Yes, it has been reviewed by key WG members and the chairs
have no concern with the reviews.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?

No.



4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.

No concerns.



5) How solid is the WG consensus behind this document?  Does it

  represent the strong concurrence of a few individuals, with others

  being silent, or does the WG as a whole understand and agree with

  it?

The working group as a whole appears to understand and agree with
the contents of the document.



6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.

No.



7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?



Yes.



- Technical Summary


Optimistic Duplicate Address Detection is an interoperable
modification of the existing IPv6 Neighbor Discovery (RFC2461) and
Stateless Address Autoconfiguration (RFC2462) process.  The intention
is to minimize address configuration delays in the successful case,
to reduce disruption as far as possible in the failure case and to
remain interoperable with unmodified hosts and routers.


- Working Group Summary



The IPv6 working group has done extensive review of this document and

this document reflects the consensus of the group.



- Protocol Quality



This document has been reviewed by members of the ipv6@ietf.org

mailing list and by the working group chairs.