←back to thread

The IPv6 Transition

(www.potaroo.net)
215 points todsacerdoti | 1 comments | 20 Oct 24 05:54 UTC | HN request time: 0.202s | source
Show context
hairyplanter ◴[20 Oct 24 07:13 UTC] No.41893537[source]▶
I have fully implemented IPv6 in my home network.

I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.

The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.

Other than this one use case, IPv6 does nothing for me.

It doesn't work from most hotels, nor from my work lan, nor many other places because most "managed" networks are IPv4 only. It works better at Cafes because they are "unmanaged" and IPv6 is enabled by the most common ISPs, like ATT and Comcast and their provided routers.

Based on this experience, I think IPv6 is less valuable than us HN audience thinks it is. Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.

I think the adoption rate reflects this--it's a linear growth curve over the last 25 years. It should have been exponential.

I think cost of IPv4 reflects this--it is now below the peak, and has leveled off.

As surprising as it seems, IPv4 exhaustion has not been a serious problem. Internet marches on. IPv6 is still a solution looking for a problem, and IPv4 exhaustion wasn't one of them.

replies(21): >>41893541 #>>41893647 #>>41893711 #>>41896275 #>>41898003 #>>41898138 #>>41898700 #>>41898907 #>>41898988 #>>41899569 #>>41900489 #>>41900918 #>>41901253 #>>41901285 #>>41902429 #>>41902453 #>>41902668 #>>41903211 #>>41903638 #>>41903908 #>>41913238 #
1. rendaw ◴[21 Oct 24 05:26 UTC] No.41900918[source]▶
My anecdote with an ipv6-only home network (linux router):

Doing NAT64 runs into MTU issues and the behavior I observed is chrome would resend the request but only after 30s, firefox and other programs entirely failed to resend requests that were rejected due to MTU issues. Once I got the rejection, retrying in firefox or whatever would work though, so it seems like the path MTU was cached somewhere at the OS level. Reducing MTU manually seemed to fix the problem, but isn't that supposed to be automatic? Why didn't the kernel do the resends?

Old iPads, Androids just don't work, I'm not sure why. My iPhone 11 would connect to the network but declare itself disconnected after 24h or so (some lease or dns expiry which it doesn't renew?).

Steam hardcodes an ipv4 address for login... !! I'm not sure what to make of that, and the fact that it was reported around 10 years ago and they still haven't fixed it. Is it even using TLS?

I needed to make docker dev containers use host networking, because otherwise they'd get ipv4 addresses and try to do ipv4 traffic which couldn't be tunneled by default over ipv6.

Other than that it basically worked.

There's fundamentally only two different ways ipv6 can be configured from an ISP: SLAAC with no delegation, so you essentially share a network with other customers, or DHCPv6 delegation. Unlike IPv4 which has a million different offerings: PPPoE, DSLite, MAP-E, DHCP, etc etc and many of those aren't supported by linux.

I signed up with an ISP that claimed to support NAT64 (Biglobe) but they only support it on their SLAAC ipv6 + PPPoE ipv4 setup, not on their DHCPv6 PD + MAP-E setup, so I had to switch back to SLAAC. At this point in time the NAT64 support seems to be have been a lie... But anyways, to control my network DNS settings despite that I made a program to rewrite RA (and various other packets) with my own DNS server information.