Dagger2

So anybody without the new stack loses access to your site, because they're querying for the A record that you removed. How is this "a gradual migration" or "expanding the address space without inventing a new stack"?

Nobody will want to switch to the new stack if it means instantly losing clients that don't have the new stack yet, so the only way to switch would be to coordinate everybody on the planet to switch simultaneously. This is as far away from a gradual deployment as you can get. A flag day for the Internet isn't viable, no matter how much you shout it.

These are not edge case questions we're asking here. They're fundamental questions about how to expand the v4 address size without ultimately doing the same things v6 had to do. You don't need to design the full spec, but you don't get to argue we should replace v6 if the best alternative approach you can come up with works the same way v6 does and has the same limitations v6 does.

So you haven't solved the incompatibility at all. Your v8 requires the client, server and everything between them to support v8 or it has to fall back to using v4, just like v6 does.

> There are two groups that should update to v8 in order to be fully functional: users' OS net stack and ISPs' infra.

A lot of software hardcodes AF_INET or sockaddr_in, and so can only handle 32-bit addresses. Also, there's the end-user's border router, and any internal routers on the client or server side, and the LANs on the client and server sides. There are databases, protocols and data structures that store IP addresses. Any attempt to use v8 with any of these will break them even if half of the v8 address is set to zeros, because they can't handle the 64 bits of a v8 address. They'll either reject the address or it'll corrupt the next 32 bits of memory. A seamless update to the OS net stack and ISP infra isn't sufficient to make them work with v8, because they'll still be limited to 32 bits.

I understand that your core idea is to say that a subset of the v8 address space maps directly to the v4 address space, so that you can convert that subset to v4 to work with the above things. This idea itself isn't bad; it's a perfectly sensible backwards compatibility mechanism that's used by v6 too. You're correct that it allows just that subset to be passed to an application over an AF_INET socket, used to send/receive v4 packets to the corresponding v4 address and so on. This approach is seamless if you stick to exposing the addresses as v4 addresses rather than as v8, because then they could be handled the same way v4 addresses are.

The problem is, you can only make it seamless by hiding the full v8 addresses and pretending they're v4, which can only be done for a small fraction of v8 addresses. What about the rest of them? You haven't actually extended v4's address space past 32 bits, so if you want to use v8's extra addresses you'll have to expose the full v8 addresses as v8 addresses, which is no longer seamless because that's a whole new stack the user and their software has to deal with.

If it was possible to seamlessly switch to bigger addresses, there would be no reason to restrict yourself to the subset of v8 addresses that end in :0:0:0:0 in the first place. You're doing that because using bigger addresses isn't seamless, which is an acknowledgement that a seamless upgrade to bigger addresses isn't possible. It would be if they were the same size, but then you've failed your goal of extending the address space.

So no, you can't claim this upgrade would be seamless unless you can remove the part that's only in there because it's not.

> If a single node is still at v4, all the communication continues v4-like (the v8 nodes send 0 at the ls32b).

If a single node is still at v4, that node will drop your v8 packets even if you set the ls32b to 0, because it doesn't understand the v8 packet format in the first place. This node will prevent you from switching to v8 even if you stick with the limited v4-compatible subset of v8 addresses.

> it will be SEAMLESS for the user, without the awful v6 UX that we have now

That "awful v6 UX" is the same UX you'd get with v8 if you tried to use the expanded address space. Or, if you limited yourself to just the v4-mapped subset of v6 then it would be just as seamless as v8 is. This should be obvious, because you already lived through OSs adding support for v6 in their net stacks and it was seamless so long as you stuck to the part of v6 which maps directly to v4. Which is what you were asking for, wasn't it?

So basically, instead of extending the v4 address space you're going to make a new stack and everybody needs to switch to it to be able to communicate with v8. That's the exact thing you said you weren't doing.

> If it receives 1:2:3:4:0:0:0:0, that's v4 and continues as such

1:2:3:4:0:0:0:0 isn't v4, so it can't "continue as v4"... perhaps you meant that a router somewhere converts the packet to a v4 packet, but this is still only the v8->v4 direction. How do you map v8 into v4 so that the destination can reply?

> The update from 32-to-64 will be massively pushed to all kernels and userspaces in a short time so to shorten outages.

Right, add support for the new stack everywhere like we did with v6's 32-to-128 update. But just saying that it'll be done in a short time doesn't mean it will be.

Port forwarding requires a port forward rule that matches the inbound connection. If there's no such rule... NAT won't stop the connection, it will just ignore it.

If no other aspect of your setup blocks the connection, it'll be successful. If you were deploying NAT because you thought it would function as a firewall then this part is probably not intentional.

Dots weren't an option, because then the syntax would overlap with DNS hostnames. "2001.db8.c.d.e.f.g.ca" is a valid host under the .ca TLD.

Nope, not at all. Everything I said is true. v6 supports deploying in the way described in that article, and you can do it today if you want.

If you don't want to deploy v6 like that, consider why -- because the people who live in the world described by that article will also have the same reasons as you to not deploy it that way.

> If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet

No, that argument doesn't hold. v6 can give tangible relief even while v4 is an important mainstay of the Internet. You only have to listen to the people doing CGNAT, or the people turning on v6-mostly and seeing their v4 address use drop by 75% to hear examples of that.

Deployments of v6 reduce the pressure on v4, because they allow us to deploy new networks without needing v4 and because migrating existing networks frees up v4 that can be repurposed. This is also a benefit that's making v4 more viable that it would be without v6.

Plus you're making assumptions about the time needed to replace the Internet's L3 protocol. It's nice to fantasize about finishing it in 10 years, but that doesn't mean that finishing it in 10 years is realistically possible. Deployment of v6 is ongoing and v4's importance is dropping over time; you can't know what the ultimate impact of v6 will be until we're finished deploying it.

There was always going to be a long tail of v4-only hosts, no matter what we did. That's why v6 has a large number of compatibility methods for dealing with them (yes, including the method described in the linked article). It wouldn't be possible to deploy it at all if it didn't.

Well, actually it will. In fact, even correctly configured NAT won't stop connections into your network.

On top of that, it lulls you into a false sense of security, so you confidently think it's protecting you even when it isn't. At least not having NAT makes the actual state of your network clearer.

That's just computers in general, isn't it?

You're looking for one of these: https://ipv6buddy.com/

Okay, so you've figured out how to make v4 addressable from v8. Good job. That lets v8 hosts address a v4 host via a v8 address.

How are you going to make v8 addressable from v4? Because you need to do this too for communication to work.

Also, you've made v4 addressable from v8, and you're about to explain how you make v8 addressable from v4... but that's just addressing, i.e. identifying the right host. How are you going to actually send packets from v8 to v4, and also from v4 to v8?

> The IPv6 critics shout out that this would be a viable solution.

But they never bother to understand enough of the problem to contribute anything useful. Either they can't come up with something that works, or they come up with something that they didn't realize v6 already did.

That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.

The most common is more like /56, which is unfortunate because it means you have to deal with "2001:db8:2d4f:61XX::". It's still easy enough to read the subnet out of :6101:, :6102:, :6103: etc, but it does mean every address is longer :(

> And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?

Somewhere around mostly. Windows, OSX, and network-manager/dhcpcd/systemd-networkd on Linux all enable RFC7217 (uses a hash of your MAC and a secret value), temporary addresses (random addresses used for outbound connections) or both by default. Either of these will prevent people from seeing your MAC when you connect to them.

I'm not sure about mobile devices. I'd expect temporary addresses there, but also MAC randomization is a thing these days which would do the job too.

Notably absent from that list is Linux's in-kernel SLAAC client. Client-oriented distros often enable tempaddrs by default (or they install one of the network daemons that does it), but server-oriented distros tend not to.

But there is a clean migration path to v6: you deploy it. How much cleaner can you get?

Perhaps you could use 41, the value already associated with doing this.

(What's up with people constantly suggesting that v6 should do things that it already does?)

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.)

But note this only gives you access to v4 addresses, not to v6 ones. You do need v6 internally too.

Just use it. This reaction is coming from a lack of familiarity, not from it actually being hard.

Here's some roughly equivalent IP addresses:

    203.0.113.45+192.168.1.1 ↔ 2001:db8:2d4f:1::1
    203.0.113.45+192.168.1.2 ↔ 2001:db8:2d4f:1::2
    203.0.113.45+192.168.1.3 ↔ 2001:db8:2d4f:1::3
    203.0.113.45+192.168.2.1 ↔ 2001:db8:2d4f:2::1

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.

  ::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.

They do seem to be making progress on that: https://aws.amazon.com/new/?ams%23article-feed%23pattern-dat...

They've enabled v6 on an average of something like two services per week for the past year... but they have a lot of services.

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 Internet itself is growing, so "50%" does still represent a growing number of users. Also Google's stats are missing half a billion v6 users from China.

The point of L3 is to aggregate hosts into networks, so that routing only has to keep track of network prefixes instead of the individual MAC address of every machine. (The amount of routing updates needed for the latter would scale as something like O(hosts²) which just wouldn't work for large networks, let alone the Internet.)

The aggregation necessarily "wastes" L3 addresses, so if you think you'll have enough machines to justify an L2 address size of n bits then that also implies needing an L3 address size of n+m bits, where m is a number that represents how densely packed your L3 address space is. Anything smaller than that will be too small to handle the full extent of your L2 address space.

RFC 3194 (https://www.rfc-editor.org/rfc/rfc3194.html) suggests we'd want something like 80 bits to handle EUI-64. 128 bits is the next power of 2 up from there.

> It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address [...] Sure, it avoids having to implement ARP

You're thinking of SLAAC, which picks the address by slapping the MAC/EUI-64 into the right-hand 64 bits, but this is just a convenient way of picking the address bits. There's no special significance to those bits and you still need to do ARP.

> I'm pretty sure that if we'd just gone for "a couple bytes extra" we'd have long been completely over.

We still can't get people to stop hardcoding socket(AF_INET, ...) or manually crafting sockaddr_in structures. This is the minimum amount of work that will always be needed, regardless of how many extra bits are involved, and even this part hasn't been quick.

There's no risk at all if you're using your own allocated prefix, because those are managed by IANA/RIRs/LIRs to not overlap.

Incidentally, if you find yourself experiencing an RFC1918 clash, one simple way of fixing it is to use NAT64 to map the remote side's RFC1918 into a /96 from your v6 allocation. You can write the last 32 bits of a v6 address in v4 format, so this leads to addresses like 2001:db8:abc:6401::192.168.0.10 and 2001:db8:abc:6402::192.168.0.10, which don't overlap from your perspective.

(If you wanted something simpler to type you could put them at e.g. fd01::192.168.0.10... but then you do start running the risk of collisions with other people who also thought they could just use a simple ULA prefix.)

Adding two bytes would have been just as much work as adding 12 bytes, and would have left us with too few addresses rather than too many. The MAC address space is now 64 bits and L3 is necessarily less dense than L2, so 128 bits is the smallest power of 2 where we can be reasonably sure we won't end up with too few addresses.

Considering how hard deploying a new L3 protocol is, we're only going to get one shot at it so it's a lot better to end up with too many addresses rather than too few.

I don't think that RFC is quite correct. Both types are set up the same way (the only difference is whether the dest IP of a packet is 6to4 or native) and it was designed to be unmanaged in the scenario we're imagining here. Windows machines configured it automatically if they received a public IP, for example.

But if it is, it's basically saying that people really didn't want to take this approach.

> To whoever wishes the IETF had thought of ipv4x, I'll bet the IETF thought of it and decided they wanted to start with a clean slate in v6.

They obviously did think of it, since v4x and 6to4 take pretty much the same approach. Both of them put extra address bits into the start of the payload. Both of them indicate they've done this with some flag in the header. Both of them send packets through unmodified v4 routers. About the only difference is that v4x consumes the entire 128-bit address space while 6to4 sits in a /16.

Everything that you've said can be done in v4x can also be done with v6 and 6to4 (possibly combined with some of the other transition options), and it doesn't make it any easier either unless you handwave away a bunch of the work that needs to happen.

> But v4x at least had a way to gradually defrag things once it was fully adopted. If you're suggesting staying on 6to4 forever, that would've meant continuing to use vanilla ipv4 between subnets.

6to4 prefixes can be routed natively without needing to be tunnelled inside v4 packets, so you don't need to do that. That's how ISP-side 6to4 would work, but you could also do the same thing in the DFZ. If you're announcing v4 addresses you could also make a BGP announcement for the 6to4 prefixes that correspond to those v4 addresses, allowing packets sent to those prefixes to reach you natively instead of getting tunnelled. Presumably this is about the same as what you were imagining v4x would have done to get rid of vanilla v4.

I don't see how you could gradually defrag things in v4x, unless you include ways that would also work with 6to4.

> Many v6 proponents seem to think your device on any random guest network should be able to receive inbound connections, enabling true P2P everywhere, which implies having no router firewall

A few do, but it's rare. The main point is that the IP of a machine should be the same no matter where you are in the network, and nobody should be using clashing address spaces. None of that implies no firewall.

NAT features heavily in the v6 transition. It's how you handle connectivity to and from v4 hosts that can't do v6. There's just no need for it between two v6 hosts.

Why do you think sysadmins and end users wouldn't need to deal with v4x?

I understand it in the situation where you aren't using the expanded address space, because then you can just present v4 addresses to the sysadmin/user and they don't need to do anything differently. But... then you don't get any expanded address space.

If you want to actually use the expanded address space, then they need to deal with it in the same ways and for the same reasons they need to deal with v6. There doesn't appear to be any aspect of v4x that would alter or avoid that need.

So your suggested ordering is for everybody to add support for your v4x addresses in every OS, device, software, API, protocol etc, and then only allow them to make use of the extra address space after everybody else has also added support everywhere?

To be clear, you don't need to change much in order to have v4x without using the extra address space... but starting to use that extra space means changing everything in the same sense that starting to use the extra address space from v6 means changing everything.

At least with v6 you don't have to wait for the rest of the world to be ready. You can start using it straight away. What you're asking for would give people _less_ motivation to do the work, so the "the world only becomes ready" problem gets worse. How is this better?