Dagger2

It's not from systemd though. glibc's NSS stuff has been around since... 1996?, and it had support for lookups over NIS in the same year, so getaddrinfo() (or rather gethostbyname(), since this predates getaddrinfo()!) have never just been DNS.

systemd-resolved normally does use a separate protocol, specifically an NSS plugin (see /etc/nsswitch.conf). The DNS server part is mostly only there as a fallback/compatibility hack for software that tries to implement its own name resolution by reading /etc/hosts and /etc/resolv.conf and doing DNS queries.

I suppose "the DNS compatibility hack should follow DNS RFCs" is a reasonable argument... but applications normally go via the NSS plugin anyway, not via that fallback, so it probably wouldn't have helped you much.

Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS.

i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively) DNS records.

The debug tool for this is `getent ahosts`. `dig` is certainly useful, but it makes direct DNS queries rather than going via the system's name resolution setup, so it can't tell you what your programs are seeing.

So... why? The article only mentions "the Medicube installer, based on OpenStack’s Ironic, “created completely wrong configurations for IPv6.”" and "Certain Dell BIOS implementations lacked complete IPv6 boot support, and when present, were buggy". The former sounds more like it's a failure of the Medicube installer rather than of IPv6, and the latter sounds more like a failure of certain Dell BIOS implementations.

It says the BIOS problem is fixed and they're using a custom deployment tool now, with no mention of them needing to move off of IPv6. They're running "a record-breaking Kubernetes cluster" on it, so it sounds more like it succeeded rather than failed?

And it is. That's exactly how deploying v6 works. In fact, even the packet format stays the same, which means you don't lose the ability to talk to peers that require the old format -- people would do more than hesitate if that wasn't the case.

But you understand that after ISPs get short on addresses and start to hand out /64s, it's not going to be exactly the same afterwards, right? You'll have to actually use that /64 and the updated DNS and stuff.

Because we hit that point twenty years ago. We're long past the "everything looks and works in exactly the same way (so only the 32-bits of addresses in v4 work)" stage and deep into the "ISPs hand out /64s" stage. There was a point where v6 deployment just meant that you turned it on and nothing else at all changed, but at this late point in the game it also involves using those new addresses. We already took the approach you're asking for here, we just didn't stop at the beginning of it.

You're talking about v4, right? Because that's the one that works weirdly and has weird failure modes and edge cases. You've gotten so used to dealing with the weirdness that you struggle to even see it, but that doesn't mean that it's not there or that there's no value in removing the need for it.

