If you created a token ring network for your K8s cluster and it worked fine I wouldn’t say you failed. But I would say you are not doing the right things. This is the same. IPv4 is deprecated. Stop using it for things like your AWS VPC. If it doesn’t work aggressively file bug reports.
Or, I can focus on getting the project done. If IPv6 is a requirement then I'll do it, no complaints. Chasing nice-to-haves is how the project explodes in complexity.
Which btw, is what ipv6 did. They just needed to enlarge the address space, instead it became a whole redesign that was not only harder to adopt but also inherently more complicated than v4 (aside from removing fragmenting). So I wouldn't even say it's the right thing, it's just what someone else wants. Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.
It wasn't a whole redesign though? It has an identical network model to v4, routing and address assignment work the same way, it works over the same L2 links as v4, and L4 protocols like TCP and UDP all work the same. DNS is the same. The socket API is the same. Link-local addresses exist in v4 too, and v4 even had router advertisements already before v6 was even out. How is it a whole redesign?
> Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.
This is, of course, impossible, because v4 only has 32 bits of space for src/dst addresses. You can't cram more than 32 bits into 32 bits. If it was possible we wouldn't have needed v6 in the first place.
#1 is that they redid all the routes. v4 routes don't carry to v6, it's a separate network.
The other things you're naming aren't L3. But they're still different for v6 because of the split network.
There's a lot of other stuff that makes it not a seamless cutover. Randomly-assigned addressed, ULAs, no NAT by default, and all the other v6 extensions.
What they could've done (and maybe will do) instead is just make a new thing with a larger address field but keep the rest the same.
They do carry into it though. My v6 packets to 64:ff9b::192.0.2.0/104 go to 192.0.2.0/24, and so do the ones to 2002:c000:200::/40. (And importantly the replies come back too, or would do if I wasn't using one of the v4 documentation ranges as an example.)
Making a new thing that changes nothing but the address field size won't give you a seamless cutover, because there's no seamless way to use addresses bigger than 32 bits with v4. (If there was then we wouldn't have bothered with v6 in the first place, we would have just used whatever that method was!)
Nothing much else has really changed in v6 -- v4 has ULAs and doesn't use NAT by default either, just when under address space exhaustion. The randomized addresses are a thing, but making a new protocol without them isn't going to produce something that's any easier to switch to, nor any more compatible with v4, than v6 already is.
If I turn on v6, it should be exactly the same aside from the packet format. I still have 1.2.3.4/32, there's still NAT, bans/rep preserved, same routes. That would be such an easy decision, nobody would hesitate.
Meanwhile, DNS and such would need to be upgraded to support 128bit addrs, but they'd still work with the old ones too, so again easy decision. Then once it's safe, any ISP short on addresses can start handing out /64s.
I know there are also v4 to v6 maps, but that's not default and is forever limited to 32-bit.
And it is. That's exactly how deploying v6 works. In fact, even the packet format stays the same, which means you don't lose the ability to talk to peers that require the old format -- people would do more than hesitate if that wasn't the case.
But you understand that after ISPs get short on addresses and start to hand out /64s, it's not going to be exactly the same afterwards, right? You'll have to actually use that /64 and the updated DNS and stuff.
Because we hit that point twenty years ago. We're long past the "everything looks and works in exactly the same way (so only the 32-bits of addresses in v4 work)" stage and deep into the "ISPs hand out /64s" stage. There was a point where v6 deployment just meant that you turned it on and nothing else at all changed, but at this late point in the game it also involves using those new addresses. We already took the approach you're asking for here, we just didn't stop at the beginning of it.
So there was a time when if I enabled ipv6 on my router and PC, it meant I'm still behind NAT, my public and private IP addresses are the same (except mapped onto v6), my DNS is the same, and all packets take the same routes?
I'm too young to remember, but I've dealt with old routers and PCs, don't recall that ever being the default. If it was, they took the second step too early.
Btw, there's also a difference between dividing up the existing blocks vs handing out new ones.
To clarify, my private ip is 192.168.1.3, public 1.2.3.4, and going to v6 I get ::FFFF:192.168.1.3 and ::FFFF:1.2.3.4, and no additional addresses
Oh my god are we back to trying to cram 8 bytes of data into a 4 byte field? You’d think people on a site called Hacker News would understand basic arithmetic.
"ipv6 packet format" means 16 byte addr. Don't talk down to people.
You are right but 8 bytes into 4 bytes sounded more on illustrative in my head. And while I try to make a point to be kind to people who do not know things, if you choose to express a clearly nonsensical opinion in such strong terms, on a forum that has discussed to death how you cannot cram more addresses into an IPv4 header, and something you can check for yourself so easily, yeah sorry you deserve a terse response of that’s not how bytes work. You did not bother to do 60 seconds of education before spouting this tired nonsense.
Seems like you misread. I said the compromise should use the ipv6 header, not ipv4 header. Discussed already with someone else here.
No, it's not my job to file bug reports and wait for $randomcorp to fix it. I'll just use v4, thank you very much.
If this isn’t your job to build networks or networked services then this comment isn’t aimed at you. If that is your job then you are neglecting a part of your job.
This is like an electrician saying it isn’t my job to install ground circuits because appliances shouldn’t get ground faults. Or a consumer saying it isn’t my job to install ground circuits because I am not an electrician.
I do not agree with you at all and I think your analogy is wrong as well. For a VPC I'd never use v6 unless an application is explicitly requires it.
I recently set up infrastructure where all VPC communication is happening over IPv6. The only part that doesn’t is IPv4 communication with Docker but that’s because Docker + Kamal doesn’t have good support for it yet but work is very much ongoing for it. IPv4 was set up along side it but is not actually used. This took maybe minutes, if that, of additional effort. It runs a mature production project. And like chances are you are smarter than me so what exactly is your excuse?
I don't do work that could complicate my life. KISS is a very important principle.
I assume you don’t use passwords or set up encryption because that is not simple either.
If token ring worked, was easier to set up, had better compatibility, and had negligible downsides, then yes I would run a cluster on it without a second thought.