Tell HN: IPv6-only still pretty much unusable • Hacker News Board

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

#551

Post by pantalaimon » Thu, Dec 08, 2022, 1:04 PM UTC

nottorp wrote: post #546

pantalaimon wrote: post #436

Earlier quoted context omitted.

Yes link-local is only local to the link (same broadcast domain). But most home networks are bridged on layer 2 anyway. IPv6 allows for a design where you don't have everything on the same broadcast domain but actually use subnets for e.g. the WiFi network. But since you still want to retain IPv4 compatibility, this is usually not an option in home networks. > So point me to an overview of ipv6, enough to manually co…

> Just enable router advertisements on your router Thats not “manually”. Thats clicking in the routers UI. My idea of manually is roll your own Linux. Worked just fine for ipv4, looks like a full time job for 6.

Then install radvd to enable router advertisements.

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

#552

Post by throw0101a » Thu, Dec 08, 2022, 1:21 PM UTC

est31 wrote: post #157

redox99 wrote: post #32

IPv6 has been one of the biggest failures in the last couple of decades. And I don't mean adoption, I mean the standard itself. If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.…

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…

> That being said, Amazon currently has 2880 ipv4 allocations and 946 ipv6 allocations... not much gained I guess? :p https://asnlookup.com/asn/AS16509/

How many clients can those IPv4 allocations serve? How many clients can those 946 serve?

If Amazon had 2880 IPv6 allocations, how many clients could they serve?

I'd say a lot was gained. Someone asking for a random PI IPv6 allocation gets, at minimum, a /48 for a "site". That's the equivalent of a Class A (16 bits for subnets).

Are you saying everyone being able to get their own Class A equivalent is 'nothing gained'?

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

#553

Post by krageon » Thu, Dec 08, 2022, 1:22 PM UTC

throwaway2037 wrote: post #499

nightfly wrote: post #323

Earlier quoted context omitted.

We've tried to roll out IPv6 at my work, and after several years of it causing more issues than it help we turned it all off again... We're gonna get back to it again this year, but I can see many organizations just not doing that until absolutely forced.

Thank you to share a real world story. Failure is usually more interesting to study than success. Real question (no trolling): Is there any business value upgrading to IPv6 or is this a forced upgrade? I think that is number one reason that delays IPv6 upgrades: no business value (or so limited compared to cost of IPv6 impl).

If you're running something that isn't absolute shit it's not this much of an issue to upgrade to ipv6. There's business value in that simply because ipv4 addresses are expensive.

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

#554

Post by throw0101a » Thu, Dec 08, 2022, 1:27 PM UTC

x3n0ph3n3 wrote: post #516

bert64 wrote: post #486

Earlier quoted context omitted.

Those ISPs are broken and not following the RFCs or RIR guidelines. There's nothing stopping you from using NAT with IPv6, people just don't do it because the only benefit of NAT is conserving limited address space. NAT on IPv6 just brings all downsides and no benefit because you (should) have no shortage of address space. In any case v6 with nat is no worse than legacy ip with nat, its just stupid because they're fo…

> the only benefit of NAT is conserving limited address space. It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.

> It's also a privacy feature which ensures I am able to hide the number of unique devices in my network.

A combination of: (a) my Asus AC-68U not allowing non-reply, inbound connections for IPv6, and (b) my clients using rotating, randomly generated addresses, accomplishes the exact same thing.

NAT doesn't add much over a decent stateful firewall with a default-deny rule on incoming connections.

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

#555

Post by throw0101a » Thu, Dec 08, 2022, 1:33 PM UTC

fernandomm wrote: post #191

redox99 wrote: post #32

IPv6 has been one of the biggest failures in the last couple of decades. And I don't mean adoption, I mean the standard itself. If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.…

Let's not forget about the idea that ISPs would distribute a /56 range to residential users. You could split it in /64 ranges according to your requirements and everything would work fine. There is only one "minor" issue: all major ISPs in my country ( Brazil ) only provide a single /64. You can't get another /64 unless you upgrade to a very expensive business plan. That makes IPv6 not only useless but also a huge se…

> There is only one "minor" issue: all major ISPs in my country ( Brazil ) only provide a single /64. You can't get another /64 unless you upgrade to a very expensive business plan.

And my ISP gives me a /56. What's your point? What you say is not a knock against the protocol, but stupid ISPs.

In fact, you're actually better off compared to IPv4. At least you now have publicly available IPs with can easily be connected to if you wish, rather than having to go through the silliness of port forwarding with NAT.

> IPv6 is the other way around. In practice, all devices and ports are exposed unless you explicitly block it.

Not on my Asus AC-68U: it has a default-deny rule on incoming connections. Only replies to existing connections are allowed.

Again: your critique is not against the protocol itself, but stupidity.

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

#556

Post by daemon_9009 » Thu, Dec 08, 2022, 1:38 PM UTC

No post body was provided.

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

#557

Post by chillfox » Thu, Dec 08, 2022, 2:03 PM UTC

viraptor wrote: post #533

chillfox wrote: post #490

Earlier quoted context omitted.

Sure, but most places are not setup to using DHCP on servers or automated installs. So you will be typing in IP addresses through some kind of console to configure the machine in the first place and you will be typing in that IP address in the DNS system and when someone remotely fucks up the routing or IP config then you will be manually typing in lots of IP addresses to fix it.