They do carry into it though. My v6 packets to 64:ff9b::192.0.2.0/104 go to 192.0.2.0/24, and so do the ones to 2002:c000:200::/40. (And importantly the replies come back too, or would do if I wasn't using one of the v4 documentation ranges as an example.)

Making a new thing that changes nothing but the address field size won't give you a seamless cutover, because there's no seamless way to use addresses bigger than 32 bits with v4. (If there was then we wouldn't have bothered with v6 in the first place, we would have just used whatever that method was!)

Nothing much else has really changed in v6 -- v4 has ULAs and doesn't use NAT by default either, just when under address space exhaustion. The randomized addresses are a thing, but making a new protocol without them isn't going to produce something that's any easier to switch to, nor any more compatible with v4, than v6 already is.

At this point, about 25% of traffic on dual-stack ISPs is v4. So no, v4 isn't where all the stuff the phone wants is.

CGNAT is generally only done for v4. v6 isn't needed to provide CGNATed v4, and if v6 is provided as well then it generally isn't NATed. I expect you could find an ISP somewhere that NATs the v6 too as a counter-example if you looked hard enough, but as a rule they don't.

(Sometimes CGNATed v4 is provided by making use of the v6 in some way -- e.g. mapping v4 destinations into v6 with NAT64, or by tunnels -- but the CGNATing still only applies to v4 destinations, so this just an implementation detail rather than an undermining of the above point.)

> Cgnat you are restricted to tail scale stuff.

But only on v4, not on v6. That's kind of the point of bothering to make v6 in the first place -- it allows you to keep the ability to poke holes in your inbound firewall even in a world where v4 is exhausted to the point of CGNAT.

The exhaustion and the CGNAT and the resulting restrictions would still be there if you didn't have v6. It's just providing you with a way out of them.

It wasn't a whole redesign though? It has an identical network model to v4, routing and address assignment work the same way, it works over the same L2 links as v4, and L4 protocols like TCP and UDP all work the same. DNS is the same. The socket API is the same. Link-local addresses exist in v4 too, and v4 even had router advertisements already before v6 was even out. How is it a whole redesign?

> Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.

This is, of course, impossible, because v4 only has 32 bits of space for src/dst addresses. You can't cram more than 32 bits into 32 bits. If it was possible we wouldn't have needed v6 in the first place.

You don't need to use ULA addresses to use NAT. You can use any GUA prefix too (preferably one you own or are assigned in some way, rather than squatting on one, to avoid the risk of clashing with someone else).

It's exactly as private as doing the same service with a GUA prefix. Just get a PI block and pick a /64 from it to use instead of whatever ULA prefix they picked at the moment.

NAT might be a thing in Mullvad's case, but there's no link between that and needing ULA.

Even Mullvad give out ULA addresses. You can hardly call that a proper implementation :(

You probably want to add the "optimistic" or "nodad" flags when adding the address, or you'll need to wait for DAD to finish.

There has to be one somewhere. In my case it's running on my router, but your ISP can do it at their end, and since you can use any /96 including public ones, it's also possible for anyone to run one:

  $ dig A +short github.com
  140.82.112.4
  $ dig AAAA +short github.com
  64:ff9b::8c52:7004
  $ dig AAAA +short github.com @2a01:4f8:c2c:123f::1
  2a01:4f8:c2c:123f:64:5:8c52:7004
  2a00:1098:2c::5:8c52:7004
  2a00:1098:2b::1:8c52:7004

Note the embedded 140.82.112.4 in the last four bytes of the v6 addresses, which you can write in v4 format if you want:

  $ getent ahosts 2a00:1098:2b::1:140.82.112.4
  2a00:1098:2b::1:8c52:7004 STREAM 2a00:1098:2b::1:140.82.112.4

My router maps the v4 address space into a v6 /96, and my DNS server returns AAAAs pointing to those addresses. I run my own, but try setting your DNS to 2a01:4f8:c2c:123f::1 (and disabling v4 altogether) to give that a go.

It's still just one firewall. You can listen on a single socket too (sockets listening on :: will accept v4 connections by default on Linux). You can likely drop many of the v4 ACLs when things are going over v6.

It's not no work. I'm just saying it's not double the work. You'd think knowing that would make people more likely to do it, but...

You're never going to get that. There isn't enough v4 in the world for that. That's kind of why we're doing v6.

You don't have to install NAT64 to connect to v4-only hosts -- you can run dual-stack, and use your existing v4 setup to reach them. NAT64 is just what you do when you want to turn off v4. You said in the post above that people running networks should have been told they had to change things, so you don't get to whinge about needing to do it yourself.

Also, you don't need to have a public v4 address for v4-only people to connect to you. Reverse proxying is a service you can pay for, and only the people running the proxy need v4. CloudFlare do this (for free, even, depending on what you're doing).

In fact the same is true of NAT64; set your DNS server to e.g. 2a01:4f8:c2c:123f::1 and away you go.

There's been endless effort into all of those things. What else are we supposed to do when people just aren't following them anyway?

It's not even double the config. For e.g. my firewall, which is a 300-line config that I've already designed and implemented, making it dual stack mostly involves writing "domain (ip ip6)" instead of "domain ip". That's simply not double.

It's not less intuitive than v4 either. That's a lack of experience talking. Meanwhile, trying to use v4 quickly devolves into needing to use NAT, which is less intuitive.

> Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".

My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.

It's an imaginary firewall. NAT won't stop unsolicited connections in to your network -- if anything, its entire purpose is to do the exact opposite of that.

If you actually want to block inbound connections when you're doing NAT, you need the stateful firewall anyway. At that point, pretty much the only thing NAT is doing for your security is making it harder to understand what's going on.

The second line is the only one you need for NAT to work. The first is irrelevant to forwarded traffic. If you have no other rules then a) NAT will be applied to your outbound connections, and b) you'll have no firewall for the network behind the router.

NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.

> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]

Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.

It's a good strategy if deploying a bigger address space is easy and cheap. When it's incredibly difficult and time consuming, you should pause and consider a bit more carefully.

New L3 protocols on the Internet are firmly on the "incredibly difficult and time consuming" side.

Does running `ip link set mtu 1280 dev eth0` on the client machine fix it?

A lot of servers have somehow managed to screw up their path MTU discovery. People have been using client-side workarounds for this for many years, but I suspect the workarounds are often forgotten on v6. Unfortunately the resulting problems then get blamed on v6.

The other possibility is broken multicast on your local network. Some Wifi mesh APs and "range extenders" just don't work properly. The test for this would probably be to take them out of the network path by connecting directly to the main router via Ethernet and seeing if you can talk to Internet hosts properly.

Overkill is good! It's impossible to get the size exactly correct; your only options are "too small" or "too big". Given how difficult it is to deploy a new L3 protocol, why wouldn't we pick the size that ensures we don't have to turn around and do it again immediately afterwards?

> backwards-compatible would have gotten us there that much sooner

v6 is already backwards compatible. Between dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other things I'm forgetting, you could make a reasonable argument that it's too backwards compatible, even.

If you meant "v4 being forwards-compatible would have gotten us there sooner", then yes, I agree. It's unfortunate it's not. That's entirely v4's fault though, not v6's.

You would want that. The upstream network can't do it for you, because RAs can't be routed. Same deal for DHCPv6 (although personally I'd say you can probably skip that and just use SLAAC).

It's pretty simple with systemd-networkd:

  # On the upstream network.
  [Network]
  DHCP=yes
  [DHCPv6]
  PrefixDelegationHint=::/56

  # On each downstream network.
  [Network]
  IPv6SendRA=yes
  DHCPPrefixDelegation=yes

If you don't want systemd-networkd, look at https://wiki.debian.org/IPv6PrefixDelegation#Using_ifupdown_.... Firewalling is the same as v4, just without the NAT.

One frustrating part is that as far as I can tell nothing supports easy downstream DHCPv6-PD delegation, so machines on the downstream network that want their own prefix won't be able to get one automatically. OpenWRT's network config daemon supports it, but nothing on regular Linux does.

> however many /64s that is (at least 8);

256!

ssh is fine:

  ssh fe80::2%eth0

where fe80::2 is the peer's address, and eth0 is the local name of the interface they're on.

Unfortunately browsers have decided that link-local is pointless and refuse to support it, so HTTP is much more difficult.

Sure you can. You can do it today even, let alone in some unspecified number of years.

::ffff:0:0/96 is for representing v4 addresses in v6 APIs. You shouldn't even see it on the wire at all, but if you do it's just a regular v6 bogon range and not anything to do with v4, so it doesn't get or need any special handling in firewalls or routers.

6in4 is just a basic "put the v6 packet directly into the payload of a v4 packet" tunnelling approach. It's a sensible way of tunnelling one protocol over another (and it's the same thing as 4in6, just the other way around).

HE's tunnels are 6in4, and 6to4 and 6rd are automatically-configured 6in4 tunnels.

That's... not how things work in general. It would be possible for an ISP to do that, and I'm sure somebody somewhere does, but they could do the exact same thing on v4 so you don't get to blame v6 for it.

If your ISP runs the default router for your own LAN, they'll have full visibility into it on both v4 and v6. That's just how IP works.