[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?

--Jari