Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: IPv6-only still pretty much unusable

news.ycombinator.com

Post reply on HN
Print view View original

361–370 of 649 posts

Re: Tell HN: IPv6-only still pretty much unusable

#361

Post by SoftTalker »

293984j29384 wrote: post #295
derefr wrote: post #174

Earlier quoted context omitted.

What makes you think that, for critical systems, "IPv4 + NAT + bad firewall" is the default IPv4 deployment paradigm, rather than "IPV4 + bad firewall"? Sure, big IaaS providers like AWS put you in a VPC by default. But most servers on the net are not hosted in an IaaS; they're hosted using a VPS or bare-metal hosting provider, or just coloed in a DC by their owner. And in all those cases, what that kind of deploymen…

While I don't have any factual proof to refute your statements, in my personal experience almost every organization uses NAT & RFC1918 address space. The only client I can think of in my 20 years of experience that used a public IPv4 per VM/machine was the DoD, specifically, the U.S. Army. From your very last statement, I think you've confused self hosting (like buying a VPS from Digital Ocean and hosting your own bl…

Big universities (at least in my experience in the USA) are the other ones that would have a public IP address for every device, at least until rather recently. They were online very early and got allocated huge blocks of addresses, before anyone really imagined future scarcity.

Re: Tell HN: IPv6-only still pretty much unusable

#362

Post by Dagger2 »

LinuxBender wrote: post #317
noipv6 wrote: post #227

Earlier quoted context omitted.

> I could see doing IPv6+IPv4 in a corporation and terminate everything on load balancers, allowing anything behind the LB to be any combination of IPv4/IPv6. But IPv6 only? I don't see any big companies doing that in my lifetime. facebook started migrating to ipv6-only datacenters in 2014 or so. i think all of them are converted at this point. they only support legacy ip at their network edge, & use siit (iirc) to f…

The legacy IP at their edge is what I meant by terminating IPv4+IPv6 at the load balancers. The tricky part is that almost all datacenters today need to talk out to other datacenters. Not all of them use IPv6 which means they will still need some way to speak IPv4 until all their 3rd party data processors are also doing IPv6 and for Facebook I happen to know that is a lot of 3rd parties. If they are truly IPv6-only i…

You can do that with NAT64, which you can run as a service in your datacenter rather than needing to deal with v4 throughout it. (In fact it doesn't have to be run in your datacenter -- it could be outsourced to somebody else, which will probably make sense eventually as v4 use dwindles.)

Re: Tell HN: IPv6-only still pretty much unusable

#363

Post by AnIdiotOnTheNet »

CountSessine wrote: post #313
throw0101a wrote: post #300

Earlier quoted context omitted.

> I would switch to that "IPv4+" system if it existed.. I am willing to use latest software/standards to future-proof my setup, but duplicating all the work is too much for me. And exactly how would you accomplish this switch to a larger address space? Please explain the steps exactly how they would be done. Because IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How exactly do you fit in…

In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan. OR Maybe you don’t use those 96…

Couple things:

1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets.

2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.

Re: Tell HN: IPv6-only still pretty much unusable

#364

Post by Dagger2 »

_8j50 wrote: post #141

My take is that they should have used alphanumeric addressing. You could have addresses like company:office:laptop and it shouldn't have reinvented arp and dhcp or added more complex routing like anycast or link local. It tried to solve too many problems at once.

You're thinking of DNS, which... we already have.

v6 actually changed very little from v4. It more or less works in exactly the same way v4 does.

Re: Tell HN: IPv6-only still pretty much unusable

#365

Post by bauruine »

cranekam wrote: post #329
tlb wrote: post #277

Earlier quoted context omitted.

I'm not up to date, but when I knew about this stuff the cost of memory for routing tables was only a tiny, tiny fraction of the cost of a network. Most of the cost is burying and maintaining fiber. So unless something big has changed, it seems like a terrible choice to twist the whole system into uselessness to try to save a small amount of RAM cost.

According to this Stack Exchange post from last year a full IPv4 routing table requires on the order of a few hundred MBs of RAM. This is indeed a tiny fraction of the cost of maintaining the global internet infrastructure. https://networkengineering.stackexchange.com/questions/76562...

The problem is that the routers that have to hold the routing table can only handle a limited number of routes. There is a good article from APNIC about the topic.

https://blog.apnic.net/2021/03/03/what-will-happen-when-the-...

Re: Tell HN: IPv6-only still pretty much unusable

#366

Post by lee101 »

I just like to call out Starlink for not supporting ipv6, massive headache as calls to various ipv4 only sites fail in python then you need to set a timeout in your request to trick python into falling back to ipv4, also no public adresses on Starlink made self hosting https://text-generator.io a pain but CloudFlared tunnels helped

Re: Tell HN: IPv6-only still pretty much unusable

#367

Post by salmo »

anthropodie wrote: post #262
throw0101a wrote: post #164

Earlier quoted context omitted.

> And regarding compatibility, with ipv4+ if you have a 0.0.0.0.x.x.x.x ip address you would be able to talk to both ipv4+ aware and legacy ipv4 devices natively without any tunneling (because you also own the legacy, non quad 0 ip address). This exists: > Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For…

> What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6? I'm pretty sure that those who built new protocol were aware of this and were like "anyway we are gonna have to upgrade network devices. Why don't we build a new protocol while avoiding pitfalls of older one" Any comittee that sat down to solve IPv4 issue would have thought of compatibility first. I…

They took much more on with IPv6 than IPv4 replacement. The spec goes much deeper than IPv4 did, replacing ARP, DHCP, etc. It's a product of its time, including a lot of over-engineering by committee. Many of the problems they tried to address didn't pan out to be real issues. You can read the RFCs and compare.

IPv4 w/ more bits is a lot more simple. Yes, older network gear wouldn't deal with it well, but that's not a real issue today because that same network gear supports IPv6.

Buuut, one of the biggest problems with app-level issues is just that the app doesn't bother dealing with IPv6 addresses and AAAA records. It would be the same issue with an imaginary IPv4*2.

Re: Tell HN: IPv6-only still pretty much unusable

#368

Post by alexfromapex »

I think it's the format of the numbers that's not user-friendly enough. They can be too long to remember and my first thought is that there should be a clever algorithm to use "catchy names" or words and then map them to the numeric values. Could even down-sample the names/words that need remembering and then up-sample them to the full numeric range behind the scenes to help add a larger range of values.

Re: Tell HN: IPv6-only still pretty much unusable

#369

Post by tinglymintyfrsh »

There are large swaths at work that are IPv6 only. There is a proxy to work with things like Github that don't do it.

Ideally, every OS and device should be able to do IPv[46] only and dual-stack.

IoT stuff has the most problems where they're 2.4 GHz and IPv4 only.

Re: Tell HN: IPv6-only still pretty much unusable

#370

Post by anyfoo »

AnIdiotOnTheNet wrote: post #363
CountSessine wrote: post #313

Earlier quoted context omitted.

In theory this could be handled by stuffing the extra 96 bits in an IP extension header. But this solves nothing because then any switch that isn’t IPv4+ aware will route packets incorrectly. Literally every single switch on the internet needs to be updated/replaced before you could start generating IPv4+ traffic otherwise the one outlier will send your IPv4+ packets off to Uzbekistan. OR Maybe you don’t use those 96…

Couple things: 1) Instead of stuffing the extra 96 bits in an extension, you stuff all 128 in the extension and use a reserved unrouted address in the v4 header field. Devices with no clue will just drop those packets. 2) Pedantically, switches are layer 2 devices. Some some of them act as routers also, but only routing is relevant.

Devices with no clue of IPv6 also just drop those packets. What have we gained?

The only thing I can imagine is that while you still need to alter or replace every piece of equipment on the net, software adoption would likely have been much easier and thus immediately higher if 128 bit addresses were the only change (I still don't see the benefit of tucking it in as a field into IPv4, but if IPv6 was just IPv4 with wider addresses), and all the other protocols and semantics that were changed with IPv6 stayed the same. But arguably, since you do need to change every piece of equipment, this was the time to make desirable, fundamental, not-backward compatible changes, and possibly the only opportunity at that.

Post reply on HN