Live data from Hacker News

Google Hits 50% IPv6

blog.apnic.net

461–470 of 496 posts

Re: Google Hits 50% IPv6

#461
post #447
post #434

Earlier quoted context omitted.

> We didn't have requirements 4. change all the pre-existing addresses So your alternative does something you said you didn’t want, while being worse than the original?

Oh I mixed it up with 3. Yes you don't need #4. I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1, so it's 1:1 but not onto. Instead v6 did completely new /64s with random addrs inside, no association with the v4 addrs. About the others being optional, no they aren't really, because most devices will implement the minimum. Android doesn't support dhcp6. My router is like mo…

> I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1

"v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses.

> because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway.

Sucks to be you but irrelevant to the protocol.

> Ipv6 spec also says that a router could either default allow in or not via its firewall.

Just like in IPv4 - in the pre-NAT world (or if your ISP assigned you a block of v4 addresses), if you were connecting a device to the public internet it would have be assigned a routable v4 address and it would be up to the administrator what traffic they accepted.

Re: Google Hits 50% IPv6

#462

Earlier quoted context omitted.

Latency wise, I am not noticing any difference (at least in ICMP). ycombinator@Mainframe:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=24.3 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=24.1 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=23.9 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=23.9 ms ^C --------------- 8.8.8.8 ping statistics -------…

There is no inherent added latency. That only applies for the translation layer, when there is no native support.

OP was making the case that CGNAT adds to the latency in some significant way. Yes it adds latency, but it is of negligible concern.

Re: Google Hits 50% IPv6

#463
post #461
post #447

Earlier quoted context omitted.

Oh I mixed it up with 3. Yes you don't need #4. I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1, so it's 1:1 but not onto. Instead v6 did completely new /64s with random addrs inside, no association with the v4 addrs. About the others being optional, no they aren't really, because most devices will implement the minimum. Android doesn't support dhcp6. My router is like mo…

> I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1 "v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses. > because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway. Sucks to be you but ir…

> "v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses.

Yes that's what I wanted. You don't do #4 that way. But that doesn't mean entirely separate networks, as they share the same DHCP, DNS, NAT, and so on. Maybe separate ifaces on the host.

> Sucks to be you but irrelevant to the protocol.

The protocol defined SLAAC as the default. If everyone's holding it wrong, maybe the protocol sucks.

> Just like in IPv4 - in the pre-NAT world

We're not in the pre-NAT world of ipv4. That was decades ago.

Re: Google Hits 50% IPv6

#464
post #459

Earlier quoted context omitted.

Windows, Linux, OSX, Android and iOS all ship with v6 enabled by default out of the box, so it's already turned on without you needing to think about it. You have to deliberately go out of your way for this not to be the case. > If it were as easy as you're saying, all those things like Github would already at least support v6. This isn't the "turn it on" stage, it's the "people can start putting something besides 0…

You need ipv4 to reach GitHub right now. The ipv5 "people can turn it on but not use the last bytes" stage wouldn't require ipv4 to reach it.

Do I? I don't have v4 on this machine and I can reach GitHub, so that appears to be untrue. Also GitHub would need to continue having v4 so that v4 users could reach it, so it's untrue from that perspective too.

At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much work it is or you're just outright ignoring it, but only for your own proposal and not for v6.

Re: Google Hits 50% IPv6

#465
post #463
post #461

Earlier quoted context omitted.

> I could still have 8.8.8.8 routed to me in v-next, and then later do something with 8.8.8.8.1 "v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses. > because most devices will implement the minimum. Android doesn't support dhcp6. My router is like most and has no option to enable dhcp6 or nat6 anyway. Sucks to be you but ir…

> "v-next" 8.8.8.8 isn't the same thing as IPv4 8.8.8.8, so you now have two "interfaces" running different versions of IP with identical addresses. Yes that's what I wanted. You don't do #4 that way. But that doesn't mean entirely separate networks, as they share the same DHCP, DNS, NAT, and so on. Maybe separate ifaces on the host. > Sucks to be you but irrelevant to the protocol. The protocol defined SLAAC as the…

Nah, it's just you that's holding it wrong.

Re: Google Hits 50% IPv6

#466

Earlier quoted context omitted.

The best thing about SLAAC is that it forces your ISP to give you at least 64 bits. Otherwise you know Comcast would only give out a /128 and charge you for more, so you'd use NAT at home just like IPv4.

Unfortunately SLAAC doesn't force upstream to provide a /64 universally. Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem. Mobile phone as WiFi access point is another common way people access the net nowadays. I've occasionally seen permanent installations, with a phone taped to a window. I've never seen a mobile phone AP offe…

> I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.

iPhone does that, and I’m pretty sure I’ve seen Android doing the same. The phone keeps a single /128 from the /64 assigned by the mobile network on its mobile interface and the re-assigns the /64 on the WiFi interface. No NAT is involved.

Re: Google Hits 50% IPv6

#467
post #459

Earlier quoted context omitted.

You need ipv4 to reach GitHub right now. The ipv5 "people can turn it on but not use the last bytes" stage wouldn't require ipv4 to reach it.

Do I? I don't have v4 on this machine and I can reach GitHub, so that appears to be untrue. Also GitHub would need to continue having v4 so that v4 users could reach it, so it's untrue from that perspective too. At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much…

Github.com doesn't have an AAAA record, so I don't know how you're reaching it if you don't have a v4 anywhere. Even if they had that, they said that basic features like cloning repos won't work over v6. Only one example of many services like this.

> In your proposal, where is that work being done?

Work for longer v5 addrs would be similar in difficulty to what v6 had to do, but it'd be done at a different time and place. Only thing that's the same is you need a new packet format that hardware can read, which could literally be the v6 format repurposed. I'd say 8 bytes is enough, leave the rest as 0s.

Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4, unlike v6 which made separate versions of those with their own state. V5 with 4-byte addrs works with those instantly, no chicken and egg. Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade.

Re: Google Hits 50% IPv6

#468
post #97
post #76

2026. Literally no reason to be using this outdated limited addressing. New regex: IP(any collection of numbers and dots). Now we have infinite IP address possibilities and no one controls the space. Done.

What does a packet header look like?

Need an IP address and a prompt explaining to Claude how to parse it

Re: Google Hits 50% IPv6

#469

Earlier quoted context omitted.

I never heard this idea before, but more octets would be a lot prettier!!

They added 12 more octets. I mean we could have written IPv6 addresses in the old format but I don't think that 42.0.20.80.64.1.192.15.0.0.0.0.0.0.0.113 is easier to remember than 2a00:1450:4001:c0f::71 (or 2a00:1450:4001:0c0f:0000:0000:0000:0071)

Exactly, it'd be horrible. They picked the right format for v6. The problem isn't the space size, it's the entropy. V6 addrs are randomly spread, but if you were using the most significant bytes first, you could have something like 42.0.20.80.64.

Re: Google Hits 50% IPv6

#470
post #248

Earlier quoted context omitted.

> It takes over 30 years Only because it is overengineered. Parents pragmatic protocol would have been adopted faster

IPv6 is just IPv4 with more address bits.

It really isn't. I mean, at a very basic addressing level, sure, IPv4 addresses and IPv6 addresses are just a sequence of octets. But at a network infrastructure level they are quite different, and IPv6 is (conceptually) designed for large-scale, hands-off deployments. See: SLAAC, NDP, DAD, GUA/ULA/link-local address scopes, unicast vs. multicast vs. anycast, etc.
Post reply on HN