Dagger2

(Long post was long so I split it into two short... shortish... uh... here, enjoy two walls of text instead of one.)

> I am not an IPv6 hater...just giving observations that when you introduce a breaking change, and add additional friction, it dramatically reduces adoption.

It's not like we had a choice. We needed to increase the available address space but v4 doesn't support doing that, so there's your breaking change. (v6 did the work to introduce family-agnostic socket API calls, so applications can now use new address families without breaking, but those calls didn't exist before v6).

Also... v6 suffers from massive double standards. When people hit a problem in v4 they treat it as a problem to fix, but when they hit a problem in v6 -- or a problem with v4 that causes a colon to be printed --- they skip trying to find and fix the problem and just go "oh my god look how shit v6 is disable it now".

Computers break all the time. "It's always DNS" is a meme, so clearly things that aren't v6 break too. But if people are willing to forgive the other things for problems and fix them but refuse to do either with v6, and will blame v6 for problems it reveals in other things, then v6 could be far more reliable than v4 and people would still be moaning about it breaking all the time.

We're in this situation because the people who designed v4 made it too small. It sucks but we need to deal with it, and the sooner we do that the sooner we can stop being annoyed by it. Dragging our feet on v6 just maximizes the amount of time we need to deal with transitioning to it.

> Ubuntu should never have even requested an IPv6 aaaa in the above system, and yes it only does because of politics and RFC requirements.

getaddrinfo() has the AI_ADDRCONF flag for this. I don't know why it doesn't pass it here, but it could.

The getent output shows that addresses are being sorted properly for a machine without v6. apt-get and other properly-written software will try the addresses in the order listed there, i.e. all v4 addresses first and only then the v6 addresses.

So... I don't think `Acquire::ForceIPv4 "true";` could fix the problem, because apt-get wouldn't have even tried the v6 addresses if any of the v4 ones were working. If you run `wget http://us.archive.ubuntu.com/ubuntu` while the problem is happening it should give you clearer log messages.

Another possibility is a DNS failure that causes your DNS queries to go missing sometimes. If this is the issue then it probably affects both your A and AAAA queries, but you wouldn't notice it on the AAAA queries if you don't have v6. You would only notice when the A queries go missing and the lookup only returns AAAAs; programs will try v6 "first" if this happens, since v6 is all there is to try.

> And how "::/0" > "::ffff:0:0/96"

It has higher precedence, but DNS results are sorted by "do the labels match?" first and by precedence second (rules 5 and 6 in section 6). The idea is to prefer connecting to addresses where the kernel would select the same type of address (as identified by the labels) for the source address. In your case, the algorithm is looking at something like this:

     src addr               →    dest addr
  <your v4 address>         → 91.189.91.81        (label  4 → 4) (precedence 35)
  <your v4 address>         → 91.189.91.82        (label  4 → 4) (precedence 35)
  <your v4 address>         → 91.189.91.83        (label  4 → 4) (precedence 35)
  fe80::786a:e338:3957:b331 → 2620:2d:4002:1::101 (label 13 → 1) (precedence 40)
  fe80::786a:e338:3957:b331 → 2620:2d:4002:1::102 (label 13 → 1) (precedence 40)
  fe80::786a:e338:3957:b331 → 2620:2d:4002:1::103 (label 13 → 1) (precedence 40)

The first three go first because of the matching label, then the last 3 go last because of the differing label. The two groups of three would then each be sorted by precedence, which you can't see here because both groups are homogeneous.

Note the label sort is the only one that considers your source addresses. If that step wasn't there, the sort order would be the same on machines with and without v6, which would be bad.

It'll prefer ULAs when connecting to hosts without A records. Programs will use ULAs if you connect to an IP literal, or if connecting to the A records fails. Also, Linux/glibc will prefer ULAs if you have a ULA assigned to the machine, and so will anything using the update to RFC 6724. So "ULA won't be used at all" is definitely not correct.

