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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Tue, 7 Nov 2000 01:11:39 +1100

>       Stateless autoconfiguration and MIPv6 are independant
>       of the underlying layers.
>
> => 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...
>
        => I guess I don't see it as a very special case. There is a close
        relationship between stateless configuration and DAD. Since MIPv6
        implicitly assumes the use of stateless address autoconfiguration
        then I think it is fair to address DAD. If you believe that this is
a special
        case then I can pick many parts of the spec where there are
underlying
        assumptions about certain types of media.

> To summary: the mobile IPv6 document must NOT do the assumption that
> cellular == wireless == mobility!
>
        => I'm not sure where you read that in what I'm saying. BTW this
        issue is irrelevant for cellular and is not specific for wireless
systems.

>       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.
>
        => An RA is an L3 indicaion. MIPv6 addresses L3 mobility
        There is no need for assuming L2 indication in the MN. They would
        help of course but that assumption is definitely not generic
        for all cases.

> gain cellular != wireless != mobility
>
        => I know. I don't see where you read the oppsite of that in
        what I'm saying.

>         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.
>
        => I agree with the rationale. However my point is there is some
        conflict with "fast mobility".

> 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.
>
        => That's one way of doing it. But of course it has to be done
        for each case. I don't see a major problem with that as long
        as something is done about it. It is only a problem when
        mobility is considered.

        Regards,
        Hesham

---

From: Francis Dupont <[email-masked]>
Date: Tue, 7 Nov 2000 09:34:44 +0100

In your previous mail you wrote:

        => There is a close relationship between stateless
        configuration and DAD.

=> this is not true, the only relationship is they share the same document.
DAD is in fact a fully independent function and may (in fact MUST) be
used for statefull configuration too (aka DHCPv6).

        Since MIPv6 implicitly assumes the use of stateless address
        autoconfiguration.

=> this is not true! Mobile IPv6 is supposed to work with stateful
autoconf too (but as DHCPv6 is not yet ready I can't prove it today).

        If you believe that this is a special case then I can pick
        many parts of the spec where there are underlying assumptions
        about certain types of media.

=> these assumptions should be explicit and minimal.

=> On a common wired system you can't move from a link to another link
without a reliable indication from layer 2 like a carrier loss followed
by a restart sequence. Even Ethernet is supposed to negociate speed
and duplex when you attach a device to a link. The only kind of systems
where you should have transparent movement from a link to another one is
the cellular LAN one.

=> because the context where your proposal has a meaning is the cellular
one even if you don't say this and because I am really tired to see
mobile IPv6 implementations which don't support multihomed (multi-interface)
hosts.

=> mobility is an important property of 802.11-like links then
it is natural IMHO to take mobility into account in an IPv6-over-802.11
document. Today we assume that 802.11 is like 802.3 and this discussion
proves it is not true...

Regards

[email-masked]