Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft]

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sun, 5 Nov 2000 14:04:41 +1100

>    On the topic of new version of MIPv6, I'd like to bring up
>    one possible improvement. DAD !
>
> => this issue really depends on the type of the links which
> are used then PLEASE give the context to us!
>
        => Which context is RFC 2462 written into ?
        I'm referring to links that use DAD I don't see a
        need to refer to "a" link type.
        If your link does not use DAD or uses PPP ...etc
        then you do not need to worry about this.
        But if you're running 802.11 for example then
        you probably will use DAD.
        Stateless autoconfiguration and MIPv6 are independant
        of the underlying layers.

>    I don't think DAD is only relevant for fast handoffs.
>    I believe it is also relevant to the current standard.
>    As said earlier, with DAD we could be looking at a
>    2 second delay for the handoff. Certainly unacceptable
>    for any type of service.
>
> => I disagree! If it takes some seconds to be attached to the link then
> DAD is no more an issue.
>
        => Sure, but what if it doesn't take that long ?

>  And if you believe a 2 second delay is very
> high then you should ask for fast boot for every devices (routers,
> computers running fatware OSs, ...).
>
        => I don't see the analogy here. I'm talking about
        a delay every time you do a handoff.

>    So what I have in mind is very simple,
>
>    execute handoff,
>
> => how the handoff is detected is very important: in many cases
> you still use the old COA on the new link just because you don't
> know it is a new one.
>
        => That's a separate issue. I'm talking about the case
        when you know that you moved. That's what I meant
        by "execute handoff" above.
        The bottom line is you don't know that you moved
        (on L3) unless you get a new RA and you lose your
        reachability to your old default router. When that happens
        and you get a new COA then you need to follow RFC
        2462. Hence the delays. There is an interworking
        problem between the 2 standards clearly.
>
> => a simple(r|st) solution is to use only point-to-point links
> where IPv6CP (or a similar tool) will do the DAD for free. This is
> why the context is important!
>
        => This is one scenario. Clearly we can't enforce that in all cases.
         Therefore the context is, the use of stateless autoconfiguration
         and MIPv6 on links that do not provide DAD for free.
        Of course if the network doesn't need DAD then it's not an issue.

        Regards,
        Hesham

---

From: Francis Dupont <[email-masked]>
Date: Mon, 6 Nov 2000 10:41:20 +0100

In your previous mail you wrote:

=> the same than RFC 2461!

=> but "links that use DAD" refer only to one kind of links
(no point-to-point, no NBMA).

=> 802.11 with overlapping cells is one link type where you should use DAD
but in some situation you can['t] use it in time. Mu concern is the DAD issue
exists only for some special links, not in general, then the mobile IPv6
document is not the best place to deal with it. For instance you can't
put a MUST for something specific...

=> neighbor discovery is dependent of the underlying layer in practice then
or you say nothing for special cases in the mobile IPv6 document (the current
case) and you produce an additional "application" document, or you have
to add something for every cases in the mobile IPv6 document. The result
will be the same but perhaps not at the same date...
To summary: the mobile IPv6 document must NOT do the assumption that
cellular == wireless == mobility!

=> the term "you know that you moved" is not enough accurate because
the important point is to know that you are moving before to be attached
to the new link. If you can't know then if someone uses the same interface ID
then you'll kill it, if you can know then you can (then must) avoid this
situation, ie. DAD can/must be done before sending any (other) packets on the
link. Of course this really depends on how the movement is detected and done
at the layer 2 (then the details should not be in the mobile IPv6 primary
document).

        The bottom line is you don't know that you moved
        (on L3) unless you get a new RA and you lose your
        reachability to your old default router.

=> this is a special case because you have moved from one link to another
link without a reliable layer 2 indication (like a carrier loss followed
by a restart). This is not the general case. The other case is not too.
gain cellular != wireless != mobility

        When that happens and you get a new COA then you need to
        follow RFC 2462. Hence the delays. There is an interworking
        problem between the 2 standards clearly.

=> there is a rationate for RFC 2462. The idea of DAD is not only
to detect collisions but also to detect them before bad consequences
of collisions. For the first point you can (then should) do a DAD
at any time, for the second (which is important in the real world)
you need to perform a DAD before using the address, ie. before
sending any other packets.
 Then if you apply this to our discussion you get two different cases:
 - you know you have moved too late then you can do the DAD when you'd like,
   of course the sooner is the better but if you collides you've already
   collided.
 - you know you are attaching to a new link then you must perform a DAD,
   for instance if you are adding a new Ethernet interface to your laptop
   you must keep the DAD phase, the only "improvement" you can do is
   to remove 0 to MAX_RTR_SOLICITATION_DELAY of the end of 5.4.2.

To quote RFC 2462:

   It should also be noted that Duplicate Address Detection must be
   performed prior to assigning an address to an interface in order to
   prevent multiple nodes from using the same address simultaneously.
   If a node begins using an address in parallel with Duplicate Address
   Detection, and another node is already using the address, the node
   performing Duplicate Address Detection will erroneously process
   traffic intended for the other node, resulting in such possible
   negative consequences as the resetting of open TCP connections.

=> no special case can be enforced in all cases... We should agree
about this (ie. "PPP everywhere" is just a counter-provocation :-).

Regards

[email-masked]

PS: the simplest (and cleanest) way to solve this issue is to write
an IPv6-over-foo document about IEEE 802.11-like networks. The DAD
behavior will be a link property and it won't be applicable to
IEEE 802.3 networks for instance.