Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward.
My question for this list is basically, has anyone noticed or fiddled with babel? It's supported in FRR, bird, and a very small standalone daemon. Anyway, after babel hit the ietf, development slowed down a lot, but along the way some useful innovations were made, notably a RTT metric, "source specific routing" for ipv6, HMAC authentication, and most recently, Juliusz's announcement of V4-via-v6 hit the git babeld codebase. To recap that: "V4-via-v6 routing is a routing technique that allows routers with only IPv6 addresses (including link-locals) to forward IPv4 packets. It doesn't involve encapsulation (tunnelling), it doesn't involve translation (NAT), it just works. For details, please see https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6 Short story: v4viav6 is enabled by default if your linux kernel is recent enough. Just upgrade babeld to current master, and you should see your v6-only routers forward IPv4 packets. In order to disable announcing of v4-via-v6 routes, add the following to your configuration file: default v4-via-v6 false Long story. There are two pieces to v4-via-v6: installing IPv4 routes with an IPv6 next hop, and announcing such routes. By default, babeld will: - install v4-via-v6 routes on Linux 5.2 and later; - announce v4-via-v6 routes on Linux 5.13 and later. (backports are available for various stable versions) The former behaviour cannot be overridden -- we always install v4-via-v6 routes if the kernel supports them, and (obviously) never do otherwise. The latter behaviour can be overridden by the interface option 'v4-via-v6'. Feel free to experiment, but be aware that enabling v4-via-v6 on an older kernel might create ICMP blackholes. Please let me know if you feel that it should be possible to completely disable v4-via-v6 even on newer kernels, and whether you feel that v4-via-v6 should be disabled by default. (The "Security Considerations" section of the draft cited above might be interesting.)" Enjoy, -- Juliusz Juliusz Chroboczek via alioth-lists.debian.net Thu, Mar 31, 3:30 PM (3 days ago) to babel-users, Théophile On Fri, Apr 1, 2022 at 2:17 AM Pascal Thubert (pthubert) via NANOG <nanog@nanog.org> wrote: > > A very long thread. > > Face it: everyone is right, and even technically correct. There's no good and > evil. We'd know, after 20 years. > > I live in France and my country has a famous 100-years war in its long > history with England. Do we want to beat this here? > > The plain truth: > > - IPv4 is here to stay. Some v4-only nodes and functionalities are here to > stay. Plenty of reasons for that in this thread. > - IPv6 is unavoidable. New devices like phones and IOT need it, many IPv6 > only in that space, numbers only growing > > > The things everyone agrees upon: > - Dual stack everywhere and forever is the worst of both worlds as it doubles > every cost, and that will remain long as the war rages > - Stateful NATs the size of the Internet not doable, which in my book says > that isolation not only unavoidable but already there. > > An the illusions: > > - any-to-any is required. In particular, any IPv4-only to any-IPv6 only. I'm > not talking security but plain functionality. And yes, exceptions if they are > few can be handled by expensive stateful NATs when the cost is justified > - the Internet is a big homogenous thing. The more it expands, the more we > see domains forming where specific capabilities are deployed, and because we > fail to handle that at L3, we mask the functionalities above UDP. > > If we agree on the above then a compromise is possible. Ideally, the > compromise would: > - maintain the current state of v4 affairs for those who want that > - scale v4 addresses for those who want that > - provide v4 to v6 stateless NATs for this who want that, and > - allow networks to be either of the 2 versions for those who want that. > > SciFi? There's a proposed starting point for that compromise in the yada-yatt > draft published at IETF v6ops. The key is to use baby steps between locations > (in the transition plan) where people can be at ease and stay as long as they > want to, as opposed to enforcing a giant zero-to-hero illusionary step. > > Are you ready for that, or should we wait another 80 years with dual stack > and gigantic stateful NATs? > > Pascal > > > > > -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
