Subject: Re: [MOBILE-IP] MIPv6 address conflict checking?

From: Thomas Eklund <[email-masked]>
Date: Mon, 13 Dec 1999 10:21:43 +0100

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]]
> Sent: Thursday, December 09, 1999 5:45 PM
> To: [email-masked]
> Subject: Re: [MOBILE-IP] MIPv6 address conflict checking?
>
>
>  In your previous mail you wrote:
>
>    * If a Mobile IPv6 Node uses IPv6 stateless
> autoconfiguration to form
>      care-of addresses, does it have to verify the uniqueness
> of the link
>      local and globally routable address when it moves to a new IPv6
>      subnet?
>
> => it SHOULD do it. Usually the DAD (uniqueness check) is done only
> on the link-local address because other addresses are derived from it
> using stateless autoconfiguration.
>
>    RFC 2462 describes the use of Neighbor Solicitation and Neighbor
>    Advertisement messages to detect address conflicts,
> however, it is not
>    clear to me whether doing this is a requirement.
>
> => it is not a requirement but a very useful feature.
>
>    If it is a requirement, making a fast handover is difficult,
>    as waiting for a Neighbor Advertisement "not to appear" is
> time consuming.

---------------------
It is a tradeoff between radio resources and granularity of the router
advertisements. If you advertises them more often then the standrad 3 sec.
you will get a "speakier" radio wich would limit your bandwidth, and if its
advertised to seldom it will take time to discover a movement. So its a
tradeoff and you would have to tune for different network.

--------------------

>
> => it is a safety against speed trade-off. Personally I
> prefer safety...
>
>    * Would it be ok to skip address conflict checking in this case?
>
> => same question, same answer.
>
>    * Or, could one perhaps do address conflict checking "reactively"
>      (i.e. let the Mobile Node start to use the address
> immediately and
>      resolve the rare(?) conflicts afterwards if they occur)?
>
> => if there is a conflict (rare because interface ID has 64 bits,
> ie. you need more than 2^32 nodes to get collisions) you are dead!
> The real problem is not with collisions but with management
> (ie. human)
> errors and DAD is the only way to detect them before a disaster.
> (believe me, DAD is *useful*!)
>
>    * What do current Mobile IPv6 implementations do?
>
> => when a new interface is inserted my implementation does a
> (fast) DAD
> (fast: no extra delay, cf RFC 2462 5.4.2 last paragraph), in
> other cases
> (like when the mobile is connected to a new LAN without a
> clear indication
> from lower layer) no DAD is done because in general it is too late to
> avoid a conflict.

--------------------------------
There are though some easy tricks you can do, and that is to have a pool of
static addresses that could be autoconfigured with DHCP.
So when you autoconfigure using ND and get a conflict when you do your DAD,
you do a stateful DHCP request from this pool. This is a very nice way of
solving the problem.
This is how I have done it.

/Thomas Eklund, SwithCore

> My opinion is when you are using something like a wireless or
> a cellular
> network a lower layer mechanism can be far faster than mobile IPv6
> handover, but you still need mobile IPv6 because it is more general,
> for instance you can change the technology (for instance leave your
> 9600bits/s GSM data expensive service for a 100Mbits/s cheap
> Ethernet).
> Then the speed of handover is not an issue for me.
>
> Thanks
>
> [email-masked]
>

---

From: Francis Dupont <[email-masked]>
Date: Mon, 13 Dec 1999 10:41:14 +0100

It is a tradeoff between radio resources and granularity of the router
   advertisements. If you advertises them more often then the standard 3 sec.

=> standard is 600 seconds (RFC 2461 6.2.1) not 3... Router advertisements
are expensive then I don't believe it is a good idea to have very frequent
router advertisements, even with proposed adjustements of section 6.5 of
draft-ietf-mobileip-ipv6-09.txt.

   --------------------
   There are though some easy tricks you can do,

