[Babel-users] Question about AHCP

Juliusz Chroboczek jch at pps.jussieu.fr
Sun Nov 29 18:22:58 UTC 2009


>> That's what version 0 of the AHCP protocol did -- it first configured
>> IPv6 statelessly, then used unicast IPv6 to perform stateful IPv4
>> configuration.  It didn't work very well:

> So you just communicate over linklocal IPs and broadcast until the IPs are 
> set?

Yes.  (Link-local multicast, not broadcast.)

> I was not talking about some kind of meta-server. I thought about some
> kind of distributed peer-to-peer sharing of IP addresses.

I see.  I'll try to wrap my head around this idea.

> A node which has owned a lease for a long time should try to "hang" on
> it for a while. Maybe the age of your own lease could be added to the
> PROBE/DEFEND message, so the nodes can decide which side needs to
> change its address.

When everything goes well, no two nodes should ever have the same
address, so only the PROBE/DEFEND mechanism will ever trigger.  And this
mechanism has the property you like -- the more recent node (PROBE)
yields to the established one (DEFEND).

The DEFEND/DEFEND mechanism only triggers when two nodes already have
the same address, and this should only happen after a network partition
is healed.  Healing a network partition, as you justly note, is
always a traumatic experience -- somebody is going to lose his address
in this case.

Adding an advisory priority field to DEFEND messages, as you suggest
(derived from the lease's age or from something else, it doesn't matter)
might be possible.  I need to think it over.

> Maybe the DEFEND mechanism could be some kind of DHT ? So we have
> a redundant and distributed storage we can ask if an IP is already
> taken, even if the node itself is in another part of the network ?

The DHT algorithms I'm familiar with (Kademlia and Chord) require
transitive communication, which is not the case before we've
configured.  Do you know otherwise?

Any DHT-based protocol must be significantly more efficient than simple
flooding.  The mechanism I'm suggesting requires flooding three packets
throughout the network for each configuring node.  I'm not sure it's
possible to have a DHT-based protocol that will be much more efficient
than that.

                                        Juliusz



More information about the Babel-users mailing list