On 17:51 15.12.20, Toke Høiland-Jørgensen wrote: > Andreas Rammhold <[email protected]> writes: > > > On 13:05 15.12.20, Toke Høiland-Jørgensen wrote: > >> Andreas Rammhold <[email protected]> writes: > >> > >> > This is a first attempt at implementing draft-ietf-babel-v4viav6-00 as > >> > IPv4 via IPv6 extension to the Babel routing protocol that allows > >> > announcing routes to an IPv4 prefix with an IPv6 next-hop, which makes it > >> > possible for IPv4 traffic to flow through interfaces that have not been > >> > assigned an IPv4 address. > >> > > >> > I've tried my best to be compliant with the current RFC version. One > >> > point that is not entirely clear is how to implement in section 2.2. > >> > regarding fallback when the device doesn't support v4-via-v6 routes. > >> > (See notes below) > >> > > >> > The implementation is compatible with the current Babeld PR > >> > (https://github.com/jech/babeld/pull/56). I've verified this with a few > >> > VMs in the following setup: > >> > > >> > Bird <- v4 only -> Bird <- v6 only -> Babeld <- v4 only -> Babeld > >> > > >> > Each routing daemon was running on their own VM and had L2 connectivity > >> > to only its direct neighbors. At the nodes at the edges v4 networks have > >> > been announced and full end-to-end communication was possible over the > >> > mixed AF network. The v6 only link between Babel and Bird (at the > >> > "center" of the above setup) did transport the v4 packets via the v6 > >> > link-local next hop addresses just as expected. > >> > > >> > Thanks to Toke Høiland-Jørgensen for early review on this work. > >> > > >> > -----< notes >------ > >> > > >> > (My current notes on the current implementation regarding > >> > compliance with the current draft) > >> > > >> > Bird doesn't implement compression for outgoing (send) IPv4 prefixes and > >> > thus this also hasn't been implemented for this AE. Best guess is that 4 > >> > bytes are cheap enough to not bother with the added complexity? In the > >> > RX path compression is supported for IPv4 prefixes (for the IPv4 AE > >> > as well as for IPv4-via-IPv6 AE). > >> > > >> > Especially the part last paragraph of 2.2. remains to be > >> > discussed/solved: > >> > > >> > * If a node cannot install v4-over-v6 routes, eg., due to hardware or > >> > software limitations, then routes to an IPv4 prefix with an IPv6 > >> > next-hop MUST NOT be selected, as described in Section 3.5.3 of > >> > [RFC6126bis]. > >> > > >> > * What if the kernel doesn't accept the RTA_VIA value we gave it? > >> > Does BIRD generally handle this already? > >> > One example is hitting: "ipv4: use IS_ENABLED instead of ifdef" > >> > (id:[email protected] @ linux-netdev) Where > >> > the kernel does support it but due to a bug fails to add those routes > >> > when CONFIG_IPV6=m. > >> > Kernel version comparison is probably a bad idea. Which kind of route > >> > can we attempt to install to test this functionality without breaking > >> > any setup? > >> > >> Can't we just have Bird do the equivalent of: > >> > >> ip r add 192.0.2.1/32 via inet6 ::2 dev lo onlink > >> ip r del 192.0.2.1/32 via inet6 ::2 dev lo onlink > >> > >> on startup, and set a system flag depending on whether the operation > >> fails or not? > > > > That could work. I am not happy to use the documentation prefix for this > > but I am also not aware of any other subnet that might be better suited > > for this task. If someone is using the documentation prefix they will > > probably not like this tho (but that is hardly our fault…). > > Well, just used it as an example of something that was not likely to be > in use; could be anything, really. Maybe you can even use 127.0.0.1/32 > on lo without any ill effects?
That sounds good and doesn't appear to have any noticeable side effects while the route is installed. I'll have to see where in Bird such a check could be added.
