The Reg does 240/4

Tue Feb 13 07:39:55 UTC 2024

On Tue, Feb 13, 2024 at 2:18 AM Jay R. Ashworth <jra at baylink.com> wrote:
>
> ----- Original Message -----
> > From: "Dave Taht" <dave.taht at gmail.com>
>
> > The angst around ipv6 on hackernews that this triggered was pretty
> > revealing and worth thinking about independently.
> > https://news.ycombinator.com/item?id=39316266
>
> Thanks; the source where I got the other link mentioned that, and I meant
> to include it...
>
> > I was inspired to try a couple traceroutes. It used to be 240 escaped
> > my prior comcast router and wandered around a while; it does not do
> > that anymore. I would be dryly amused if that box was actually running
> > my old OpenWrt bcp38 stuff which blocked 240 for a couple years. My
> > cloud works, my aws stack works, openwrt works.
>
> Damn; I haven't touched the bcp38 wiki in some time.

In what way do you plan to touch it?

> Thanks for the reminder.

The bcp38 code for OpenWrt was not updated in light of the nftables
switch, as of a few years ago, but I have not looked at it in a long
time. Maybe someone else fixed it. I have not been doing much
development.

As it is bcp38 needs to be applied carefully by an ISP given the
sordid mess of other rfc1918 addresses along the path nowadays.

I doubt it is a good idea for consumer devices anymore. I liked the
side-effects of running it then tho, stopping random worms for chewing
up my external bandwidth. (the code was not just bcp38 related)

A plug - that I have NO IDEA made it into other ipv6 implementations -
is that we put ipv6 source specific routing into the OpenWrt stack to
elegantly make bcp38-like behavior the default there, back in 2013.

ip route add :: from my:ipv6:address:ranges/mask dest:addr:of:your:choice.

And also made the idea work in babel and ISIS to help with poor man´s
multihoming.

Most distro kernels I have seen lately do not seem to support "from" anymore.

>
> > Peering into a murky crystal ball, say, 5 years in the future:
> >
> > Another thing that I worry about is port space exhaustion, which is
> > increasingly a thing on firewalls and CGNs. If I can distract you - in
> > this blog cloudflare attempted to cut the number of ipv4 addresses
> > they use from 2 to 1, after observing some major retry issues. With a
> > nice patch, reducing the problem.
> >
> > https://blog.cloudflare.com/linux-transport-protocol-port-selection-performance/
>
> Interesting.  Isn't that something CGNAT implementers would have had to deal with
> already?

I do not know of a single CGNAT that gives an operator a report on syn
retries, and thus exhaustion is hidden by the native retry behaviors
of the host stacks. Is there one?

The cloudflare work seems helpful here.

>
> > Peering further into the soi-distant decades ahead, perhaps we should
> > just allocate all the remaining protocol space in the IP header to a
> > quic native protocol, and start retiring the old ones.
>
> Well, I've been able to avoid thinking about it for some time, but ISTR my
> reaction to QUIC as violating a number of organized religions' blasphemy
> rules...
>
> > /me hides
>
> Indeed.

I enjoy being offline ever the more, these days. The internet
addiction level out there has become rather depressing.

https://www.linkedin.com/feed/update/urn:li:activity:7162457657210044416/

>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274

-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos