Update: Approaching IPv4 Run-out • Hacker News Board

Re: Update: Approaching IPv4 Run-out

#111

Post by WorldMaker » Thu, Oct 03, 2019, 5:32 PM UTC

bifrost wrote: post #99

JimDabell wrote: post #83

Earlier quoted context omitted.

Apple have made it a hard requirement for apps to operate correctly on IPv6-only connections for a few years now. If your app doesn't work unless it's on IPv4, Apple will reject it.

That can't be totally true, Twitter doesn't work on v6.

Apps can't request IPv4 addresses directly (ie, no hardcoded IPv4 addresses allowed), but DNS may still return them for indirect use (via the Happy Eyeballs [1] approach that heavily favors IPv6 because an increasing number of mobile carriers are IPv6-only or IPv6-primarily and IPv4 addresses must get sent to NAT64 gateways).

[1] https://en.wikipedia.org/wiki/Happy_Eyeballs

Re: Update: Approaching IPv4 Run-out

#112

Post by AlpineG » Thu, Oct 03, 2019, 5:33 PM UTC

tyingq wrote: post #28

I wonder if they will implement some kind of clawback for orgs that are sitting on large chunks of sparsely used blocks. Old tech companies and colleges come to mind. https://myip.ms/info/ip_ranges_blocks/Major_Biggest_IP_Addre...

HP have two contiguous class A 15 & 16 the latter was inherited when they took over DEC. That cant be justified.

Re: Update: Approaching IPv4 Run-out

#113

Post by WorldMaker » Thu, Oct 03, 2019, 5:42 PM UTC

smacktoward wrote: post #69

sp332 wrote: post #30

Earlier quoted context omitted.

Instead of excluding CF, I'd like to see server stats weighted by popularity. I'd bet that the concentration of traffic to just a few mega-sites means most people can now get by just fine with IPv6.

You might be surprised. For reasons I can't begin to fathom, a coffee shop near me used to have its wifi router set up to only permit connections to external sites over IPv6. I was legitimately surprised at how many sites I couldn't access from there, including sites from Fortune 50 companies and big tech firms, who you'd expect to be among those who'd be on top of this sort of thing. (Including, ahem, HN.)

Enterprise has a lot less pressure to switch, because they have existing capital investments into, for instance, large, expensive IPv4-only firewalls that aren't currently "broken", and large private IPv4 subnets already walled off with enough IP addresses for their device/asset catalogs.

It maybe shouldn't be a surprise that IPv6 has seen much faster consumer adoption comparatively, as consumer ISPs face much less steady/predictable device growth and sometimes much more complex routing scenarios (cell towers have much more complicated internet traffic routing needs than wired ethernet in an office park somewhere).

Re: Update: Approaching IPv4 Run-out

#114

Post by wmf » Thu, Oct 03, 2019, 5:47 PM UTC

criddell wrote: post #101

wmf wrote: post #87

Earlier quoted context omitted.

No, because the Internet is a voluntary system.

Very few companies would need to decide to not interconnect with IPv4 networks before IPv4 was effectively dead. Typically, though, there's a process that they would go through before making that move. That's what I was asking about. Has anybody floated a date for IPv4 death?

Those very few influential people who make the decisions are incredibly conservative; they won't even kick criminals off the Internet without overwhelming evidence. I don't think they're even interested in discussing IPv4 sunset at this point.

Rather than a date I think it would make sense to look at the traffic. When IPv4 hits, say, 1% it might make sense to turn it off. I would estimate that's decades away.

Re: Update: Approaching IPv4 Run-out

#115

Post by jakeogh » Thu, Oct 03, 2019, 6:14 PM UTC

IPv4's inability to label all the things may be a feature. NAT's are like borders in some ways, and prevent fine grained censorship without larger consequences.

Re: Update: Approaching IPv4 Run-out

#116

Post by ryacko » Thu, Oct 03, 2019, 6:32 PM UTC

gorgoiler wrote: post #79

tyingq wrote: post #28

I wonder if they will implement some kind of clawback for orgs that are sitting on large chunks of sparsely used blocks. Old tech companies and colleges come to mind. https://myip.ms/info/ip_ranges_blocks/Major_Biggest_IP_Addre...