This part is exactly the problem I was talking about:

  root@ubuntu-server:~# apt-get update
  ...
  Could not connect to security.ubuntu.com:80 (91.189.92.23). - connect (111: Connection refused) Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4000:1::102). - connect (101: Network is unreachable) <long line snipped>
  <snip>
  W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/questing-security/InRelease  Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4000:1::102). - connect (101: Network is unreachable) <long line snipped>
  W: Some index files failed to download. They have been ignored, or old ones used instead.

Well... in this case the output does show the failure to connect to 91.189.92.23, but that looks like a different kind of message to the "W:" lines, so maybe it doesn't show up on all setups or didn't make it into the logs on disk, or got buried under other output.

If you look at just the W: lines, it mentions a v6 address but the machine doesn't have v6 and the actual problem is the Connection Refused to the v4 address. The output is understandably misleading but ultimately the problem here has nothing to do with v6.

Blame the WHATWG for that. They're the reason that v6 addresses in URLs are such a mess. http://[fe90::6329:c59:ad67:4b52%8]:8081/ should work, but doesn't because they refuse to allow a % there. (This is really damned frustrating, because link-locals are excellent for setting up routers or embedded machines, or for recovering from network misconfigurations.)

If it's on the same machine then just use http://[::1]:8081/. Dropping the interface specifier (http://[fe90::6329:c59:ad67:4b52]:8081/) works if the OS picks a default, which some will. curl seems to be happy to work. Or just use one of the non-link-local addresses on the machine, if you have any.

The other frustrating part of this is that it makes it impossible to come up with your own address syntax. An NSS plugin on Linux could implement a custom address format, and it's kind of obvious that the intention behind the URL syntax is that "[" and "]" enter and exit a raw address mode where other URI metacharacters have no special meaning. In general you can't syntax validate the address anyway because you don't know what formats it could be in (including future formats or ones local to a specific machine), so the only sane thing to do is pass the contents verbatim to getaddrinfo() and see if you get an error.

But no, they wrote the spec to only allow a subset of v6 addresses and nothing else.

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;
   }

You would also need something like O(N²) routing update messages to keep those tables updated, instead of the current... I'm guessing it grows more like O(log N) in the number of hosts. So everyone would need vast amounts of CPU and bandwidth to keep up with the announcements.

Or frequently, considered and accepted. 6to4 is a popular one to reinvent.

AAAA records have lower priority than A records if you don't have a v6 address assigned on your system. (Link-locals don't count for this).

You would only see a timeout to an AAAA record if the connection attempt to the A record already failed. Some software (looking at you, apt-get) will only print the last connection failure instead of all of them, so you don't see the failure to connect to the A record. I've seen people blame v6 for this even though they don't have v6 and it's 100% caused by their v4 breaking.

Run `getent ahosts example.com` to see the order your system sorts addresses into. `wget example.com` (wget 1.x only though) is also nice, because it prints the addresses and tries to connect to them in turn, printing every error.

I mean... adding v6 is the right thing to do either way, but "AAAA is higher priority than A" isn't the reason.

Are you talking about reaching the devices from inside the network, or outside?

If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix.

NAT66 doesn't help in either situation, so why do you think you need to use it here?

> automatically updating the firewall rules

You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.

None of that has anything to do with what you said in the post I replied to. "Add an extra octet to v4 addresses" has hard technical barriers to deal with if you want it to work, regardless of what the world looks like or what you're designing for.

> We now know that the "internet of things" and "having your fridge online", as well as "5G in everything so people can't firewall it off" is just insane and malign

None of this is really relevant either. IP's job is to handle the addressing used when sending data over the Internet, and it should do this job well regardless of what people end up doing with it.

> We also know that tying an IP address to a person (compared to an ISP using NAT) reduces privacy

We don't tie IP addresses to people. PI allocations might sort of count, but regular users don't get those.

You don't need any tricks like that. Regular new connections will work.

That might well have been a more immediately pressing issue, but they did know that v4 was going to be too small and that they still needed to work on v6.

