[PATCH] Babel: add RFC9229 (v4 via v6) support

[Andreas Rammhold]

Ondrej Zajicek <santiago at crfreenet.org> writes:
> Just few random notes:
>
> The RFC says "ordinary IPv4 announcements are preferred to v4-via-v6
> announcements when the outgoing interface has an assigned IPv4 address",
> but there is also the third option - using an IPv4 address from another
> interface as a next hop.

Are you proposing letting the administrator selecting an IPv4 address
for that case? I don't know how this could work reliable in an automated
way.

Imagine a situation where you have three routers connected like so:

Router 1 <-- IPv4 --> Router 2 <-- IPv6 --> Router 3

Router 1 and Router 2 have an IPv4 link, Router 2 and Router 3 don't. In
your scenario would Router 2 send packets to Router 3 with the IPv4 next
hop from the Router1<>Router2 link?

> What happens if route is announced with IPv6 next hop and the
> interface later?

You mean what happens if an IPv4 (or IPv4+IPv6) connection transitions
to being just an IPv6 link?

Let's look at this example with two machines that are connected via both
IPv4 and IPv6 and have v4-via-v6 enabled:

On the first machine called "kappa":
>kappa# birdc show babel interfaces "wg-bertha"
>wg_backbone:
>Interface  State  Auth  IPv4 via Ip6 RX cost   Nbrs   Timer Next hop (v4)   Next hop (v6)
>wg-bertha  Up     No    Yes               96      1   1.399 192.168.0.2 fe80::12

On the second machine called "bertha":
>bertha# birdc show babel interfaces "wg-kappa"
>wg_backbone:
>Interface  State  Auth  IPv4 via Ip6 RX cost   Nbrs   Timer Next hop (v4)   Next hop (v6)
>wg-kappa   Up     No    Yes               96      1   2.603 192.0.2.1 fe80::1

"kappa" has the address 172.20.25.12/32 on a loopback interfaces and is
announcing that to all its babel neighbors.

Since the link between the two machines has both IPv4 and IPv6 available
the code prefers IPv4 (as it should do). Bertha learns the IPv4 next hop:

> bertha# birdc show babel routes | grep 172.20.25.12/32 | grep kappa
> Prefix                   Nexthop                   Interface Metric F Seqno Expires
> 172.20.25.12/32          192.168.0.2               wg-kappa      96 * 1  50.130

In the event that the IPv4 address goes missing from the link. The route
will fail over to an ipv4-via-ipv6 route after a couple of seconds:

> kappa# ip addr remove 192.0.2.2/24 dev wg-bertha

> bertha# birdc show babel routes | grep 172.20.25.12/32 | grep kappa
> 172.20.25.12/32          fe80::12                  wg-kappa      96 * 1  53.360

And in my case that is also properly reflected in the kernel routing table:
> bertha# ip route get 172.20.25.12
> 172.20.25.12 via inet6 fe80::12 dev wg-kappa src 172.20.25.4 uid 0

The IPv4 source address selected here is configured via `krt_prefsrc` in
my bird configuration. It would work without, but traceroute wouldn't be
as readable.

If the IPv4 address reappears on the interface between the two the next
hop will be updated to the IPv4 address again.

Does this answer your question?

> What do you think about changing the option name to 'extended next hop',
> like the equivalent BGP option? On the one hand, it improves consistency
> within BIRD, on the other hand, 'v4-via-v6' is used by the RFC.

My personal preference would be to stick with the babel
terminology. Other babel implementations (e.g. babled) are using the
same wording. I imagine that someone interfacing with other
implementation is going to be happier about the protocol-level flags
being consistent within the protocol (across devices) rather than having
consistency with BGP (which they might not have knowledge in any way).

Correct me if I am wrong but only Juniper and BIRD have picked up
`extended-nexthop` as an option whereas e.g. Cisco went with something
different. I recall these inconsistencies across devices (while staying
within the same protocol) to be annoying, but I haven't been involved in
any commercial networking for some years now.

I'll *not* die on this hill if you think that consistency within BIRD is
more important from your perspective. :)



Andi