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 21:36:59 +1100

>  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).
>
        => I can't see how this is not true !
        If you statelessly autoconfigure yourself with an address
        then you _MUST_ do DAD. It is certainly not a coincidence
        that they are in the same RFC.

>         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).
>
        => I realise that it works for both. But in many situations where
        time matters you would rather use stateless address configuration.
        Of course the fact that you have to do DAD (in some links) slows
        things down.

>         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.
>
        => Well, they should be and they are. So if we add DAD as
        another case that might be widely used I don't think it would
        do any harm to the spec. As I said it is only a problem with
        mobilty therefore it is certainly relevant to the MIPv6 spec.
        Do you really see any harm done by clarifying this ?

>    > 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.
>
> => 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.
>
        => You also have L2 indications in a wireless system clearly.
        They may not be identical but certainly similar.

> 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.
>
        => Cellular systems and LANs are two completely different systems.
        You also have L2 indications in these systems in a similar
        way (not the same of course) as you would on Ethernet L2.

>    > gain cellular != wireless != mobility
>
>         => I know. I don't see where you read the oppsite of that in
>         what I'm saying.
>
> => because the context where your proposal has a meaning is the cellular
> one even if you don't say this
>
        => That's not true at all. If I was only worried about a cellular
system
        I wouldn't bring this issue up. I've mentioned this before, the IPv6
        based cellular systems I'm aware of do not use DAD.
        Therefore it is not a concern of these systems.

> and because I am really tired to see
> mobile IPv6 implementations which don't support multihomed
> (multi-interface)
> hosts.
>
        => I really can't see how this is relevant to cellular.
        Any terminal can have multiple interfaces.
        If implementations do not support them there are
        probably other reasons and you could check with
        implementors for that.

        Regards,
        Hesham

---

From: Francis Dupont <[email-masked]>
Date: Tue, 7 Nov 2000 13:50:40 +0100

then you _MUST_ do DAD.

=> this is the same for statefull autoconfigure too.

           It is certainly not a coincidence that they are in the same RFC.

=> they are in the same RFC because DAD is for stateless and statefull
autoconf, the stateless part was ready and the statefull one was not
(in fact this is not yet ready today). The RFC is not only about
stateless autoconf, it is about shared part (mainly DAD) and interactions
between the two modes too. Just ask authors...

=> this depends on the wireless system. Some have real carrier detections
and some have nothing, for instance the non-standard ad hoc mode by Lucent
for 802.11 (which can be considered as a cellular LAN if we need a
definition by example).

           => Any terminal can have multiple interfaces.

=> it should...

=> I've checked. For too many of them to test mobility you have just
to unplug your RJ45 Ethernet and to plug it to another link. This is
supposed to model some 802.11 systems (but fortunately they have in
general a more clever way to work :-)...
It is this limited view of what is mobility which makes me very tired
and I believe our DAD discussion is too marked by that. This is why my
first remark was about the context: with it we can know if the DAD issue
is a general one or it is only for some applications (real-time) on a
special kind of links (what I have called cellular LANs). In both cases
it is useful to discuss (a special case issue is still an issue) but
a general issue should be in the general document (ie. can slow it down)
and a specific one should be addressed in a specific document.

Regards

[email-masked]