V4 via V6 and IGP routing protocols

Sun Apr 3 11:55:36 UTC 2022

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 at 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