Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

apenwarr.ca

Post reply on HN
Print view View original

281–290 of 318 posts

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

#281

Post by cyberax »

greyface- wrote: post #271
cyberax wrote: post #268

Earlier quoted context omitted.

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

> How do you think multicast is implemented in Ethernet? Via MLD snooping on switches that support it. Yes, some switches will fall back to broadcast, but only if they're not multicast aware.

Snooping table sizes are typically around 16k entries. IGMP/ND packets are almost always punted to the CPU, so once the CPU is saturated, switches typically either fall back to broadcast or stop forwarding multicasts.

It's not a good outcome either way.

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

#282

Post by greyface- »

cyberax wrote: post #281
greyface- wrote: post #271

Earlier quoted context omitted.

> How do you think multicast is implemented in Ethernet? Via MLD snooping on switches that support it. Yes, some switches will fall back to broadcast, but only if they're not multicast aware.

Snooping table sizes are typically around 16k entries. IGMP/ND packets are almost always punted to the CPU, so once the CPU is saturated, switches typically either fall back to broadcast or stop forwarding multicasts. It's not a good outcome either way.

This varies widely by switch model, and 16k is on the low end. I looked at a few random Cisco and Arista switch datasheets just now and saw numbers ranging from 16k to 768k (usually 25% to 100% of the unicast MAC table size of the same switch).

Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. You don't see people claiming this makes IPv4 over Ethernet infeasible. Do proper capacity planning, and this isn't a problem. Oversubscribe your network, and this is a problem even without multicast in the picture.

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

#283

Post by WorldMaker »

Thiez wrote: post #279
WorldMaker wrote: post #255

Earlier quoted context omitted.

Certainly, it is at least a start that all the cloud providers are slowly raising the hourly costs for v4 addresses to better reflect scarcity and other externalities. Those costs rise high enough it will be a pressure on corporate bottom lines (and then in turn IaaS tools and many other SaaS providers).

And yet Azure has comically bad IPv6 support, so you can't even move (partially) away from IPv4 even if you wanted to. Besides, the cost of a v4 address is peanuts compared to the other cloud costs.

All of the big three (AWS, Azure, GCP) have comically bad IPv6 support and comically bad security advice on IPv6 and private networking in their documentation.

Kubernetes is comically bad at IPv6. Docker is comically bad at IPv6.

GitHub is comically bad at IPv6.

Like I said, pricing IPv4 at all, is at least a start, a baby step in the right direction. Even if it is a drop in the bucket compared to the rest of the cloud invoice, it is still at least a line item that corporate accountants are going to notice. It is now an obvious cost to cut. Maybe that will put pressure on fixing how comically bad the above offenders (and more) are actually supporting IPv6, because corporate accountants may start asking hard questions.

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

#284

Post by lproven »

tenebrisalietum wrote: post #121
lproven wrote: 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…

I read the article, also found it a bit confusing and wayward, and couldn't quite articulate why I disagreed with it at first, but I think I can now. - The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. - IP addresses are assigned to interfaces, not people, computers, devices, applications, n…

> The "mobile IP" problem isn't IP's job and should not be.

Not an expert here, but my understanding of the argument is:

For constructing virtual networks, which may be distributed across the real Internet, the new protocol needed a virtual translation layer. It doesn't have one. Instead it just had a vastly larger address space, which doesn't help with this.

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

#285

Post by maaarghk »

A bit off topic but the most interesting part of this was clicking through to the link about TCP BBR. It's available for the Linux kernel but not bundled / enabled by default, but if these related posts are telling the truth, maybe it should be:

https://djangocas.dev/blog/huge-improve-network-performance-...

https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...

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

#286

Post by justcool393 »

BizarroLand wrote: post #210
0cf8612b2e1e wrote: post #204

Earlier quoted context omitted.

Probably anathema to the dreams of IPv6+ IP-for-everything, but in your putative scheme, could we also make a carve out for local network? I like that 192.168.*, 10.* are defined as local. So 0000:0000 local network, 0000:0001 legacy internet.

Yeah, that's smart. There's no need for everything to be uniquely identified on the internet anyway, right? Why would someone halfway around the world need to be able to ping my smart fridge after all? Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities. Actually, now that I've done the math, why not just extend IPv4 into hexadecimal? Once again, none…

> what's not to love about it

hexadecimal, unironically. the url of

http://[2002:914b1:::1]

is one of my major sticking points for IPv6. i'd rather just have it be 16 octets or even 8 decimal quartets where each thing is required.

http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246

would've at least looked a bit better than it is. would've been super easy too. imagine the convo:

"what's google's DNS IP in IPvX?"

"oh it's just 8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.8"

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

#287

Post by justcool393 »

AtlasBarfed wrote: post #244
GordonS wrote: post #115

Earlier quoted context omitted.

> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gath…

> Also, NO SLASHES NO COLONS in the notation

CIDR notation I think is fine, but hard agree on the colons holy crap. Also not being clever with the things, remove the "empty dot" thing.

> And ... can we increase the number of ports to 32 bits or more?

That requires a TCPv2 or UDPv2 or whatever, it happens at a higher layer than the IP layer.

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

#288

Post by justcool393 »

WorldMaker wrote: post #251
arka2147483647 wrote: post #164

Earlier quoted context omitted.

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

> 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. IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123 Technically, there's nothing stopping you from building a qui…

To be honest, the hex strings make it much harder to remember imo, especially with the terrible syntax of nothing between a colon being a 0.

Even having them be 16-bit integers would've been find imo

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

#289

Post by lproven »

Dagger2 wrote: post #252
AtlasBarfed wrote: post #242

Earlier quoted context omitted.

I pulled out this as the most salient point in the article: IPV6 designers assumed that IPV4 would be phased out completely in a short period of time, for some definition of a short period of time, and IPV6 would completely replace internet networking. I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design. And now it's been ...…

> Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6 You don't know how, and nobody knows how, because it's not possible to do. v4 simply does not support addresses longer than 32 bits. If it did, we wouldn't need v6 in the first place. Choosing not to do something that's impossible isn't hubris. Hubris is crit…

> You don't know how, and nobody knows how, because it's not possible to do.

I think you misunderstood the comment, but at first reading, I did too.

But on consideration, I do not think @AtlasBarfed meant that this hypothetical IPv12 or whatever (7 through to 10 are taken) would be able to talk to both in one protocol.

It's well established that no seamless extension of the IPv4 4-octet address space was possible. I know, a lot of people still don't get that, but honestly, to the majority of people working in tech today, all this stuff is black magic that just happens. Either they learn, or they don't and can be ignored. That's OK. We have to live with that and move on.

The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half the IP market. That is not just "not good" - that's terrible.

What IMHO apenwarr's blog post was trying to get at was the complexity of connection schemes needed, and how a new protocol with an integral way of of constructing virtual networks, connected over the public internet into cohesive wholes via some form of built-in redirection or mapping layer, would have made it a far more compelling offering.

I have seen others saying this, but I can't find any links any more. I welcome other pointers to articles not merely pointing out problems -- there are lots of those -- but proposing solutions.

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

#290

Post by pknomad »

mike_d wrote: post #267
ianburrell wrote: post #226

Earlier quoted context omitted.

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.

I was under the impression that Google simply latched onto the project? Doesn't Google still use borg to this day?
Post reply on HN