Am Sonntag 29 November 2009 17:31:27 schrieb Juliusz Chroboczek: > >> > (If the network would have a mesh-wide multicast implementation, you > >> > could just use it and forget about the forwarders, right ?) > >> > >> Bootstrapping issues. The main reason AHCP implements its own multicast > >> routing rather than relying on the IP layer is that at the point when > >> you run AHCP, the network has not bootstrapped yet. > > > > IPv6 should be up and running at this point, because it's stateless. > > 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?
> * it only worked with hybrid routing (you needed IPv6 in order to > configure IPv4), which is ungood for people running OLSR; > * although the protocol was still well-founded, it did violate > layering, which made it incomprehensible, even to me; > * configuration was slow, since you couldn't configure IPv4 before IPv6 > routing converged. > > The experience with AHCP 0 taught me to avoid weird interactions such as > above, so AHCP 1 configures IPv4 and IPv6 in the same manner. Only minor > leaks between the two address families are allowed, notably in the > Renewing state (see Section 2.2.3.7 in the draft). > > >> that's prefix delegation. Discussed on this list a few weeks ago. > >> > >> The trouble with relying too much on prefix delegation is that it > >> introduces a single point of failure, > > > > Why ? > > With prefix delegation, you have one or two "meta-servers" that serve > out address prefixes to the normal servers. If the meta-servers crash, > the whole network is down. I was not talking about some kind of meta-server. I thought about some kind of distributed peer-to-peer sharing of IP addresses. And maybe something like a DHT to store the leases, so nodes don't loose their lease only because "their" AHCP-server goes down. > > I think it would be nice if AHCP could support a "distributed/stateless" > > IPv4 mode too. > > Yes, it would. As you justly note, this requires implementing duplicate > address detection (DAD), and I believe that it should be done at the > AHCP level -- after all, AHCP already has provisions for flooding > a message throughout the network. Yes, getting a mesh-wide DAD would be a good thing. > The alternative would be to snoop the routing protocol, but that brings > back the kind of weird interactions between layers that I've learnt to > avoid. Furthermore, it is not quite as simple as one might think: > > 1. if you're running in a hybrid network (say, some nodes use Babel and > some nodes use static routing configured by DHCP), you need to snoop > multiple routing protocols. > 2. in a prefix-based protocol such as Babel, a node need not advertise > its own address, it is enough to advertise a prefix that contains its > address. Think a gateway that only advertises the default route, or > a router that manages a given subnet only only advertises the subnet, > or prefix aggregation. I was thinking about snooping the routing table, not the routing protocol. If there is a route with a prefix longer than the IP subnet your mesh lives in, you should avoid to take an IP from this range. This could be an on/off option similar to the DAD. > In short, I'm not a fan of this approach. I'm therefore thinking about > adding DAD to AHCP itself. The two things are not mutual exclusive. > The idea is to have two new messages: > > AHCP_ADDRESS_PROBE: carries a set of addresses, and requests that any > node that has any of those addresses reply with AHCP_ADDRESS_DEFEND. > > AHCP_ADDRESS_DEFEND: carries a set of addresses, and claims that the > sender "owns" the addresses in question. > > Minimal client behaviour (obeyed by all clients, even those that > don't perform DAD) is as follows: > > * upon receiving PROBE with your address in the BOUND/RENEWING state, > reply with DEFEND; > * upon receiving DEFEND with your address in the BOUND/RENEWING state, > unconfigure and switch to INITIAL (i.e. when a conflict is detected, > both nodes give up and start from scratch). I don't think this is a really good approach. 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 it's address. > Note that the second point above, which is necessary in order to deal > with network partitions, makes it easy to DoS any node. Since AHCP is > an insecure protocol, I'm not too concerned about that at the current > stage. Yes. Autoconf is always a good point to DoS a node. But if you want to solve ALL problems at once you get nowhere at all. ;) > At that point, you can have two strategies for DAD: > > * client-based (as in IPv6 autoconf): before switching from INIT to > REQUESTING, a node floods the network with AHCP_ADDRESS_PROBE > a small number of times. If either DEFEND or PROBE arrives, it > switches to INIT and tries again. > Additionally, a node should periodically flood the network with > DEFEND when in the BOUND state. 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 ? > * server-based (as in DHCPv4): before statefully giving out an > address, a server sends an AHCP_ADDRESS_REQUEST. If DEFEND arrives, > it marks the address as taken (i.e. it marks a fictitious lease for > 1 hour or so), and choses a different address. > Additionally, the server should periodically send PROBE for all the > leases it has given out; if a DEFEND arrives from the wrong node, it > should NAK the currently given out lease. I don't like the server based approach. You either add a layer of configuration problems to your network (by partitioning the IP space) or you just push the problem to a "collision between servers" problem I think. > The advantage of client-based DAD is that it works for both stateful and > stateless. The advantage of server-based DAD is that it is more > efficient, since the REQUEST/DEFEND exchange can be sent over unicast > rather than flooding. Yes, having a fixed infrastructure is always more efficient than doing it peer to peer. This might be a point where a DHT can help. > Note that the two strategies can cohabitate in the same network, as long > as the minimal implementation above is met by all nodes. In particular, > it would make sense to do server-based DAD for stateful configuration, > and client-based for stateless. Interesting idea. Henning Rogge
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
