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