Dagger2

It doesn't rely on anycast. The ISP gives you a v4 address from which you generate the 2002:: prefix, and when talking to another 6to4 network you send the packets directly from your v4 address to their v4 address. Inside those packets is an extra 80 bits of addressing that the source and destination networks can use.

Or, ISPs that want to do so can use one of their own v4 addresses to get the corresponding /48 6to4 prefix, split it up and hand that out to customers while handling the v4 packets themselves.

Looking at the 15 or so years afterwards shows native v6 deployment at 50% of the Internet, and approximately nobody interested in deploying 6to4 outside of these posts where people keep reinventing it but with different names and an assertion that if only the IETF had thought of this, everybody would have loved it. I think that's decent evidence that they wouldn't.

There is no extension mechanism built into v4 for longer addresses.

Of course v4 is going to be with us for a long time. We can't make existing v4-only devices go away because we have no way to enforce a flag day on the Internet, so there was never any way around that. But you can run networks without v4 just fine if you want to (including the ability to connect to v4-only hosts, or let them connect to you), so you can in fact turn v4 off on your network.

> That's an address-space expansion, not just a weird way to do NAT

You said the server would have a proper v4 address and the client would put its RFC1918 address into an extension header. You don't get any extra address space that way. But if you do try to give nodes 8-byte addresses... you immediately get the same situation we have in v6, because nodes and software that only know how to deal with 4-byte addresses won't know how to deal with your 8-byte addresses. You'll end up having to use the same approaches v6 uses to deal with the same problem.

> I have no doubt the IETF could have embraced NAT as a transition technology quickly obsoleted by broad adoption

What do you think RFC 2765/2766 are about? Or RFCs 6144~6147?

We did take that path. If you zoom in on the start of https://www.google.co.uk/intl/en/ipv6/statistics.html you can see that 6to4+Teredo was more common than native until 2010. (Okay, that's combined with Teredo, but I think probably 6to4 is the majority of it because Windows will use 6to4 without needing a registry change or custom application behavior.)

You see it as a special feature with rare usage because it competed with native and lost. People overwhelmingly preferred deploying v6 natively instead of deploying 6to4. Obviously more people would be using it if it was the only option, but if you're trying to come up with an alternative to the way v6 went then "an approach that v6 took but which nobody wanted to use when native v6 was the alternative" might not be a very promising place to start.

If your goal is just to roll out support for v6 addresses without actually using them, then you don't need to change anything about your network to do that. (Remember going from XP to Vista? That added support for v6 in Windows, but you didn't need to change your network for it.) This is the same as your described rollout of support for v4x.

Once the world is ready and your ISP actually issues you with v6, then you need to change some things (I would argue not everything). Again, this is the same as for v4x. The only difference is that in the v4x case, you put this after the end and ignored it.

Ignoring the bit you don't like for one of them but not for the other isn't a fair comparison.

We already did it decades ago, with 6to4. The extra address space is under 2002:<v4 address>::/48.

But like the similar proposals, it fails to avoid a dual-stack scenario.

Note that going from v4 to v6 also doesn't mean changing all your routes and addresses; you just enable it and everything still works. Network components can get updated behind the scenes without user impact. There's no flag day though; ISPs can start using the new address space as soon as they want, rather than being forced to wait until everybody else is ready.

It might get hidden by disabling v6, but not fixed. And if your DNS server fails to reply to an AAAA lookup over v4, that's 100% not a v6 problem.

If you disable the NIC, the problem goes away 100% of the time.

Don't blame v6 for problems with your network.

v4 doesn't even manage one IP per person. It's fundamentally completely insufficient in a world with personal computing devices. Even if you declared every single IP in v4 to be wasted and demanded we repurposed them all, it wouldn't be enough to fix that.

The multicast and reserved blocks total 32 /8s. Before IANA runout, we were going through over one /8 per month, so this would represent less than 2.5 years of allocations. We've already spent decades buying more time for people to migrate to v6; we don't need another 2.5 years that people will just immediately squander.

