Ondrej Zajicek <[email protected]> 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