=> no, there is no easy trick to recover when you have two nodes with
the same address.

   and that is to have a pool of
   static addresses that could be autoconfigured with DHCP.
   So when you autoconfigure using ND and get a conflict when you do your DAD,

=> the discussion was about is the DAD necessary or not. I believe your
easy trick is about how to recover from a conflict detected by the DAD
(there are plenty easy tricks in such a case, for instance a random
interface ID should near always work with less than one billion of nodes
are on the link :-).

[email-masked]

---

From: Jon-Olov Vatn <[email-masked]>
Date: Mon, 13 Dec 1999 15:05:07 +0100

First, thanks for all the feedback, Francis and Thomas. 
It has helped me a lot.

> interface ID should near always work with less than one billion of nodes

Sorry, I was not very clear in initial message, as my main concern
is actually if a change of AP (and possibly IPv6 subnet) requires me
to stop the communication until link layer address uniqueness has
been verified. (Also, I should have pointed out that my concern is
related to high speed wireless LANs, not WANs.)

I do not want to skip DAD, but if it leads to a gap in my communication
of in the order of seconds each time I move to an AP on a different
subnet, I would not be very happy?

I wonder if it in some cases would be ok to do it reactively and resolve
the cases when a conflict actually occurs (note, I do not want to skip it)?
Thus, if Thomas' or any other suggestion of how to resolve a conflict
situation really works, it gives me the answer I was looking for (once
again, apologize for not formulating my initial message very clear).

Also, I'm I right if I say that hosts running Mobile IPv6 could cope with
a conflict situation better that other hosts? If a MN backs off and tries
another address (e.g., using some random interface ID, which you mentioned),
no higher layer connections need to be lost (in contrast to a "normal" host).

/J-O

----------------------------------------------------------------------
Jon-Olov Vatn                         Email:    [email-masked]
Royal Institute of Technology         Address:  KTH-Electrum/204    
Dep. of Teleinformatics                         S-164 40 Kista  SWEDEN
Telecommunication System Lab.         Tel:      +46 8 752 14 24
                                      Fax:      +46 8 751 17 93

---

From: Francis Dupont <[email-masked]>
Date: Mon, 13 Dec 1999 17:42:57 +0100

=> if you don't stop communication, for instance if you send a neighbor
advertisement with the override bit, and you have a conflict you can
get all the traffic for another node and do nasty things (for
instance reset TCP connections).

=> as I've said the first time, this is a safety against speed trade-off.
If there is an other reason to lose some seconds then it is a good
idea to do DAD.

=> there is no possible recovery then the only safe way is to stop
neighbor advertisements for the address and do a DAD. If you have
smooth handover with overlapping cells you can have more than one CoA
then you don't need to stop everything (look at Thomas' suggession).

=> Thomas' idea is not a conflict resolution but a way to overlap
conflict detection with other things. It doesn't apply in every cases
but conflict probability is nearly zero in most of the cases then
you can try to find strategies avoiding or overlapping DAD.
(ie. put a flag in your code for cases where the user wants to spend
time to do DAD :-)

   Also, I'm I right if I say that hosts running Mobile IPv6 could cope with
   a conflict situation better that other hosts? If a MN backs off and tries
   another address (e.g., using some random interface ID, which you mentioned),
   no higher layer connections need to be lost (in contrast to a "normal"
   host).

=> the issue is that damages are not for the MN but for the conflicting node
(usually this kind of conflicts is triggered by a new & fast node (MN here)
and throw the old & legitimate node out of the network: if your MN does
that to the site Web server your network managers won't be happy (:-))!

Regards

[email-masked]

PS: I've already seen a conflict (with IPv4) with an important server as
the victim and I've already seen a conflict detected just in time by DAD
(two reasons to prefer safety over speed).
PPS: in your case a MAC address conflict will do some damage before
DAD can detect it then it is not a shame to rely on MAC address uniqueness.