If you have enough nodes to care and manually assign and at the same time don't automate deployment that sounds like an issue in general... and not with IPv6. You're likely to typo IPv4 just as well with enough entries.

Yep, but in my experience you have to manage about 2000+ machines before management will allow you to spend time on setting up deployment automation. So around the time you are setting multiple new machines a week.

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

#558

Post by pflanze » Thu, Dec 08, 2022, 2:05 PM UTC

marcosdumay wrote: post #501

pflanze wrote: post #260

Earlier quoted context omitted.

- NAT punching does require cooperation of programs on the protected machines, though, no? How is it different from them inviting traffic in any other way (like, requesting a page via https from an infected server could hijack the client on the protected machine if the client has security holes in the right places; the https client is willing to get traffic here, just as some VoIP program is willing to receive a call…

> 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 connection), and limiting that reach is the topic here.

NAT hole punching is more like an outgoing connection in that the client agrees to communicate with a particular single counter party for each punch. That's why I made the comparison to opening an https connection to a server. The risks look basically the same to me (the client has to trust the server in the https case, and the client has to trust the intermediating server in the NAT hole punching case to intermediate with the right client; admittedly it additionally has to trust the other peer (e.g. that its compressed data doesn't try to break decoders), but in cases where it communicates with another party via a server the situation may be the same again (unless the server re-encodes the data and does that securely)).

> And that's the point, all of those are basically the same.

That's a relief for me to hear, as I started to doubt myself whether I am missing something ("why is it not OK to use NAT to block incoming connections?").

> since NAT usually is configured for connectivity, and a firewall for protection.

Sure, a firewall can add additional restrictions. I have always understood NAT's protection to be limited to prohibiting incoming connections (unless when adding port forwarding), while allowing outgoing connections including NAT hole punching.

I'm also talking in the context of configuring a Linux machine via iptables (where you configure both NAT and other firewalling rules). Maybe you're thinking more in terms of consumer "NAT" vs. consumer "firewalling" devices and their respective capabilities. Or maybe this whole "don't consider NAT to be a security feature" movement is just to pull people towards IPv6 by saying they don't need NAT to be as secure (or better if they configure additional restrictions)?

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

#559

Post by mplabelspace » Thu, Dec 08, 2022, 2:46 PM UTC

MisterTea wrote: post #84

noipv6 wrote: post #21

Earlier quoted context omitted.

anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes. part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008 part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). that turned out to not be so effective since so many ppl ignored the realities of legacy ip depleti…

> part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008 Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6? > part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). Perhaps they didn't listen because dual stack means investing in building another incompatible internet on ipv6 i…

This is an astoundingly narrow take. They (vendors, practitioners, stodgy luddites) didn't listen because there was nothing on fire and no money to grab at when the conversations began 20 years ago. Networks exist (and have always existed) globally that operate using parallel, incompatible protocols from layer 1 to layer 3. None of this is new, and none of it should be a surprise. The outrage all stems from a lack of awareness of history and increased visibility from armchair experts that fixate on how things work for them, and not from the long-term perspective or the point of view of a large provider, global network, or resource of significant scale / size. IPv4 is the poster child for the sunk cost fallacy; it is an outdated shit pile that has become the outdated shit pile we know, and therefor somehow the option that needs extended in perpetuity. "Good Enough" is subjective. A bicycle is "good enough" for moving a person from point A to point B over short distances. It's not good enough when it is below freezing, raining, or needs to transport large cargo. It's not good enough when there are 3 people that need to travel from point A to point B and there is only one bicycle. A car may be good enough for that. But a car isn't good enough when part of that trip spans an ocean. The fact that a person thinks IPv6 is a stupid idea and that extending or making compatible the pant load of diarrhea that is IPv4 is "good enough" is fine for that one person, or even a group of persons. However, it does not scale globally, and it provides no supportable longevity. Even with the release of every single extra block of IPv4 - 240, 127, all of the unused or dark /8 addresses, 0.0.0.0, 255, and even with the proliferation of carrier NAT - it is still too limited to scale long term or introduces blindingly unnecessary complexity. There is already significant IPv6 deployment globally, and it has grown by a large margin in the last 3 years, prior posts have clearly shown that. As far as IPv4, The goal was never to turn it off like a light switch, it has always been to phase it out, and by and large that has been happening at a fairly accelerated rate.

If we spend half as much time on IPv6 that we do moaning about IPv6, we would have been done with this a decade ago. The point is that IPv4 is functionally legacy. It'll continue to exist until it doesn't, but refusal to learn and implement IPv6 (and contribute to improving it) is truly a disservice. It's well past the point of no return, so learn it. Or don't. It won't really change the direction we are moving.

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

#560

Post by temp2022acc » Thu, Dec 08, 2022, 3:17 PM UTC

I've always figured the easy way to improve adoption rates is to build in a statistical failure to ipv4 stacks; add a kernel option to drop 0.1% of ipv4 packets, or add a 250ms delay to ipv4 packets, and adoption of ipv6 will skyrocket without significantly impacting existing workloads because v4 will still work 99.9% of the time.