[DNA-BOF] About Charter, DAD, and SEND

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Greg Daley wrote:
> DAD Optimization
...
> This group will specify how to optimize the existing
> procedure for detection of IPv6 address collision. "DAD
> optimization" aims to reduce delay due to the detection of
> IPv6 address availability.
...
> * Develop a DAD optimization protocol independent of link
>   layer technology.
...
> * Define IPv6 DAD optimization Problem Scope
>   (goal: info, initial by IETF58)
...
> * Determine IPv6 DAD optimization Requirements 
>   (goal: info, initial by IETF58/59)


Do we really need a separate problem statement draft
for DAD optimization?  The charter clearly says that
the goal is to reduce delay, and people seem to agree
on that on the mailing list.

IMHO, draft-park-ipv6-optidad-requirement-01.txt
is already fairly good, and could be directly adopted as
a WG item. However, if we do so, I would like to change the R-word
with the less-load "goal", as has recently been done in a few WGs.

What comes to draft-park-ipv6-optidad-requirement-01.txt,
I would suggest adding some text to Section 2. discussing
the scenario where DAD is taking place simultaneously with DNA.
I would also add two requirements/goals:

After 3.5/before 3.6:

   3.N  Interoperability with SEND

    The optimized DAD mechanism SHOULD work when SEND is used.
    It is desirable that the SEND and DAD optimization work
    are closely coordinated so that it DAD optimization could
    benefit from SEND and vice versa.

Somewhere:

   3.N+1  Simultanoeus operation with DNA

    It SHOULD be possible to optimistically use optimized
    DAD addresses even before the DNA process has not
    been completed.  In other words, the hosts SHOULD be
    allowed to send packets to a newly attached link with
    the optimistica assumption that the link is the same
    one that was previously used, without needing to wait for
    the DAD and/or DNA procedures to complete.

What comes to the solutions (I know it is early to speak
about them, but anyway), IMHO using pseudo-random addresses
(e.g. SEND addresses) with careful collision detection
procedures should be able to fulfil the latter goal.

--Pekka Nikander