1) DNS caching: as devices roam in and out of my network, they don't always evict the cache and remember the wrong address.

When trying to connect to ULA from outside, that's not going to work.

When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly, or I need to dynamically update the setup to know what is internal.

2) DNS over HTTPS: which is forced by more and more things by default. They will always resolve to the outside address, even when on the local network. Causing the same problem as caching.

3) Source addr selection "stuck" on ULAs: When I loose the public prefix for a brief period, things tend to start using the ULA as a source for public destinations. This is not going to work as expected. However, when I get a new prefix, some things tend to be stuck for a long time on trying to use the ULA instead of using the new prefix.

4) I've seen devices incorrectly keep a ULA address from a different network, and attempting to use that on mine. This is definitely a bug in the device, but now it is my problem.

5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix. This is related to Matter support.

They should detect that there is already a ULA prefix and use that, but this detection is far from perfect, so sometimes they just do it anyway. Now my whole network has two ULAs. All devices should still use their "nearest" address to communicate, but - bugs again - sometimes they don't do that.

But hey, apple provides me with free pentesting to see if I have the RA filtering correctly setup in switches :-)

---

The list goes on, this is just what came to my mind immediately. There are really 3 conclusions I came to:

- Split-brain DNS is an outdated concept, being broken every day by new tech. You can't rely on the devices talking to the specific NS you want.

- There are a lot of buggy IPv6 implementations out there. Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.

- Dual-stack and happy-eyeballs hide these issues too well. It is hard to detect and report them. Even if you do, vendors often just don't care or bother fixing because the issues do not have an immediate impact.

▲ simoncion 3 days ago | parent [-]

> 3) Source addr selection "stuck" on ULAs

So, I think #3 will be solved by rejecting traffic from fc00::/7 that's going to be routed out the router's WAN interface. To do this on my network, I have this on the 'filter' table of my router firewall:

  -A FORWARD -s fc00::/7 -o wan-interface -j REJECT

This should cause machines that attempt to use the only valid prefix during the outage to have their attempts to establish Internet connections during the outage actively rejected, rather than quietly dropped by your ISP. That will almost certainly cause them to use the globally-accessible prefix when it comes back up. You probably also need to do the same for RFC1918 and RFC3927 addresses on your IPv4 firewall... just in case.

> 1) ... When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly...

I'm fairly confused about why you need to treat them as an "outsider"? Same-subnet communications do not go through the router; hosts contact each other directly... so you're talking about firewalls running on each host, right? What are you doing to traffic destined to the globally-reachable address to treat it as an "outsider", and why? [0]

> 4) ... This is definitely a bug in the device, but now it is my problem.

How is this your problem? Your router won't have a route for traffic from that source address and will either drop or reject it... which is exactly the same as if a device erroneously retained an RFC1918 address in a subnet that isn't used on your LAN. [1] Are you seeing different behavior?

> 5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix.

That's pretty stupid behavior from the TV, but it's exactly the same sort of problem as the TV setting up a DHCP server on the LAN. It should not be doing that, and should be doing communications over the addresses already assigned to the interface (even the link-local address would work!). Do the RAs sent by the TV at least set the preference of the router to "low"? [2]

> Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.

I'm curious about what things you put in the advertisement (other than DNS server) that didn't work.

> Split-brain DNS is an outdated concept, being broken every day by new tech.

Meh. Keep the TTL for your internal hostnames very low (60 seconds or less) and any problems you might have go away quickly. You're not serving a lot of DNS traffic, and it is all local, so the low TTLs won't be a problem.

[0] For services that I don't want to be Internet-reachable I either block the ports at the router (for things like NFS which cannot be bound to certain IPs), or I configure the daemon to listen on my ULA address. If you use "privacy" addresses, and the daemon doesn't permit bind addresses expressed as a subnet (e.g. fd06:0:0:1::/64), then this will probably be difficult to do. I recommend NOT using "privacy" addresses for your daemon-running machines.

[1] It's actually better than the typical "Apple devices fail to renew their DHCP lease on wake" situation with IPv4, as the chances of duplicate IP addresses (and resulting ARP/ND flapping) are effectively zero.

[2] Though, it's an Apple device, so I bet they set the preference to "high" and have an infinite lifetime for the prefix. XD

	▲	herczegzsolt 2 days ago \| parent [-]
		3) The ICMP rejects may help, that I did not test. 1) I run services which give you different permissions depending on wheter you are local. Think a fileshare which is RW internally and RO externally. Yes, you could - and often should - do it differently, but IPv6 limitations should not be the reason that force you. 4) If a device does not work when connected to my network, but works on other, than this is my problem. Good luck explaining that it's a device bug to anyone. If they even understand it, they are not gonna care. This specific case is only a practical issue, when you have multiple networks interconnected, because the "correct" local prefix is always closer than the erroneously cached one. Besides, with a public-addr-only* network, this is not an issue. 5) Yes, it is stupid, but nobody is going to blame apple for the issues it causes to other devices. It's a problem with the network! I have no idea about the RA preference, i filter them away on the switchport. I may check sometime. > As for the advertisement contents: That is a misunderstanding. I meant to keep the network configuration simple in general, (like no ULAs, no splitbrain DNS, ...) not specifically the RA contents. But now that you mention it: Android still does not support DHCPv6, so the "Other configuration" flag is a funny one. I also put the PREF64 address in the RA for the NAT64, because apple devices require it. Android uses the ipv4only.arpa dns lookup instead. Isn't it lovely how consistently they behave? > As for DNS: Well, we completely disagree on this for multiple reasons: - DNS over HTTPS and users connecting to other "privacy nameservers" or "adblocking nameservers" will not be solved by the low TTL - Also 60 seconds is not an acceptable time for outage when nothing is phyisically broken - That 60 seconds is often 300, because I have seen way to many recursors just extend TTL to a minimum of 5min. Again absolutely their fault and my problem. [1] Just give them a "static lease" at the DHCP(v4) and it's never an issue again. Also, you should use DHCP-snooping (just like RA filtering) in switches all the time ;-) *yes, there are still link-local addrs, but those are not used for any practical stuff, so it does not matter much.