[Babel-users] Question about AHCP

[Henning Rogge]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20091129/4cc05d35/attachment-0001.pgp>