NAT is not in any way a feature. I'll admit it can be a useful tool in your toolbox sometimes, but otherwise it's just a completely unnecessary complication that breaks things and wastes time and effort. It's not something to be building the Internet on. You want each device to get an IP and you don't want two devices to have the same IP, because that's how machines on the Internet send packets to each other -- which is the entire point of having the Internet at all.

> All of "the global internet" is in 2002::/16, which effectively gives 32 bits of assignable space. Exactly the same as IPv4 [...] the assumption that all routable prefixes are in 2001::/16 as specified

Global allocations are actually coming from the entire of 2000::/3, not 2002::/16 or 2001::/16 (and there's another five untouched /3s in case we need them). So far about 0.2% of it been allocated to RIRs, and most of that RIR space has not yet been allocated to anybody. We're clearly not exhausting it at anything like the rate of v4.

v6 is less complex than v4 in practice due to not needing NAT, and gains us far more than you're thinking. A /48 contains 65k subnets of effectively infinite hosts each, which is similar to a /8 but with no limit on hosts per network, and there are something on the order of a trillion of them in total rather than 256 of them.

Sure there is: use single-stack v6 with NAT64.

What you're describing there is just an approach to store NAT state inside every packet instead of on the router. I'm not sure that's even an improvement on v4, but in any case it wouldn't increase the size of the address space so it wouldn't help with the one thing driving the need for IPv6.

Two 6to4 networks will communicate directly between each other without using a relay, so it will still work for that. Although you ought to be able to use native v6 these days.

If you can't deploy v6 (whether native or 6to4) on the remote side for whatever reason, NAT64 is useful for dealing with conflicting RFC1918. You map each instance of RFC1918 you need to access into different v6 /96s, and then they don't conflict from your perspective. (But like NAT44, it only works for outbound connections; inbound ones need a port forward.)

If your DNS server isn't replying to requests, your DNS server is broken. That has nothing to do with v6.

Plenty of people are switching v4 off. Facebook run basically all of their datacenters without v4. T-Mobile USA use only v6 on their network. Thread only supports v6 in the first place

There are plenty of other places doing the same thing, but these examples alone should be sufficient to disprove "no-one is willing to turn v4 off".

You will certainly need to update applications, because they won't be able to connect to v6 addresses otherwise. 464xlat only helps you connect to v4 addresses. It just means that updating _all_ of your applications is no longer a prerequisite of turning v4 off on your network.

It does exist though. The OS part is 464xlat and the router part is NAT64. You can try the second part out by setting your DNS server to one of the ones listed on https://nat64.net/, which will work with hostnames. To get IP literals to work you need 464xlat, which is currently a bit annoying to set up on Linux.

(Note that using the servers provided by nat64.net is equivalent to using an open proxy, so you probably don't want it for general-purpose use. You would probably want either your ISP to run the NAT64 (equivalent to CGNAT), or to run it on your own router (equivalent to NAT).)

The standard prefix for NAT64 is 64:ff9b::/96, although you can pick any unused prefix for it. ::ffff:0:0/96 is the prefix for a completely different compatibility mechanism that's specifically just for allowing an application to talk to the kernel's v4 stack over AF_INET6 sockets (as you figured out). It was a confusing choice of prefix to use to describe NAT64.

They *are* making progress on it: https://aws.amazon.com/new/?ams%23article-feed%23pattern-dat...

They seem to have been averaging about two services per week for the past year. But they have a lot of services...

There's also the question of whether we should be tracking percentage or number of users -- there's about 3 billion v6 users at the moment based on Google's stats, but 12 years ago there were only 3 billion Internet users in total. Even if the percentage was flat, that would still represent ongoing v6 deployment for as long as the Internet itself is growing.

(As a side note, Google and APNIC disagree significantly on China's deployment percentage -- 6.5% vs 52% -- so there's actually something like another half a billion v6 users not represented in Google's stats which would push the world percentage from ~48% to ~56%, and that "x years ago" stat to 10 years ago.)

Except not really. You can't assign v6 addresses to people, because IPs are picked ephemerally by devices based on the IP range of the network they're attached to.

You need a separate protocol (like HIP or LISP) on top to map the identifier to its current network location, and at that point you're no longer limited by the size of the underlying address space.

It's possible to do NAT without firewalling in netfilter. I gave the rules for it in this comment: https://news.ycombinator.com/item?id=46709150 -- you literally only need the first one for NAT. Inserting it will make netfilter track connections, but you need the other, separate rules to do firewalling based on that state.

Most home routers will ship with those firewall rules in place, because not doing so is a security vulnerability, so in practice you're going to have the firewall, but it's not a strict requirement and routers have been discovered to not have them in the past.

At least with v6 it's more obvious that you need these rules, so it's more likely people will be checking for them.

You can't get a packet from a random store wifi network to your home network when your home network is using 192.168.* (barring something like routing headers, which most routers wouldn't process). You said that yourself in the first part of your post, and I don't think I ever argued otherwise.

> Symmetric NAT 100% stops inbound unsolicited connections to the public IP

No, it doesn't. If it did it wouldn't be possible for routers to accidentally make their web admin or UPnP interfaces available to the Internet.

It doesn't stop connections to your router, and it doesn't stop connections through your router either. It just plain doesn't stop connections, which is why it protects you from 0% of attackers.

No, it might belong to the router. If it does then the connection goes to the router, but if it's set to a LAN machine's IP then the packet gets routed to the LAN machine.

You aren't in control of the contents of inbound packets, and NAT won't filter them to enforce anything about the destination IPs in them either.

There's no inherent ACL in NAT, and adding one would just demonstrate that ACLs can block packets, which we already knew.

> What you’re describing would happen if NAT were completely disabled. You’re just describing an open router

Yep. It also happens when NAT is enabled. A router doing NAT is exactly the same thing as an open router -- it just has the additional property of editing outbound connections to appear to come from the IP of the router itself.

If NAT on its own blocked inbound connections, I would have seen that in my tests.

Source address selection is usually left to the kernel, so that part should be okay. It'll pick a GUA source for a GUA destination unless you've changed the labels with `ip addrlabel`.

I could do it if it was using a routable v4 address too, and I can do it with either RFC1918 or ULA as well (which are both routable, just not over the Internet) if I can get close enough to send the relevant packets. NAT provides no protection against any of these.

You don't normally see many SSH brute force attempts on v6, let alone getting hammered by them. I do see some, but it's mostly to obvious addresses like <prefix>::2, ::3 etc which I don't use, or to IPs you can scrape from TLS cert logs. If you set an ssh server up on an IP that you don't publicize, finding it is hard.

Neither of them prevent inbound connections, on their own or together.

I don't really think that "inbound connections work fine and you're basically just praying that the people that can do them simply won't" counts as being secure, but I'll admit that using RFC1918 does limit the set of people that can do them. If you made that your argument, you'd have more of a point than an argument based around NAT.

They connect to whatever IP is specified in the packet's "destination IP" header field. It's exactly the same behavior as if there was no NAT going on.

The same problem applies to masquerading. Routers are happy to route packets they receive, and NAT (in whatever form) isn't the tool you use to drop those packets.

Well no, it's purely a property of the fact that the packet is addressed to the router.

If the packet is addressed to a machine on the LAN, neither RPF or NAT will protect you from it. "The Internet won't route to private IPs" only protects you if you have private IPs on the LAN, and even then it only protects you from people who can't get access to the network on your WAN interface.

Any way you dice it, NAT isn't providing any protection.

And in this common configuration, NAT does nothing to prevent inbound connections.

The point is that NAT offers no security, so it doesn't make sense to be skeptical about the security of a network just because it doesn't have NAT.

The only way to be confident is to have a firewall, and you can do that on v6 just as well as you already do on v4.