When the options are: let them profit awkwardly from a windfall, claw it back against their will, or make their IPv4 assets obsolete, focusing on the latter seems most productive. The UK’s largest mobile provider now gives me an IPv6 only connection and I didn’t even notice.

The major browser currently hides "www" and " https:// " by default.

Now it has to hide port numbers and IPV4 space will suddenly be multiplied by less than 2^16.

Re: Update: Approaching IPv4 Run-out

#117

Post by Dagger2 » Thu, Oct 03, 2019, 6:49 PM UTC

pikzel wrote: post #3

RIPE, there's this story of The Boy Who Cried Wolf. Would suggest reading it.

When did they cry wolf over this? They've made various announcements at each stage of running out, but this is the first time they've announced that they have more pending LIR applications than blocks to assign to them.

Re: Update: Approaching IPv4 Run-out

#118

Post by Dagger2 » Thu, Oct 03, 2019, 6:55 PM UTC

gerdesj wrote: post #46

lifty wrote: post #32

I'm curious if there are people here that have migrated their home network to IPv6 only, and if yes, what are the challenges encountered? I suspect the biggest problem is that there still are many websites that only have IPv4

IPv6 only is a bit daft as yet because you'll need a 6 to 4 gateway of some sort to see much of the web/internets. For starters, this: $ dig news.ycombinator.com AAAA ... fails I have been running dual stack at home for around five years now with only a couple of wobbles that I can point at my ISP losing their IPv6 and not noticing for a while.

  $ ip -4 addr show | grep eth0
  # nothing

  $ dig news.ycombinator.com AAAA +short
  64:ff9b::d1d8:e6f0

  $ wget -6 https://news.ycombinator.com -O /dev/null
  Resolving news.ycombinator.com (news.ycombinator.com)... 64:ff9b::d1d8:e6f0
  Connecting to news.ycombinator.com (news.ycombinator.com)|64:ff9b::d1d8:e6f0|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  [...] ‘/dev/null’ saved [34663]

WFM!

Re: Update: Approaching IPv4 Run-out

#119

Post by zzzcpan » Thu, Oct 03, 2019, 6:59 PM UTC

Dagger2 wrote: post #118

gerdesj wrote: post #46

Earlier quoted context omitted.

IPv6 only is a bit daft as yet because you'll need a 6 to 4 gateway of some sort to see much of the web/internets. For starters, this: $ dig news.ycombinator.com AAAA ... fails I have been running dual stack at home for around five years now with only a couple of wobbles that I can point at my ISP losing their IPv6 and not noticing for a while.

$ ip -4 addr show | grep eth0 # nothing $ dig news.ycombinator.com AAAA +short 64:ff9b::d1d8:e6f0 $ wget -6 https://news.ycombinator.com -O /dev/null Resolving news.ycombinator.com (news.ycombinator.com)... 64:ff9b::d1d8:e6f0 Connecting to news.ycombinator.com (news.ycombinator.com)|64:ff9b::d1d8:e6f0|:443... connected. HTTP request sent, awaiting response... 200 OK [...] ‘/dev/null’ saved [34663] WFM!

It's a translated with DNS64 ipv4 address into a NAT64 ipv6. They have 64:ff9b prefix.

Re: Update: Approaching IPv4 Run-out

#120

Post by magicalhippo » Thu, Oct 03, 2019, 7:30 PM UTC

jl6 wrote: post #15

IPv6 worldwide adoption is at just under 30%: https://www.google.com/intl/en/ipv6/statistics.html If the current growth rate continues, it looks like it will reach 100% by about 2035.

I just disabled IPv6 at home. Again. Been running it for a year now, but ended in tears. Again.

Gave up on trying to figure out how to make it all just work. I'd rather take one public IP that works than 9223372036854775808 that doesn't.

Mainly there seems to be a big disconnect between how IPv6 is designed and intended to be used (according to modern RFCs), and how at least my ISP actually deploys it. For one they only give me a /64, which isn't compatible with modern IPv6 ways. In addition they do so using DHCPv6, which means my prefix changes every now and then. All those internal services that got their own IP needs separate DynDNS entries. All those firewall rules opening ports for those services? Yeah they need to be manually updated.

Local DNS resolution fails because the DHCP server in pfSense sends out the public IPv6 address as the primary DNS rather than the local IPv4 I added manually to try to override it, so now my devices try to contact a DNS server that doesn't exist.

I'm sure some day it'll actually just work for me...