Dagger2 · HackerTrans

12 dni temudiscuss

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.

Dagger2

17 dni temudiscuss

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.

Dagger2

18 dni temudiscuss

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.

Dagger2

18 dni temudiscuss

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

Dagger2

18 dni temudiscuss

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

Dagger2

18 dni temudiscuss

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.

Dagger2

18 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

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.

Dagger2

19 dni temudiscuss

You have to do that with range bans in v4 too, since you have no idea how big the pool of addresses a user can pull from is -- and with CGNAT in the picture you're kind of doomed to banning legitimate customers on v4 no matter what you do.

Dagger2

19 dni temudiscuss

Data exfil is basically impossible to detect/block with IPv6? What? No. It's no easier or harder than it is in v4.

I'd also question the Rube-Goldberg-ness part, given how straightforward v6 is compared to the contortions we go through to get v4 to work in the face of address exhaustion.

(I guess I'll just ignore the systemd rant.)

Dagger2

19 dni temudiscuss

What ridiculous overdimensioning? L2 addresses are 64 bits, and L3 has to be bigger than L2 because L3 acts as an aggregation layer over L3. From staring at RFC 3194, I'd say the minimum size for L3 is about 80 bits.

v6 is 128 bits, which is the smallest power of 2 that's bigger than 80 and is only an extra 48 bits. Is that really enough to qualify for a claim of "ridiculous overdimensioning"? Especially when we really, really don't want to discover down the line that we made it too small and now need to migrate to another L3 protocol?

I get that the resulting number of IPs is big, but... so? Everything deals with the 128-bit long addresses, not the 2^128-entry long list of IPs. There's no need to care about the latter, just like there's no need to care about the number of potential RSA2048 keys or whatever.

comments