[Babel-users] Question about AHCP

[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:

 * 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 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.

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.

In short, I'm not a fan of this approach.  I'm therefore thinking about
adding DAD to AHCP itself.

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).

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.

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.

  * 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.

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.

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.

                                        Juliusz