Dagger2

The performance hit for running an emulated CPU would be significant, to the point that it wouldn't really be the same argument.

I was thinking more along the lines of network namespaces -- although actually, I should have been thinking of TUN interfaces. Any packets sent into one of those are delivered to the attached program, which can do what it likes with them. Those are usually used by e.g. OpenVPN for L3 things, but nothing stops a program from handling the L4 headers.

Thanks Claude. But maybe we should avoid normalizing ND proxy, lest we end up with ISPs that think it's okay to not provide delegated prefixes? We already have some doing that now; we don't need more.

Note that RFC 7278 doesn't prescribe ND proxy use for the mobile network case. Mobile networks provide the /64 over a point-to-point interface, so they can simply put the /64 and their own address on the LAN interface and it'll work fine, as described in the examples at the end of the RFC.

There's nothing stopping you from giving each stack its own IP, making the kernel only responsible for routing.

I don't think it's a good idea to put more of the stack than necessary into each individual program though, because then you're reliant on each program implementing everything correctly and you have to worry about bugs and security issues in every single program you're running rather than just in the kernel.

Considering that even something as simple as opening a socket (which involves calling one function to give you three numbers which you pass unchanged to a second function) is largely a clusterfuck in existing programs, I don't trust them to implement the whole TCP stack.

> It doesn't.

...it does. You can spend five seconds in tcpdump to see that it does:

    $ ping6 fe80::506c:e9ff:fe08:9ba3%eth0

    11:58:48.741688 d6:57:10:b8:52:77 > 33:33:ff:08:9b:a3, ethertype IPv6 (0x86dd), length 86: fe80::d457:10ff:feb8:5277 > ff02::1:ff08:9ba3: ICMP6, neighbor solicitation, who has fe80::506c:e9ff:fe08:9ba3, length 32
    11:58:48.742459 00:23:6e:5b:b8:2b > d6:57:10:b8:52:77, ethertype IPv6 (0x86dd), length 86: fe80::506c:e9ff:fe08:9ba3 > fe80::d457:10ff:feb8:5277: ICMP6, neighbor advertisement, tgt is fe80::506c:e9ff:fe08:9ba3, length 32

Notice how a) it's doing NDP, and b) the link-local is fe80::506c:e9ff:fe08:9ba3 while the MAC is 00:23:6e:5b:b8:2b? The "506c:e9ff:fe08:9ba3" part of the address isn't being treated as a MAC address by the protocol -- it's just some opaque bytes.

Yes, those bytes can be picked by looking at a MAC address, but that's only one way to pick them and the protocol doesn't treat those bytes as having any particular significance, and in particular it never assumes they contain a MAC or tries to use them as an actual MAC, so it doesn't qualify as a layering violation.

Huh? No, the MAC was never a part of the publicly-visible v6 address.

I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.

Get me onto the network that's on the WAN interface of your router, disable the firewall on it, and I will.

How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.

It is true. NAT only changes the source address used for outbound connections, it doesn't deny inbound ones.

You don't need to take that on faith either -- you can just test it.

No, the reason is that people incorrectly believe it provides security.

It doesn't actually do that.

It was engineered like that. It was known from the start that having a flag day wasn't possible (https://datatracker.ietf.org/doc/html/rfc1726#section-5.5):

  We believe that it is not possible to have a "flag-day" form of
  transition in which all hosts and routers must change over at
  once. The size, complexity, and distributed administration of the
  Internet make such a cutover impossible.

And when they picked a design, it indeed didn't have a flag day (https://datatracker.ietf.org/doc/html/draft-hinden-ipng-over...):

  IPng is a new version of IP which is designed to be an evolutionary step
  from IPv4.  It is a natural increment to IPv4.  It can be installed as a
  normal software upgrade in internet devices and is interoperable with
  the current IPv4.  Its deployment strategy was designed to not have any
  "flag" days.

If saying "we can't have/didn't do a flag day" in the design documents, and then not having a flag day, isn't enough to stop you from arguing that v6 should have been engineered without a flag day, I have to wonder what v6 could possibly have done to make you happy with it.

NAT is accepted for transition purposes; for example NAT64 makes it trivial to connect from v6-only clients to v4 servers, and is used by some large ISPs (e.g. T-Mobile in the US) to avoid running v4 inside their access network.

But v6 _is_ backwards compatible though? It's got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how is this not backwards compatible? You could make a reasonable argument that it has too many backwards compatibility methods, even.

> The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative

If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.

If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.

All you've done there is reinvent v6 with a combination of dual stack, NAT64 and 6to4, plus add a flag day.

You haven't fixed any of the problems involved in deploying v6, and you added a step that was known 35 years ago to be impossible on the Internet. This isn't a useful contribution, it's just a waste of time that you could have spent on doing v6.

SLAAC-generated addresses will stay the same so long as the prefix and your MAC address stay the same, so there should be no need to do static leases.

Also... service discovery. Needing static addresses is a kludge.

People running servers don't seem to be reliably capable of making sure that either pMTUd works or isn't needed on their network, so... it is indeed broken on random servers.

We've mostly decided to go with TCP MSS clamping rather than using the minimum MTU, which is still nonsense but it's nonsense that we already decided to go with for the same problem in v4.

Of course, I don't have enough info to tell if this was the problem or if it was something else, or a mix of the two, but pMTUd does seem to be a leading cause of "fails to load for some weird reason" problems.

That's basically no burden at all. If we cut the address length down to increase throughput, we would get a one-time increase of about 0.8% -- but consider how much faster Internet connections have gotten over the past 30 years. They've improved by about 0.8% per week on average. You're worrying about something that's smaller than one or two weeks of natural progress in Internet connection speeds

