Live data from Hacker News

The world in which IPv6 was a good design (2017)

apenwarr.ca

261–270 of 318 posts

Re: The world in which IPv6 was a good design (2017)

#261

Earlier quoted context omitted.

> I can't `ping ::ffff:192.168.0.1` and have it ping my router. How would that even work in theory? How would a ('legacy'?) host that only understands the 32-bit data structure of IPv4 addresses talk to a >32-bit data structure IPv6 addressed host?

If it truly encapsulated IPv4, then there wouldn't be two stacks. It would be one stack and legacy devices could snip the xtra bits (or have it done for them via a router).

> (or have it done for them via a router)

And then we are back to NAT...

Re: The world in which IPv6 was a good design (2017)

#262

Earlier quoted context omitted.

Because it comes with all of the drawbacks of IPv6 but also ditches some of the advantages. You still need to update every router and application. Network admins still need to learn something new. The two protocols still don't interoperate. If you're going to go through all of that trouble why only do a half measure. IPv6 is supposed to be the final version of IP.

> The two protocols still don't interoperate. On the contrary, they would, the behavior's and quicks would be the same. And if we define, say, that if the last four components are zero, then the addr is the same as normal IPv4 address, then you could deploy the whole thing without having anybody assigning new addresses. NAT's/configs/etc could keep working. The big problem with IPv6 is that everything has to be doubl…

> then you could deploy the whole thing without having anybody assigning new addresses. NAT's/configs/etc could keep working.

How does a device that thinks that addresses fit in a 32-bit address space send a packet to a device with a larger address?

Re: The world in which IPv6 was a good design (2017)

#263
post #134

Earlier quoted context omitted.

> And once you go over 16 bits, you really need to start dealing with routing. Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets. The reason you don't see them very often is because people have had to use IPv4, which means ARP, which just doesn't scale. At some p…

> Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets. First, a /16 network is 65536 devices, which is pretty big as-is. And like in V4, you'll be able to disregard recommendations and choose a larger local net size (just change the netmask). But it's a bad idea. Y…

> First, a /16 network is 65536 devices, which is pretty big as-is.

"big" is a relative term. For some cases, that's a really annoying restriction.

> But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...

IPv6 doesn't have the concept of "broadcast".

> ND doesn't solve it. It works in practice using the same old broadcast

No, ND uses multicast.

Running any network with >100k hosts has its challenges, but these are surmountable with IPv6, and not at all with IPv4.

Re: The world in which IPv6 was a good design (2017)

#264

Earlier quoted context omitted.

> The over 99.9% of sites that still have an A record have it for a very good reason A records work on v4 and v6, so they'll probably stick around for a while. Perhaps they'll end up being concentrated around 4-to-6 forwarding NAT-as-a-service companies, but they're the fallback mechanism. I don't think anyone is advocating for dropping A all together unless you're really trying to pinch pennies. > I'd love to see so…

> Unlearning NAT NAT is certainly not a firewall, but it is a very useful router function. I still don't understand how IPv6 makes NAT a thing that isn't useful to know. I want to expose my servers to the internet through a single shared IP address, and to be able to have those servers exist on different IP addresses inside my network. How does IPv6 allow this without NAT?

IPV6 doesn't prevent you from natting if you really want to. It just gets rid of the thing that forces you to NAT.

Re: The world in which IPv6 was a good design (2017)

#265
post #241

Anyone else mostly fine with IPv6 like it is? Biggest complaint here is that I wish I had a way to correlate SLAAC addresses with hostnames somewhere other than the host. But I don't so when it matters I run a DDNS client on the host, which is probably the "more correct" answer anyway because the host always keeps DNS updated with its current address.

I'm fine with IPv6. The more correct answer to your complaint is to dump the router's ND cache. I'm pretty sure this is part of SNMP.

Interesting, thanks! I'll have to see if I can get OpenBSD to do that.

Re: The world in which IPv6 was a good design (2017)

#266
post #241

Earlier quoted context omitted.

I'm fine with IPv6. The more correct answer to your complaint is to dump the router's ND cache. I'm pretty sure this is part of SNMP.

Interesting, thanks! I'll have to see if I can get OpenBSD to do that.

On OpenBSD, you can dump the ND cache with `ndp -an`. You'd still have to map MAC addresses to hostnames somehow.

Re: The world in which IPv6 was a good design (2017)

#267

Earlier quoted context omitted.

I work for a federal space where IPv6 native is a mandate. As someone who's working on k8s, we often have to build and patch everything ourselves to support that mandate. Want to pull a helm chart from a github repo? Gotta either dual stack the node or run a reverse proxy to make that happen. I'd love to be at a point where everyone just dual stacked everything so that one day we can flip off the IPv4 switch.

I think major failure of Kubernetes was not being IPv6-only from the beginning. Its model of every pod having own address works much better with IPv6 where addresses are cheap. With IPv4, it needs complicated overlay networks. The cluster boundary would also make a good place for NAT64 proxy. Kubernetes didn't get IPv6 support until later, and it sounds like it isn't reliable yet.

> I think major failure of Kubernetes was

Heh. Kubernetes as a whole was a failed project at Google that got open sourced.

Re: The world in which IPv6 was a good design (2017)

#268
post #263

Earlier quoted context omitted.

> Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets. First, a /16 network is 65536 devices, which is pretty big as-is. And like in V4, you'll be able to disregard recommendations and choose a larger local net size (just change the netmask). But it's a bad idea. Y…

> First, a /16 network is 65536 devices, which is pretty big as-is. "big" is a relative term. For some cases, that's a really annoying restriction. > But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do ... IPv6 doesn't have the concept of "broadcast". > ND doesn't solve it.…

> IPv6 doesn't have the concept of "broadcast".

Indeed. It has magic fairies delivering multicast packets to the right interfaces.

> No, ND uses multicast.

How do you think multicast is implemented in Ethernet?

Re: The world in which IPv6 was a good design (2017)

#269
post #159

Earlier quoted context omitted.

I can't `ping ::ffff:192.168.0.1` and have it ping my router. There is a range reserved for representing IPv4 addresses, but the stack doesn't translate.

You can if you have NAT64: $ ping 64:ff9b::1.1.1.1 PING 64:ff9b::1.1.1.1(one.one.one.one (64:ff9b::101:101)) 56 data bytes 64 bytes from one.one.one.one (64:ff9b::101:101): icmp_seq=1 ttl=54 time=10.4 ms 64 bytes from one.one.one.one (64:ff9b::101:101): icmp_seq=2 ttl=54 time=10.0 ms

The NAT64 prefix (64:ff9b::/96) is not the one GP cited (::ffff:0:0/96).

Also I don't have NAT64... The fact that ISPs don't provide NAT64 by default is kind of my point.

Re: The world in which IPv6 was a good design (2017)

#270
post #7

>It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address? Not super common but there's Infiniband. Latter versions supported encapsulating ethernet frames (Ethernet over InfiniBand) but not all hardware supports it. Otherwise it's straight IP over IB. There must be other niche networking technology that does IP without Ethernet.

Does networking over Thunderbolt work similarly?
Post reply on HN