Live data from Hacker News

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

apenwarr.ca

181–190 of 318 posts

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

#181
post #79
post #70

Earlier quoted context omitted.

No, it didn't work. Other than already mentioned issues of hardware, you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets which leaked protocol internals up to application layer. It was a very big and vocal issue about porting to v6 even in early 2000s despite BSD Sockets finally getting a new API (lifted from the Streams-based XT…

> you also had for years the issue of lots of applications requiring substantial rewrite to support another protocol due to use of BSD Sockets Past tense? I still regularly see code that uses BSD sockets and doesn't support IPv6. Actually, I feel like among C and C++ codebases that make direct TCP or UDP connections, the majority are IPv4-only, even in 2023. Though, direct TCP and UDP connections themselves are less…

[deleted]

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

#182
post #106

Earlier quoted context omitted.

in ipv6 you can (should) grade whole subnets as end customers typically get whole /64s.

Not always though. Lower end VPS providers seem to be moving towards placing you on a shared /64. I run into issues on a particular Digital Ocean instance of mine where my IPv6 allocation is something like a /112 and it gets swept up in bans on the parent /64 because of other's bad behavior. Then you have other providers like Vultr that do weird things like not statically route your /64 prefix to your instance which…

Digital Ocean has been in the wrong with their IPv6 allocation since the day the implemented it. One of the rules of IPv6 is never allocate less than a /64. Unfortunately their network admins don't seem to care.

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

#183
post #159

Earlier quoted context omitted.

But it does, that's what ::ffff:0:0/96 is for

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.

> 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?

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

#185
post #91
post #78

Earlier quoted context omitted.

IPv6 adoption is just the traffic shift from desktop to mobile. IPv6 kinda makes sense in mobile because it solves a problem of needing multiple addresses per person (phone, tablet, gaming device, etc) and the whole stack is maintained by two entities (the phone OS manufacturer and the carrier). It probably would have worked even better if it was far less complex and only solved the problem that was needed. https://w…

Residential broadband often has it too. The laggards are corporate networks and cloud where IT is ultra conservative and “if it’s not broke don’t fix it.” The only thing that will make corporate environments change is if something they need starts requiring it, and not a second before. Cloud is slowly getting it. Slowly. GitHub still doesn’t have it though, which makes pure v6 nodes annoying for a lot of use cases.

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.

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

#186
post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

> Point A: IPv6 is broken because it didn't go far enough Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it. Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. We have jumbo frames, why not jumbo addresses?

[deleted]

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

#187
post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

Lampson attributed that “fundamental theorem of software engineering” to Wheeler, he did not claim to have said it first.

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

#188
post #51
post #41

Earlier quoted context omitted.

> Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 16 bits is just way too small. The article clearly states that network operators just love to bridge together larger and larger networks due to the mobile IP problem. In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

8 bits for the home network feels cramped even now, my home network is at 56 devices. But 16 bits are fine for end-user networks. And once you go over 16 bits, you really need to start dealing with routing. > In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough. This is not a fair comparison. You won't have a 10.0.0.0/8 network in IPv4 that has 16 mil…

Large, sparse subnets are nice for their security benefits.

For a 16-bit network, you can enumerate all active public servers by exhaustively port-scanning it; it takes something like a few hundred gigabytes of traffic, which is nothing these days. For a 64-bit network, it takes quadrillions of gigabytes of traffic and just isn't feasible.

64 bits is enough space to fit a small public key, which v6 uses to secure neighbor discovery.

There are anonymity benefits too: privacy extensions wouldn't work as well on smaller subnets.

As an added bonus, having extra bits to spare is useful if it ever turns out that we need them. If we run out of space in 2000::/3 then we can start over in one of the five other unused /3s using tighter allocation policies. L3 protocols are incredibly hard to deploy and it would really suck to deploy a bigger one only to have to deploy another, even bigger one again soon after.

I don't think there's a good reason to give up all of that. Smaller addresses break compatibility with v4 just as thoroughly as bigger ones do, so it wouldn't even help deployment much.

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

#189

Earlier quoted context omitted.

The single biggest mistake IPv6 made was not encompassing the entire IPv4 space within it to ease transition. As it is, I am seeing a transition to either non-IP or LISP/HIP based methodologies due to security and attestation concerns.

But it does, that's what ::ffff:0:0/96 is for

That part of IPv6 is mostly deprecated. The more modern version is NAT64 which uses 64:ff9b::/96 by default.

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

#190

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…

[deleted]
Post reply on HN