Hacker News Reader

Comment by guardiangod | Hacker News Reader

>0/8, 127/8, 224/4, 240/4

Why would anyone even bother. All the scripts and programs that were hardcoded to treat 127/8 as loopback and 0/8 as various default routes would need to be changed and more importantly, verified. You wouldn't want anything that's hardcode bind to, say, 127.48.47.218 as localhost to suddenly be routable from the internet.

I vaguely recall Cloudflare uses a huge chunk of 127/8 as internal loopback addresses for their edge servers. Without Cloudflare's support this proposal is DOA.

View on HN

John Gilmore (who founded this project and whom I've been consulting for on it) has talked about this in the current NANOG mailing list thread about our proposals. He has several posts there, but the most relevant to your specific comments is probably

https://mailman.nanog.org/pipermail/nanog/2021-November/2164...

Let me perface this by saying thank you for being sincere and civil, because what I am about type might not be up to the standard you established.

I read that email and there's a serious tons of hand waving and 'dude, trust me.'

I am going to ignore "would be useful to a lot of people -- hundreds of millions of people who you may never know." There's no example use case of who the hundreds of millions of people might be, and how this proposal would benefit them. What are the benefits that the existing CG-NAT and ipv6 couldn't provide?

I am also going to ignore "one-line patches is almost risk-free." Sure if all the software in the world is only Linux/Windows/BSD TCP/IP stack and no one build anything on top of the stacks, then the patch would indeed be only 'one -line'.

What I really have a problem is 'simply include them in new releases of the various operating systems and router OS's that implement the Internet protocols.' I work for a _major_ hardware firewall company, and it is ridiculous the amount of effort we would put on our customers to upgrade their firmware. There are still hardware that run with 15 year old firmware (with all the accumulated CVEs). You are telling me it's easy to convince these people to upgrade their stuff? Are you serious??? 'People naturally upgrade their OS's every few years." Oh I guess we can ignore all the IoTs and middle-boxes on the interweb then.

"We have tested major routers, and none so far require software updates to enable most of these addresses." As mentioned I work for a firewall company. I just logged into a sample firewall under my control- yes the configuration is doable. But in enterprise, everything needs to be rigorously tested or else the sysadmin's not gonna touch it. The sysadmins are certainly not going to waste a few weeks of their lives testing things that might bring down their entire network, and would only benefit the select few who managed to grab ahold of the new IPs.

It's late at night and I don't want to continue. So here.

Adding on to this, the claims seem actively contradictory: it wants us to feel for the millions of people who never got IP addresses (they were late to the internet for whatever reason) but also thinks that they will upgrade on the drop of a hat. Like, these people are using Windows XP and Android KitKat: that’s all they can afford. It seems wrong to present this change as being for them and in the next ask for them to do something that is out of their reach.

I agree. If updating were so easy, we could all just switch to IPv6 tomorrow and be done with all of this.

This whole IPv4 address mining thing is only relevant because updating is hard.

People who use Windows XP and Android KitKat today can't connect to most sites anyway due to TLS 1.2, I doubt they're relevant to any discussion.

> People who use Windows XP and Android KitKat today can't connect to most sites anyway due to TLS 1.2

...if they use the Windows built-in SSL stack. For instance, Firefox has always used its own SSL stack (NSS) everywhere; and AFAIK, the last version of Firefox which was compatible with these systems already worked fine with TLS 1.2. The same for root certificates: Firefox uses its own CA roots (from NSS).

Firefox stopped supporting XP since Firefox 52.9 ESR which did not have finalized TLS 1.3 support. That's kicking the can down the road a bit longer than TLS 1.2, but not much longer.

See my comment in the other thread. Basically, Windows XP / Windows Server 2003 and other OSes of that vintage still probably drive a good portion of industrial machines. For example a new and modern dentist office, with top of the line equipment had to buy a used panoramic x-ray machine. It makes sharp images, it runs on a separate network and only talks to the NAS - so it is quite decoupled. It works really well but it runs Windows XP. I noticed when I was there, that is how I know all this. In this case, the unicast extension doesn't really apply but it could be other Windows XP machines connect e.g. over a VPN somewhere perhaps in the public cloud. The machine doesn't listen on any port on the public IPs it has... until one day, it can't connect to the VPN endpoint for some reason, because it is in the 0/8 or 127/8 range or whatever.

You have to consider it, it is still millions of devices potentially flooding the new addresses, causing major security holes in legacy networks and a lot of maintenance burden. It is a dream/ nightmare come true for support companies and contractors depending on who you support.

These XP/2003 devices should be isolated behind a million firewalls and perferably not connected to the internet at all. If these devices can't route to some portion of the net which they shouldn't have been connected to in the first place, that's hardly a loss.

* Personally I think 240/4 is very reasonable since it was always reserved, 0/8 is doable but would require effort enough people might not want to do, and 127/8 is hardcoded in too many places and isn't doable. IPv6 is the future, but it isn't justified to make things now worse to make deployment faster (it won't be). IPv6 will win by default anyway.

I am absolutely with you. At least unsupported Windows versions should be eradicated where at all possible. Sadly, this isn't the reality we live in as I described at length.

Only including 240/4 and parts of the multicast space perhaps in the unicast extension would most likely minimize the impact to potential legacy use-cases and setups and be the 80/20 kind of compromise.

How about a Windows XP VM which can only talk to the NAS?

Not certified I guess. Remember, medicine. :-)

In practice, VMs on PCs for non-technical personnel are a major pain. All kinds of stuff breaks in curious ways e.g. the pass-through of the protocol or the specific interface might not work reliably, there is a custom setup to support, some pop-up causes the windows to overlap in a way that makes it hard for the medical personnel to get going quickly yadayada. Yes, you can do snapshots and other stuff.

Also, the technicians setting this up are usually not trained in IT DevOps/ broad sysadmin tasks so much as in the setup of special medical devices. They also tend to cost a small fortune, because again, they are certified to work on those machines costing on the order $100000 when used and multiple that when new and there might be a handful of them for the whole region. In this particular case, as a patient you also don't want more x-rays than you absolutely need to get. Doing a panoramic x-ray multiple times because e.g. of some software failure could breach some daily/ monthly whatever irradiation limits so you would need another appointment etc. Not something you want to go through as a responsible doctor because of some custom setup.

I get it, I am also enthusiastic about Windows never touching bare metal if at all possible for long running professional stuff precisely because of snapshots and e.g. the possibility to cut the network remotely and bring it back up if needed. But I also come in contact with non-technical folks that don't want to risk stuff, deal with more stuff than they already deal with etc. I respect that, it is an approach that works for them.

OpenSSL works on windows xp.

The same people who never ever update their 20 year install have installed software which uses modern(ish) OpenSSL? That's very unlikely.

Besides, since XP doesn't install IPv6 support by default (and these people never update), we should ditch IPv6 too?

No one wants to be bound by 20 year old never updated installs of ancient OSs, so let's not.

There's windows 7 too :)

Also out of support, unless you have ESU.

I think that if Microsoft ever does decide to support this extension there'll be a patch for all supported versions including via ESU - just like all supported relevant MS products got a TLS 1.2 patch, even the embedded Windows XP (POSReady 2009) got a TLS 1.2 patch.

This address shuffling is not a security patch, so would have near zero priority.

> What are the benefits that the existing CG-NAT and ipv6 couldn't provide?

CG-NAT is nasty: you can't be reached from the Internet and (this is the more important thing) IP-based rate limiting or activity tracking (think of stuff like Wikipedia and anonymous edits) don't work any more.

IPv6 adoption has been ... sluggish by any measure, I remember playing around with sixxs ~2010ish, and there still are providers that don't hand out native IPv6!

> and there still are providers that don't hand out native IPv6!

There's still a lot of Linux' that can't handle IPv6 handed out by their ISP as well, for example systemd-networkd got working PD support that's at best a few years old (so only in the latest LTS releases of Ubuntu for ex.).

I think we're now at the hardest 20% to fix and deploy, that 20% includes humans as well.

He is thoughtful and states his case well, but these two assertions make no sense alongside one another:

But it would be useful to a lot of people -- hundreds of millions of people who you may never know.

Microsoft Windows is the biggest laggard; they drop any packet whose destination OR SOURCE address is in 240/4.

We can assume he's not talking about mobile users: they can and usually do get IPv6 addresses. We can assume he's not talking about all the endless servers and so on talking to one another, those aren't "people." He's talking about hundreds of millions of PC users.

Hundreds of millions of PC users, except Windows users. How is that going to work?

It'd be fun and ironic to pick on Microsoft for adhering too closely to established open standards, but unless I'm missing something here, they've got a veto over implementation of these ideas.

But then how does one ensure 127/8 are local?

Routing (static or dynamic routes depending on the network setup), firewall + /etc/hosts depending on what you try to do exactly. There would probably be some guidance on how to support the old behaviour consistently in legacy networks.

I might as well create an ip6 loopback network that way. 127/8 is used because it already exists.

How many projects realistically code for 127 outside of 127.0.0.1, how many code in 0.0.0.0/8 outside the /0 default?

I'd be interested in the CF example if there is a doc.

Lots of 127/8 outside of 127.0.0.1, both for development (running multiple services on conflicting ports) as well as for production use (either due to port conflicts, or simply ease of use if you stick to default port when, for example, setting up multiple DNS servers (to separate recursive resolver and authoritative server).

I recall a lot of use in routers as well, but haven't personally used those setups.

a ton of routers (think, high end access or core platforms) use "unroutable" ip space for internal communication between different systems in the router.

These are hardcoded addresses used in the backplane of the system, and changing them would be incredibly difficult because usually:

- these routers have multiple forwarding and control plane systems for redundancy purposes, and upgrading them all at the same time is usually not feasible. (remember, these system are build redundantly because you want no downtime on a core router).

- Some of these prefixes are used for constructs inside the routers (virtual interfaces between forwarding planes for instance). This might be called ugly, but it is the way it is. and changing that is near impossible.

This reminds me of how RFC1918 address space is supposed to be "never connected to internet" (including NAT, because when it was written NAT would have violated basic host requirements).

And some computers abused the hell of it, for example Digital/Compaq Alpha EV7 "Marvel" line, where each processor had its own address in 10/8 subnet and essentially equivalent of BMC controlled the computer through 10mbit ethernet linking all components

One example I can remember right now: systemd-resolved which binds to 127.0.0.53. (if that's what you're asking about)

A very good overview, aside from these proposals, of the problems that internet addressing has developed over the years was also presented at the same working group meeting.

https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios...

This should also be a candidate for careful extrapolation:

https://www.larus.net/blog/IPv6_adoption_then_and_now

Reply on news.ycombinator.com