Live data from Hacker News

Tell HN: IPv6-only still pretty much unusable

news.ycombinator.com

571–580 of 649 posts

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

#571
post #157

Earlier quoted context omitted.

One of the ideas of ipv6 was to reduce routing tables, those tables that backbone providers have to keep in memory and look up for incoming traffic. With ipv4's fragmented allocation scheme, these routing tables are huge. With ipv6, even huge companies like amazon only have a couple of global allocations. A "ipv4 with more octets" scheme would have kept that fragmentation around. That being said, Amazon currently has…

> One of the ideas of ipv6 was to reduce routing tables That idea was abandoned about 20 years ago. One fairly quickly discovered that hierarchical routing does not work well in the real Internet, where redundancy is done on the IP level with everybody and their dog having provider-indepent IP space. > like that the only standard for local ipv6 addresses Which one is the only standard? Link-local, site-local, ULA, or…

site-local addresses are deprecated since RFC 3879. Link-local addresses are indeed another standard, but have the very same length problem. You have these horribly long ipv6 addresses... those can't reasonably be parsed by humans... There is no 192.168.* equivalent in ipv6. Why don't we have something like fd00::1 being the router and fd00::2, fd00::3, etc being the devices in the local network, assigned by DHCP. You can absolutely configure your router that way but it is violating a MUST requirement of RFC 4193. That's my point. There is no non-routed netblock where you can just use it for local purposes, outside of the one for SLAAC and the one for ULA, both creating these horribly long monsters of addresses. All the others have purposes attached that are not meant to be used for local networks.

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

#572
post #157

Earlier quoted context omitted.

One of the ideas of ipv6 was to reduce routing tables, those tables that backbone providers have to keep in memory and look up for incoming traffic. With ipv4's fragmented allocation scheme, these routing tables are huge. With ipv6, even huge companies like amazon only have a couple of global allocations. A "ipv4 with more octets" scheme would have kept that fragmentation around. That being said, Amazon currently has…

Amazon is really not a great example, I don't think. The giant cloud providers are outliers with respect to DFZ announcements, as they have many, many POPs and also allow their customers to announce address space. They're more like transit networks at this point than what could be reasonably considered a representative end user. More reasonable to look at announcements per AS, where it's currently about half of IPv4,…

So Amazon with its 3-fold ratio is in fact giving a better argument for ipv6 than the average, nice. Generally a factor of two doesn't say much about ipv6 creating less allocations at all, given how ipv6 is roughly within a factor of two in terms of adoption in general.

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

#573
post #345

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…

Or you extend on network level, and even kernel level, but keep programming API compatible. I don't think people like IPv4 packets that much, it is all the APIs which are giving problem. I bet if we kept everything about IPv6 the same, but (1) made IPV6_V6ONLY mandatory and default to zero (2) did not use colon in IP address representation (3) recommended firewalls use same config rules for IPv4/IPv6 address.. then I…

On Windows firewall matches ip4 and ip6 with the same rule. The address field there isn't numeric, but text, and can be ip4 address, ip4 network, ip6 address, ip6 network, address range, gateway or "any". Most rules specify "any" for addresses and focus more on ports, application paths and subprotocols like TCP/UDP.

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

#574
post #448

Earlier quoted context omitted.

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.

No, ipv6. Could have eliminated the need for DNS in a LAN. There is no reason to use hex other than maybe it would be easier for control planes to translate config to bytes/asic? But that's only when a config changes. Routing and forwarding uses bits and bytes, the hex is just one of many ways they could have chosen to represent the bytes. Defining prefixes in alphanumeric and how that translates to bytes could have…

That could actually work for the host ID part of the address (not so much the network part). You could do it today with v6 just by extending getaddrinfo() (e.g. with an NSS plugin on Linux).

But L3 addresses aren't the place for naming. They're meant for computers, not humans. DNS supports names longer than 2-8 characters, descriptive hierarchies, multiple address families, other useful info types like SSH keys, and in general operates at the right layer for it.

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

#575

Earlier quoted context omitted.

> NAT punching does require cooperation of programs on the protected machines As does listening to a port. > And is it any different from a stateful firewall on IPv6? Hum, not much. And that's the point, all of those are basically the same. NAT doesn't give you much security, and NAT without a firewall usually gives you less security than a firewall, since NAT usually is configured for connectivity, and a firewall fo…

> > NAT punching does require cooperation of programs on the protected machines > As does listening to a port. Listening on a port is for incoming connections, exactly the kind that we're blocking with either a (stateful) firewall or NAT. Listening on a port is a declaration of a program (a server) to communicate with whichever counter party can connect to this port (until the server program decides to close the conn…

The point here is that the movement against IPv6 for security reasons is disingenuous or even outright dishonest. Those security reasons don't exist.

Personally, I have never seen any argument for IPv6 based on security (except for some very fringe ones about address enumeration). But if anybody makes one to you, well, it would be disingenuous, or maybe even dishonest too. There is no security-based argument either way.

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

#576

Earlier quoted context omitted.

That's NAT64. It's something that Hetzner could and should be providing for their customers, but as far as I can see they aren't.

Well ok... the problem stops right there then. Why would anyone expect -- given the low adoption of IPv6 -- IPv6 sans NAT64 to be workable? Why even bother without it? I don't imagine it would be hard to locate any number of IPv6 zealots proselytizing a NAT64-less world, but here we have someone that made a legitimate effort to apply IPv6 and failed because it wasn't there. One fewer potential convert added to the pi…

It's workable if all of the machines you're going to talk to have v6, which is doable. Or you can run your own NAT64.

It would also be very easy to suggest that maybe Hetzner want to encourage people to keep paying for v4.

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

