My networks are IPv6 only for a couple of years, but I do have to run NAT64 (jool) and use a DNS64 resolver (i use a google-provided, but you could run your own)

It had very little benefits at the beginning, but having dedicated publicly routed addresses started to become really conevinent.

IPv6 with a regulary changing dynamic prefix still sucks though to this day ... :-(

▲ mshroyer 4 days ago | parent | next [-]

Huh, why IPv6 only instead of dual stack? Assuming you're talking about a home or small business network

The (occasionally, on Comcast) changing dynamic prefix was a pain for me too, when accessing things externally. For internal use I additionally set up a fixed ULA prefix.

	▲	hdgvhicv 4 days ago \| parent [-]
		Why double your workload and risk by having to run dual stack. All the downsides of both.

▲ hnlmorg 4 days ago | parent | prev [-]

How do manage dynamic prefixes? This is the problem that’s prevented me from adopting IPv6.

▲ mshroyer 4 days ago | parent | next [-]

You can additionally set up ULA: https://en.wikipedia.org/wiki/Unique_local_address

The way I do this, my internal DNS resolves hosts to their fixed ULA addresses. For the handful that are accessible externally, public DNS resolves to their address on the current public prefix.

▲ throw0101d 4 days ago | parent | next [-]

Note that currently with ULA if you have dual-stack IPv4 will be given priority over ULA. There is a late-stage—Submitted to IESG for Publication—draft that will change this:

* https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc672...

	▲	clysm 4 days ago \| parent \| next [-]
		More than just IPv4 priorities, almost all other IPv6 addresses are given higher priority which makes routing between ULAs on an internal network problematic. That draft doc seems to fix multiple problems at once.
	▲	CaliforniaKarl 4 days ago \| parent \| prev [-]
		Ah, thanks for posting that, I was wondering how things were going there.

▲ herczegzsolt 4 days ago | parent | prev | next [-]

I did try that, but it ended in an infinite fight with the source address selection algorithm and DNS caches. Also, unique-local addresses are deprecated as far as I know.

▲ simoncion 4 days ago | parent [-]

> ...it ended in an infinite fight with the source address selection algorithm and DNS caches...

What did this fight look like? For the past fifteen, twenty years, I have NATted IPv4, globally-routable IPv6, and ULA IPv6 addresses on all of my machines attached to the internet-accessible VLANs on my LAN. The only trouble I've noticed was when ISP maintenance caused me to lose the globally-routable prefix for a little while and my franken-router started passing ULA traffic out the WAN interface. [0]

I'd love to hear what you've been seeing, so I can see if there's trouble that I've been overlooking.

> ...unique-local addresses are deprecated as far as I know.

ULAs are not deprecated. You may be thinking of site-local addresses. See the first paragraph of section 1 here: [1]

[0] The obvious firewall rule fixed that.

[1] <https://www.ietf.org/archive/id/draft-ietf-v6ops-ula-usage-c...>

▲ herczegzsolt 4 days ago | parent [-]

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.

▲ dogcow 4 days ago | parent | prev [-]

Doesn't using ULAs kind of defeat the purpose (or one of the main intents) of IPv6, which is every device having a globally rotatable IP address? It kind of puts us right back in the IPv4 with NAT situation, only with longer, uglier addresses.

I personally think it is absurd that the ISPs that do actually support IPv6 are being so difficult and stingy about assigning static v6 prefixes.

	▲	RiverCrochet 4 days ago \| parent [-]
		IPv4/NAT is not the only "to get to system X you must pass through system Y" scenario. Example: You have a bastion host that is Internet-accessible, and it has one or more server behind it you only want accessible "through" the bastion host. The bastion host might be running nginx and reverse proxying multiple servers behind it, and this host is doing caching in addition to WAF and some other stuff. So this bastion host would have at least 2 NICs, one for the Internet-facing connection and one or more where servers exist on a non-public LAN. The small network(s) connecting these servers to the bastion host can use a ULA and thus be guaranteed to not be globally routable. Link-locals are suboptimal because since they are link local, they only have to be unique per link. This means some commands insist you specify interface name with the LLA, e.g. fe80::aaaa%eth1.

▲ throw0101d 4 days ago | parent | prev | next [-]

See perhaps "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events":

* https://datatracker.ietf.org/doc/html/rfc8978

And "Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events":

* https://datatracker.ietf.org/doc/html/rfc9096

Also maybe "IPv6 Multihoming without Network Address Translation":

* https://datatracker.ietf.org/doc/html/rfc7157

Lots of good presentation at the IETF meeting for the 6man and 6ops WGs.

▲ herczegzsolt 4 days ago | parent | prev | next [-]

With the risk of self-promotion, I did write a blog about the issues and mitigations: https://herczegzsolt.hu/posts/soho-ipv6-in-2025-still-dicey/

But I have to admit, that I ended up buying my own IPv6 block from a local ISP and tunnel to them. They have great interconnections, so bandwidth is not an issue, and latency penalty is less then 2 ms an average.

▲

hnlmorg 4 days ago | parent [-]

Thanks. A quick glance of that looks very promising. Lots of detail on the problem.

I’ll have a proper read of that tomorrow morning :)

	▲	herczegzsolt 4 days ago \| parent [-]
		TLDR: Turn the frequency of your RA-s waay up (3-5s) and their valid lifecycle way down (10-30s). There's still gonna be a hickup, but it should be tolerable.

▲ tcfhgj 4 days ago | parent | prev [-]

for dyn-dns? what's the problem exactly?

You just update the IP (or just the prefix) when the IP changes

Perhaps keep in mind that the interface id of the device the DNS entry should point is different for every device in the network.

Some use the router to update the IP and put the interface id of the router into the update url...

▲

hnlmorg 4 days ago | parent | next [-]

The problem is I run my own DCHP server (mainly because I have stuff like PXE booting set up).

I can configure the ISC dhcpd for IPv6 but I wouldn’t know what prefix to use in any automated way. So whenever the modem disconnects/reconnects, for whatever reason, I then need to somehow manually update the DHCP server.

Not an issue for ipv4 with NAT. But enough of a problem with IPv6 that I gave up on it. However I do accept that this is a problem of my own making (ie not using ISP provided equipment).

	▲	Sesse__ 4 days ago \| parent \| next [-]
		You can run stateless DHCPv6, i.e., without handing out prefixes. It's a fairly normal situation that clients choose their own addresses from prefixes handed out via RA, but that they get auxiliary configuration (such as UEFI boot, or DNS servers before RDNSS was a thing) from DHCPv6. You'd probably need to make sure there was an RA on the network hinting about a DHCPv6 server (the “Other” flag), though.
	▲	simoncion 4 days ago \| parent \| prev \| next [-]
		For others who might be thinking about providing assistance, check this subthread to see if what you're thinking of suggesting has already been suggested: <https://news.ycombinator.com/item?id=44771590>
	▲	herczegzsolt 4 days ago \| parent \| prev \| next [-]
		Your other problem would be Android not supporting DHCPv6. If you need IPv6 on Android, your only option is SLAAC.
	▲	dogcow 4 days ago \| parent \| prev [-]
		This is such a dumb problem with IPv6. Unless ISP stop being crappy and start offering static prefixes to regular residential subscribers, then I just don't see how v6 would ever be practical. This seems like a big oversight in the design and implementation of v6.

▲

4 days ago | parent | prev [-]

[deleted]