Dagger2

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.

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.

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

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.

If my firewall logs are representative, about 2%.

Why the double standard?

v6 already gives you what you're asking for here: you can turn it on without thinking about it, but actually using the extra addresses from it requires reconfiguring some things (not everything, mind).

Why is that bad when it's v6 doing it, but good when it's your 5-byte thing doing it? Or did you just not think through this enough to realize you were asking for something we already have?

But subnetting in v6 is so much easier than in v4? And it's specifically because of the hex. You don't even need to calculate it, in your head or otherwise, because you just subnet based on characters:

  2001:db8:42:1xxx::/52
  2001:db8:42:2xxx::/52
  2001:db8:42:20xx::/56
  2001:db8:42:21xx::/56
  2001:db8:42:210x::/60
  2001:db8:42:2100::/64
  2001:db8:42:2101::/64

etc. About the only mildly complicated thing is remembering that leading zeros in a number can be dropped but trailing ones can't (i.e. 1 and 001 are the same number, but 1 and 100 are different numbers), but that's something you should've learnt in grade school already.

What's the par time for L3 protocol migrations on the Internet at its current size?

Bear in mind we've never done a project of this complexity and scale before. I'm sure we all wish it had been faster, but how can you possibly evaluate whether this is a failure or not without knowing how long it normally takes?

Why is it less effective on v6? You just ban the /48 or bigger.

Note that even a MAC-derived link-local may not be unique, since the same MAC can be on both networks (e.g. with VLANs, or if you assign MACs to hosts instead of NICs).

Note you can also advertise a ULA prefix without the A flag. The advertisement tells other machines that the IP is on-link, and they can use their own GUA addresses to connect without needing a ULA address of their own.

You could also assign a single address (e.g. fd53::1/128) and advertise the corresponding prefix of fd53::1/128, so you don't even need a whole ULA prefix, just individual addresses. (This is sometimes useful if you use a router you can't configure and it's advertising a DNS server you don't want to use.)

mDNS on link-locals is what makes the "plug computers and printers into switch" case work. It would have been NetBIOS originally but mDNS is how it's done today.

I very much didn't test it, but this patch might do the job on Firefox (provided there's no code in the UI doing extra validation on top):

  --- a/netwerk/base/nsURLHelper.cpp
  +++ b/netwerk/base/nsURLHelper.cpp
  @@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) {
   bool net_IsValidIPv6Addr(const nsACString& aAddr) {
  -  return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr);
  +  return true;
   }

Or if you actually wanted to do some validation, pass the address to getaddrinfo():

  bool net_IsValidIPv6Addr(const nsACString& aAddr) {
    struct addrinfo *res, hints = {.ai_flags = AI_NUMERICHOST};
    int err = getaddrinfo(aAddr.get(), nullptr, &hints, &res);
    if (err) return false;

    bool isValid = res[0].ai_family != AF_INET;

    freeaddrinfo(res);
    return isValid;
  }

This way it's valid if your OS considers it a valid address.

Routing tables don't work here, because the routing table looks something like:

  fe80::/64 dev eth0 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.11 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.13 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.14 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.15 proto kernel metric 256 pref medium
  fe80::/64 dev eth0.16 proto kernel metric 256 pref medium

Which interface's fe80::4 are you talking about? They all have an fe80::4.

They'd be more common if browsers didn't completely break handling them.

The most amazing part about this is that Microsoft used a public domain for it and then lost the domain registration.

I've never really got why this is so complicated. My interpretation of [] syntax in URLs is "[ enters into a raw address mode", "] exits the raw address mode" and "the characters between the brackets are opaque address characters to be passed to getaddrinfo()".

(It basically has to be this way, or the URL syntax would need to be updated to support future address families with their own address formats. New address families can be loaded at runtime, including ones that didn't exist at the time your current software was compiled -- and this is handled properly by the BSD socket API -- so hardcoding possible address formats is incorrect.)

The _only_ character that needs special handling is ], and if you're willing to declare that you can't be bothered to support link-local addresses at all then declaring that you'll support anything except addresses containing a "]" should be far easier.

Previously on HN:

Parsing IPv6 Addresses Crazily Fast with AVX-512: https://news.ycombinator.com/item?id=48245311

Parsing IPv6 Addresses Crazily Fast with AVX-512: https://news.ycombinator.com/item?id=48261386

Parsing IPv6 Addresses Crazily Fast with AVX-512: https://news.ycombinator.com/item?id=48294662

Parsing IPv6 Addresses Crazily Fast with AVX-512: https://news.ycombinator.com/item?id=48361058 (this page)

With two comments over four stories, I'm not sure if this article is popular or unpopular.

I intended the quoted part to mean something like "they did consider adding extra octets to v4 addresses and setting those octets to zero to mean v4".

It's not like they weren't able to come up with that idea. It's just that if you follow that train of thought through to its conclusion, you'll either decide it can't work or you'll make enough changes to end up with something that works basically the same way v6 does.

But yes, having enough IPs for everything was obviously a design goal. It would be excessively silly to go through all the work to increase the address size and not increase it by enough to handle whatever people ended up wanting to do with it.

Ah, okay. In that case v4 doesn't have a firewall by default either.

That's precisely why routers come configured with a firewall that blocks inbound connections from the WAN -- because the protocol itself doesn't have a firewall by default, and neither does NAT.

> It looks like doing this has the disadvantage that it erases the baked-in "This shouldn't be used for global-scope transmissions.

