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? -Toke