Rather than trying to minmax the address length, it makes more sense to sacrifice a few bits per packet to the addresses, wait a week or two on average to get the lost throughput back, and then spend those bits elsewhere to make other things easier. (For example, avoiding NAT is an obvious one, but even just "everything is a /64" removes the need to ever need to think about the size of a network.)

If you can spend a few address bits to make something easier elsewhere, that's a good trade. Maybe start worrying if the addresses were a kilobit long or something, but they aren't even close to that.

There were always expected to be v4 hosts on the Internet effectively indefinitely. That's not a failure condition for v6.

"There are a couple of v4-only hosts out there somewhere" would be kind of irrelevant if most ISPs stop bothering to provide v4 service.

Except you are, because all the same work needs to be done.

> You can use the 8-byte addresses earlier if you want

You can't have both this and "The 8-byte phase only starts when v4 has been abandoned" simultaneously. Decide whether you want a flag day or not and then be consistent about it. (And when you're deciding, bear in mind that flags days on the Internet are impossible.)

  $ wget -4 https://github.com/HackerNews/API
  Resolving github.com (github.com)... 140.82.114.4
  Connecting to github.com (github.com)|140.82.114.4|:443... failed: Network is unreachable.
  $ git clone https://github.com/HackerNews/API
  Cloning into 'API'...
  remote: Enumerating objects: 142, done.
  remote: Counting objects: 100% (53/53), done.
  remote: Compressing objects: 100% (21/21), done.
  remote: Total 142 (delta 38), reused 32 (delta 32), pack-reused 89 (from 2)
  Receiving objects: 100% (142/142), 67.87 KiB | 668.00 KiB/s, done.
  Resolving deltas: 100% (39/39), done.

Seems to work fine.

> Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4

Which is great, but all of these things are 4 bytes only. You need a separate set of tables etc for the longer addresses. Also v6 already shares all of these things and works with them instantly when working with 4-byte addresses, so this isn't new.

> Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade.

Yes, like with v6. I would expect people to find endless excuses to never do the patch or replace part or to just refuse to configure their gear to enable longer addresses, like they do with v6.

All this leaves me wondering why this approach is bad when v6 came up with it but good when you came up with it.

I think the span would be about the same, or smaller even, if you limited yourself to a granularity of 4 bits for v6. Allocations are often rounded to 4 bits in v6 because it correlates to exactly one character of the v6 address.

I'd also like to note that being worried about accidental overbanning in v6 but then being dismissive of it in v4 is a double standard.

Do I? I don't have v4 on this machine and I can reach GitHub, so that appears to be untrue. Also GitHub would need to continue having v4 so that v4 users could reach it, so it's untrue from that perspective too.

At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much work it is or you're just outright ignoring it, but only for your own proposal and not for v6.

Let's assume that's true... so what? That doesn't tell us anything about how long migrations like this normally take.

Windows, Linux, OSX, Android and iOS all ship with v6 enabled by default out of the box, so it's already turned on without you needing to think about it. You have to deliberately go out of your way for this not to be the case.

> If it were as easy as you're saying, all those things like Github would already at least support v6.

This isn't the "turn it on" stage, it's the "people can start putting something besides 0 into that last byte" stage.

People are at work during the week, and work networks have a lower average deployment of v6 then home networks do. As evidence, you can also see the impact of holidays and COVID-19 lockdowns on the size of the dips.

If we're talking tangible, real-world threats in existing ISPs, then NAT is doing nothing to protect you. In fact it's doing the exact opposite, because without NAT you wouldn't be able to connect out from your network.

Even if you want to ignore the fact that most attacks arrive via outbound connections and restrict the discussion to just inbound ones... remove NAT and the exact same set of people that could connect to you before can still connect to you, so it's doing nothing for your inbound connections.

Google's stats claim that it's 10-20ms for many countries, for example both the US and Canada show the latency impact of v6 as being -10ms. This is per round trip too -- between the connection handshake, congestion window slow-start and serialized requests it adds up to something significantly bigger than a few hundred microseconds.

> let's not forget IPv6 is two separate island because two tier-1 carriers refuse to peer (Cogent & HE).

The Cogent island must be very small, because I'm single-homed on HE and had actually forgotten about that.

Or perhaps v6 isn't split into two separate islands after all, and this is just yet another weird claim people make about v6 that doesn't match reality.

I don't have to imagine, because that's how things are right now for the billions of people using v6, and it's fine.

I'm in Europe and I use a tunnel from HE for v6. I feel like that's something I would have noticed if it was as widespread as you make it sound.

Try `ip link set mtu 1280 dev eth0` (or equivalent for your OS).

pMTUd breakage exists on v6 just like it exists on v4, and requires workarounds just like it does on v4. I get the impression a lot of people are applying a workaround on v4 but not on v6, then blaming the resulting failures on v6 without bothering to do any troubleshooting to figure out what's actually wrong.

I've heard plenty of accounts from people (and these were techy people even, not just the ones who only go to Facebook and think that's the Internet) who lost v4 and didn't even realize for days, so I'm not sure how true that is... but more to the point, when we say an ISP is v6-only it usually implies some form of backwards compatibility method for reaching v4 hosts over the v6-only service.

Commonly that's NAT64, which maps v4 into the v6 address space. The resulting service is v6-only (you only get a v6 address and have to talk v6 to the ISP) but you can reach v4 servers by talking to the v6 addresses to which they've been mapped.

I have no v4 on this machine. I'd disable the v4 stack on it if that was a thing Linux could do, but as it stands it's just sitting there doing nothing.

The thing you're claiming is not going to happen is something I'm already doing.