[Babel-users] Babel v4-over-v6 extension

[Théophile Bastian]

Dear all,

I am a new intern working with Juliusz on Babel.

My goal at the moment is to implement v6-over-v4 routing in Babel, that
is, using an IPv6 address as a next hop for an IPv4 packet. This
would allow, for instance, a router without IPv4 address to be used as
a next hop for an IPv4 packet, since this feature was recently
introduced in the Linux kernel [1].

I have so far experimentally implemented this feature in a fork of
babeld [here](https://github.com/tobast/babeld). This code is NOT
production-ready, and needs to be mostly re-written. It does not
reflect the exact changes we propose either yet.

We have considered three options to design this extension:

(i) One possibility, due to Toke, is to add a v4-over-v6 route whenever
   a router receives an UPDATE for a v4 prefix without a preceding v4 NH
   TLV. The next hop would then be the latest v6 NH TLV, if any, or the
   link-local address of the neighbour announcing the update otherwise —
   just as it would be done for a v6 UPDATE.

* Another possibility is to introduce a new AE for v4-over-v6. This AE
   would behave in the same way as AE 1 (IPv4) in all contexts except
   NH — in which case it would behave as AE 2 (non-link-local IPv6).

   In this case, we have to consider the state of the protocol.

   When parsing an IPv4 address, if `omitted != 0`, we use a stored
   prefix from previous TLVs for compression. This prefix cannot be
   reused with this new AE to preserve backwards compatibility. Indeed,
   a v4-over-v6 TLV might change the v4 compression prefix. Yet, this
   TLV will be ignored by any older implementation of babel, thus
   breaking the protocol state.

   However, we see no such argument that would prevent us from reusing
   the AE 2 (IPv6) next-hop. We this have two options:

   (ii)  either we use as a next-hop the address from the latest AE 2 NH
         TLV, if any, or the link-local address of the neighbour
         otherwise;
   (iii) or we use a distinct state to store NH TLVs for this new AE: we
         use as a next-hop the address from the latest NH TLV with this
         new AE, if any, or the link-local address of the neighbour
         otherwise.

Here, backwards compatibility is especially important to take into
account, since we are not only considering the case where a router is
using an old version of Babel, but also the case in which the host
system of a router does not support v6-over-v4 routes.

So far, we are more inclined to choose option (iii).

We prefer (ii/iii) over (i), because option (i) does not signal clearly
in any way that an extension of the protocol is being used, and might
confuse older versions. We also believe it is easier to understand,
debug and trace, and comes at a price of only a small overhead wrt.
(i).

Between (ii) and (iii), Juliusz is in favour of (iii), since option
(ii) mixes reuse and separate state in a weird way, and might be
confusing. I do not have yet a clear opinion on this, but I am inclined
to agree with him.

Any opinion on this choice is appreciated!


In the current experimental version, I implement this using AE 4, but I
will change it very soon to AE 240 to ensure this experimental version
does not break any future production implementation if this ID is fine
for everyone — see the previous mail from Juliusz regarding this.


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d15662682db232da77136cd348f4c9df312ca6f9

Best regards,
-- Théophile