Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning.
> but the point that there could be an interoperable version of a next generation IP and IPv4
Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms.
You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)
Is this some kind of attempt at gaslighting? If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet. I recommend you read the article I posted, and see how different things could have been, and how completely botched IPv6 rollout has become, that it is just not taken seriously except by some die hard cultists and mobile/telco (which can be done because they pretty much get full configuration of your networking stack).
I guarantee, we will be having this same exact discussion 10 years from now. And then so on, and so on.
The v6 addresses are made up of the network prefix (2001:db8:2d4f, basically an opaque string like 203.0.113.45+192.168), then the subnet ID (1, 2) and then the host ID on the network (1-3 and 1).
When you look at 2001:db8:2d4f:X::Y, it should be pretty easy to see that it's host Y on subnet X, under your prefix which is the same for your whole network. Even if it's 2001:db8:2d4f:X:YYYY:YYYY:YYYY:YYYY it's still the same thing, just with more characters.
Weirdly, the version field is actually irrelevant. You can't determine the type of a packet by looking at its first byte; you must look at the EtherType header in the Ethernet frame, or whatever equivalent your L2 protocol uses. It's redundant, possibly even to the point of being a mistake.
I mean, yes, in practice you can peek at the first byte if you know you're looking at an IP packet, but down that route lies expensive datacenter switches that can't switch packets sent to a destination MAC that starts with a 04 or 06 (looking at you, Cisco and Brocade: https://seclists.org/nanog/2016/Dec/29).
Why are you casting to sockaddr_in/6? The whole point of that system is that you can just pass around the sockaddr* without even needing to have a definition for sockaddr_in or sockaddr_in6. All of the socket API functions accept sockaddr*, and if you need to get the IP or port out then you use getnameinfo(), which also takes sockaddr*. There should be little reason to ever cast to either of those types in normal use. (I can think of one or two cases where you might, but they're not common.)
Having to deal with the separate socklen_t is mildly annoying, but you can just make a little struct that holds both.
Both of those articles are actually wrong. They say "if an unknown packet arrives from the outside interface, it’s dropped" and "While it is true that stateful ingress IPv4 NAT will reject externally initiated TCP traffic" respectively, but this is in fact not true for NAT, which you can see for yourself just by testing it. (It's true for a firewall, but not for NAT.)
The biggest security-relevant effects of NAT are negative. It makes people think they're protected when they aren't, and when used with port forwarding rules it reduces the search space needed to find accessible servers.
I agree it can be a useful tool in your toolbox sometimes, but a security tool it is not.
v6 mostly is just v4 with more bits, and it has a reasonable migration path from v4 too. I don't think a more reasonable migration path is even possible given the constraints of v4.
About the only thing new in v6 that's not already in v4 is SLAAC, which isn't very complicated. Routing works the same, the addresses work the same, DNS, TCP, firewalling etc all work the same. If anything they removed complexity by dropping broadcast and making NAT unnecessary.
People just have some very weird misconceptions about v6, and will frequently argue that e.g. it was badly designed for not doing a thing that it does actually do, or for not doing something impossible.
The biggest thing is all the v4 addresses are no longer valid in v6. They had a choice and went with making a separate parallel network with new routes. This means DNS DHCP etc work similarly but are completely different, and the separation between DNS v4 and v6 of course is never clear in any router UI, network config file, etc. And the routes themselves are different.
SLAAC itself isn't complicated, but it means introducing multiple kinds of addresses, which is complicated. Privacy addresses were the latest thing. The history of this has left the defaults in a wacky state, like I got a new router and idk what to expect if I enable v6 on it. Even disabled v6 on my laptop cause idk what it'll do when I join someone else's network. Default should've just been DHCP+NAT from the start, not a loaded gun aimed at foot.
And SLAAC means random addresses that are human-unreadable. "Just use DNS" but nah, nobody will do that.
::203.0.113.42 (tunnels to 203.0.113.42 over v4)
::ffff:203.0.113.42 (opens a v4 connection via an AF_INET6 socket)
64:ff9b::203.0.113.42 (translates to v4 at nearest NAT64 point)
What are these then? Also, it's not like they had a choice here. v4 is hardcoded to 32 bits, so the option of making a single network with a bigger address size wasn't available.
I think I can count that as falling under both "something it already does" and "something that's impossible".
Your laptop will just get some IPs as appropriate for the network it's on, and then it'll use them. You don't need to think hard about it.
reply