>> 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 _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/babel-users