Re: [babel] Babel v4-over-v6 extension

[David Schinazi <[e-mail]>]

Nice work, and welcome to Babel, Théophile!

I think I also have a slight preference for (iii), as it's
easier to reason about and to prove that it won't cause
issues for nodes that don't support this feature.

David

On Fri, Mar 13, 2020 at 1:09 AM Théophile Bastian <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel
>