I might be saying something obvious here, but address space exhaustion and size of the core routing table are really two sides of the same problem anyway. The way to keep the routing table size down is to give everybody a small number of big allocations instead of a big number of small allocations, but that consumes more address space since the allocations have to be rounded up to at minimum the next integer power of 2 (and really more, to accommodate growth).

It's just normal routing. If you send packets to a router, it'll route them.

More concretely, they can run the equivalent of `ip route add 192.168.1.0/24 via <your WAN IP>` on a machine that's connected to your WAN network, and then their machine will send packets with a dest of 192.168.1.x to your router. Your router will route them onto your LAN because that's what its own routing table says to do with them.

Anyone on your immediate upstream network can do this, not just your ISP. Also, if you use ISP-assigned GUAs then this inbound route will already exist and anyone on the Internet can connect. Applying NAT to your outbound connections will change their apparent source address, but it won't make that inbound route disappear.

It will let them in without a port forward in place. The port forward just rewrites the IP on an incoming connection, nothing more.

Our world. It was a good design in our world.

I don't think v6 is the absolute pinnacle of protocol design, but 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. If people consistently can't do better than v6, then I'd say v6 is probably pretty decent.

Enabled and actively using it to connect to servers that have v6. Though yes, this is tracking by session rather than by packet or byte.

> NAT66 implies using fd00::/8

No it doesn't. Use the GUA from your primary ISP.

NAT is state tracking with a trick, but not firewalling. It doesn't block connections, so it's not a firewall.

See RFC 2766.

Country would be far too coarse to be useful. I suspect it's more likely to be at the AS level, or /32 or somewhere around there.

I have a /48. The amount of "we have detected unusual activity from your network" messages I get from sites, when I'm reasonably sure the only activity coming from my network is my usual activity on those sites, suggests that they're using something bigger than /48.

It's honestly not that hard. Tell your router to reject new inbound connections from the WAN interface, and you're done.

You have to do the exact same thing to make sure inbound connections aren't possible on v4 (even with NAT in the picture), so you might well have already done this or got it from the default ruleset. Plus it's trivial to test, by attempting to connect from another network.

Even a correctly-configured NAT will let connections in from outside, and a lot of people don't understand this.

Personally I'd count "your security thing doesn't actually do the thing it's supposed to do" as being pretty bad on the security scale. At least people understand firewalls.

If you can't enforce a flag day then that's all you're left with, isn't it? Other than maybe hacking into people's networks, upgrading them and then somehow preventing them from undoing your work.

Big parts of it are copied straight from v6's approach, so it's kind of inevitable that at least those parts would be workable -- because they're workable in v6.

But of course, you might as well just use v6 at that point.

At this point, the people who would be worried about this ought to know that temporary addresses are a thing, and that they prevent workstation N from having a single fixed IP for its outbound connections that it could be identified with.

NAT64 is a subset of a different thing that existed since 2000 though, when v6 was ~5 years old and before most OSs even had support for it.

Nope, it doesn't. The security model is based on your firewalls and routing, not on NAT. NAT just gets in the way and makes it harder to understand what's going on.

For example, on a normal home network, if you don't have a firewall on your router then your ISP can connect to anything on your network. Even when they don't control the router and even if you're NATing.

If you didn't realize this then apparently NAT didn't make it easier to reason about after all.

Honestly, it sounds more like your network is fragile rather than robust. A robust network would be able to handle the IPs changing, rather than needing them permanently set to some specific value.

It's the illusion of a firewall too.

NAT changes the apparent destination address of a connection, it doesn't filter them. If a connection arrives with the destination address already set to one of your machines, NAT won't prevent it.

SEND secures NDP by putting a public key into those 64 bits, and also having big sparse networks renders network scanning rather useless at finding vulnerable hosts, so there are reasons to make subnets /64 other than SLAAC.

Also we can always reduce the standard subnet size in 4000::/3 if we ever somehow run out of space in 2000::/3 (and if we don't then we didn't sacrifice anything to use /64s).