#577

Hey all... unquietwiki from r/ipv6; been lead-mod there for a while now (though the rest of the folks are really amazing on the mod-side). IPv6 has saved my bacon more times in the past 15 years, than IPv4 has fought with me. No clashing of IPv4 ranges. No fighting with NAT. Ability to easily have concurrent networks, for different purposes. Ability to assign multiple network addresses. Internally, it "just works" on…

> And lastly... a lot of IT guys still don't care for IPv6 The issue I have with IPv6 is that it's so complex compared to the IPv4 I know, and still has lacking support in routers and similar. For example, I want to be sure my local devices uses my local NTP server. With IPv4 it's trivial, I just add an option to the DHCP server. With IPv6 I can't do that with RA, I have to use DHCPv6. But Android doesn't support DHC…

> For example, I want to be sure my local devices uses my local NTP server. With IPv4 it's trivial, I just add an option to the DHCP server. With IPv6 I can't do that with RA, I have to use DHCPv6. But Android doesn't support DHCPv6, so I have to run both RA and DHCPv6, and hope it just works out.

Out of curiosity, why does this require DHCPv6? Cant you just point your local devices to ntp.homedomain (or whatever the DNS name of the local NTP server is)?

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

#578

Earlier quoted context omitted.

> NAT punching does require cooperation of programs on the protected machines As does listening to a port. > And is it any different from a stateful firewall on IPv6? Hum, not much. And that's the point, all of those are basically the same. NAT doesn't give you much security, and NAT without a firewall usually gives you less security than a firewall, since NAT usually is configured for connectivity, and a firewall fo…

> > NAT punching does require cooperation of programs on the protected machines > As does listening to a port. Listening on a port is for incoming connections, exactly the kind that we're blocking with either a (stateful) firewall or NAT. Listening on a port is a declaration of a program (a server) to communicate with whichever counter party can connect to this port (until the server program decides to close the conn…

> I have always understood NAT's protection to be limited to prohibiting incoming connections

It doesn't actually do this. NAT rewrites the source address of outbound connections. Inbound connections aren't outbound connections so it does nothing to them, which means it doesn't prohibit them.

That is why you don't need NAT for security: it doesn't give any in the first place.

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

#579

Earlier quoted context omitted.

OMG! What were we all thinking! Thank you redox99 for figuring this out. Only now that you have pointed out this idea is it suddenly obvious. But, since this is, you know, the entire internet , can you maybe write a more detailed specification? So like, when my TCP stack creates a presumably backwards compatible IPv4 header, where does it put the extra 4 bytes? Or do we only send these IPv4+ packets to devices that w…

Please look at the structure of an IP header. Note the "options and padding" section. Also SECTIONS of the internet (that is, routers) can have IPV4+ packets wrapped in IPV4 packets that will transmit them through "IPV4-old" only branches. We pretend like the major routing backbones aren't known and fairly set in stone, and that routers don't know about each other. Yeah, his approach doesn't fix the Comcast-doesn't s…

I don't think you are refuting my claims. If you put the extra 4 bytes of address at the end of the header, telling the legacy software that the header is now bigger doesn't mean that it will use those bytes for routing. Hence it will route to the IPv4 address. Hence if we send to a.b.c.d.8.8.8.8, it will actually get sent to 8.8.8.8.

IPv4+ packets wrapped in IPv4 is just 6in4.

And all the handwaving is exactly that. It doesn't solve the actual problems that OP claims, e.g. being able to keep existing scripts and everything just works. If anything it makes those systems far more fraught. IPv6 does allow an admin to keep all those scripts for IPv4 and have them still just work.

If anything, what this whole thing shows is that many network admins don't know what the fuck they are doing and are relying on existing scripts and cargo culting.

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

#580

Earlier quoted context omitted.

You're essentially blaming the victim. The ISPs still haven't adopted it after 25 years. ISPs are a massive monopoly in the USA. IPV6 can't be adopted by software until a sufficient number of the backbone works. I've heard that "the backbone is all working for ipv6". Um, is comcast? Wasn't last time I had comcast. If the ISP monopolies aren't 100% ipv6 (and you see lots of comments here that ipv6 support in ISPs is s…

45% of users are on IPv6. Clearly almost half of ISPs have adopted it, probably more than half of consumer ISPs.

How many of those are Mobile?

And how many of those mobile ipv6 addresses are communicating with the "real" internet through a carrier grade NAT to translate/intermediate with IPV4 servers/addresses?

And about the most offensive, disgusting thing to ipv6 people is the NAT. It's the thorn in their side that 1) IPV6 "trivially" solves (allegedly) but even worse 2) it's what keeps ipv4 on life support with the ISPs.

Can some ipv6 person tell me with a straight face that mobiles being ipv6 behind a huge cgnat is "success"?

So the fact that the big success story of ipv6 is all enabled by a huge massive NAT is ... morbidly hilarious.

So that actually means that most "regular internet" HAVEN'T adopted it, a statistic meant to show good uptake actually shows the real problem. The ISPs for cable/internet, Despite huge huge monopoly-protected revenues, aren't doing anything at all.

Again, as a programmer, I would like to work with static IPs. NATs suck, ipv4 sucks, private addresses vs public addresses suck. If not for the condescending, ivory tower, shove-down-throat, bungled incompetent planning, utter lack of outreach and transition planning, an addres transition plan (per the MX + A guy's thesis), I would love ipv6. I WANT A STATIC IP. EVERY PROGRAMMER WANTS A STATIC IP. We don't want to think about all the ipv4 bullshit.

The failure is with the ipv6 mafia. They failed. They keep failing. And based on everything they say and their representatives, they will continue to fail.

Post reply on HN