I tried with the kernel-generated LL and my kernel does attempt to use a link-local source when connecting to GUA addresses if it has no other address to connect from. And it works:

  # ssh 2001:db8::1 env | grep CLIENT
  SSH_CLIENT=fe80::f0b3:20ff:fe3d:d4cf%eth0 54456 22

(...so long as the destination is on the local network. In this case I assigned 2001:db8::1 to the router, but the router will issue an ICMPv6 redirect for other IPs on the network, which is awkward for me to test but should also work.)

I note that you didn't run `ip route add fe80::/64 dev enp0s3` after adding the LL with noprefixroute, which... seems to break surprisingly little? Because the packet gets sent to the router, which does still have a route for fe80::/64 to the same network, so it issues an ICMPv6 redirect and the client ends up doing NDP anyway.

Of course you can say the same for v6. Blocking connections that go from WAN to LAN by default has the same effect on both protocol families. If you assume that having the appropriate firewall rule to do that is the default then inbound connections will also be blocked on v6 by default.

NAT contributes nothing to your security in this scenario, and instead makes it harder (not easier) to understand and reason about what your router is doing.

Yup, repeatedly.

It's true that almost everything comes with a firewall rule that blocks new connections from the WAN to the LAN, so in practice these connections will be blocked on most things by default. But they come with this rule precisely because NAT doesn't do the job.

It will, and if you test it then it does.

NAT doesn't apply to inbound connections if you don't have a matching port forward rule, so it kind of doesn't matter how NAT works here. This is pure routing, not NAT.

But mine was that you don't need to do this as an intellectual exercise, because we got basically all the things you're asking for.

We have address extensions in v4 packets, we have NAT to help with partial upgrades, and we have a mix of 32-bit and 128-bit addresses (which should be just as obviously clean as a mix of 32-bit and 64-bit addresses, or rather more so due to 64-bits being too small). You don't need to think about whether any of this would have been doable, because we already went and did it.

Yes, of course they were all parallel protocols -- because your problem here is that v4 doesn't _have_ variable-length addresses. It's trivial to imagine a version of v4 that does, but that version would also be a parallel protocol to the version of v4 we actually have.

> even the idea of starting a new protocol with 64-bit addresses with an upgrade path was considered far too scary at the time

No it wasn't? Every proposal had an upgrade path. Having one was a mandatory requirement.

You can read the requirements document yourself: https://datatracker.ietf.org/doc/html/rfc1726. To me, it looks like these requirements were decided by the community rather than being imposed from above, but either way you can see that having a simple transition from v4 is listed right there.

> A decade later, when IPv6 had real-world deployments was far to late for 6to4 to save the day: entirely because a swath of non-6to4 addresses existed and needed to be reachable

What I'm hearing is that the compatibility with v4 that 6to4 provides wasn't considered important, and not by people in any position of authority but rather by the actual people choosing what to deploy on their own networks. Even though there were more 6to4 hosts than non-6to4 ones, and even though 6to4 doesn't prevent you from reaching those non-6to4 hosts, people still didn't want it.

Real in what sense?

Lots of people have come up with alternate L3 protocols for the Internet. For example, check out [1] which goes up to 999.999.999.999.999, or [2] which gets updated with some typo fixes every 6 months each time it's about to expire.

Someone did post another one of these recently, but it's just a random person on the Internet. The IETF's draft database is more or less a pastebin service -- anyone can upload something there without it being a thing that's being taken seriously.

Sometimes you get drafts like [3] as a demonstration of that.

[1] https://datatracker.ietf.org/doc/html/draft-eromenko-ipff-05

[2] https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv...

[3] https://datatracker.ietf.org/doc/html/draft-meow-mrrp

> Actually, what's up with your link-local addresses? They have really odd flags on them.

They were probably configured by one of the fancy network config daemons (systemd-networkd, dhcpcd or similar). They like to take over RA processing, and they add IPs with "noprefixroute" so they can add the route themselves separately.

RAs have nothing to do with link-locals, but I bet one or the other of those daemons also takes over configuring link-local addresses and does the same thing there. If you looked in the routing table, there'll be a prefix route for fe80::/64 that was added by the daemon.

This wouldn't affect how DNS replies are sorted though. On machines without non-link-local v6, AAAA records aren't handled by trying them first and then expecting them to quickly fail. They're handled by pushing them to the bottom of the list so that the A records are tried first.

> we could have baked address extensions into the existing packet format's option fields and had a gradual upgrade that relied on that awful bodge that was (and is) NAT

We did and do have this. I wrote about the option fields part in [1] but we also have NAT as part of the migration, in the form of NAT64.

Not only was doing these things not enough for us to be done by now, they weren't even enough to stop you from moaning that we didn't do them! How could anything have been good enough if these are the standards it's judged by?

[1]: https://news.ycombinator.com/item?id=47829991

I said "whenever anybody says it's bad and tries to come up with a better alternative, they end up coming up with something equivalent to IPv6", and that's what you did here. And as predicted, it was 6to4 you reinvented.

v4 extension headers are well known to get your packets dropped on the Internet, so they're a non-starter, but there's another extension mechanism you can use: you can set the "next protocol" field to a special value, then put the extended address at the start of the payload, followed by the original payload. This is functionally identical to using extension headers, but using a mechanism that doesn't get your packets dropped.

Far from not being seriously considered, this approach was adopted in v6 as RFC 3056.

> Except after the upgrade, there'd be no parallel system.

No. You get a parallel system because v6 addresses are too big to work with v4. Even if you used extension headers, v6 addresses would still be too big to work with v4. Whatever you do, v6 addresses are too big to work with v4. You WILL get a parallel system, and there's no way around this other than not making the addresses bigger.