- Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this).
- My dhcpcd.exit-hook script is becoming a monstrosity to maintain the prefixes and routes for two different ISPs. With NDP proxying I need to have routes with metrics defined or else the LAN-side IPv6 global addresses are inaccessible to the outside world. I also need to maintain route advertisement configs for these prefixes via either radvd or dnsmasq (and need to restart the relevant services when those prefixes change).
- Prefix deprecation route advertisement (i.e. when one global address prefix is no longer valid because that ISP went down) is difficult to implement properly. dnsmasq refuses to advertise a prefix (even with 0 lifetime to mark it deprecated) if there isn't an address for that prefix on an interface -- and tools like dhcpcd will remove those addresses automatically when the WAN-side interface goes down or the RAs expire, etc. radvd can deprecate all advertised prefixes on shutdown/restart, but that's not entirely desirable either.
- Multihoming has no truly good solution right now. If you advertise two different global network prefixes (e.g. for different ISPs), then the individual client nodes decide which source address to use via the "longest common prefix" match (RFC 6724). This implicitly decides which ISP their outbound traffic will go through. The problem is that these individual clients are poorly placed to make those kinds of route decisions. With the two ISPs I have, some remote hosts exhibit better behavior (i.e. higher raw throughput, lower loss, lower latency, whatever) with one network or the other. With IPv4, I am using NAT and doing load balancing across the two ISPs (round robin selection basically). I also have some hard rules on the IPv4 NAT side about which network to prefer for specific remote addresses. With IPv6, I could do the same approach (via IPv6 ULA + NAT), but that defeats the main advantage of IPv6 where everything can have global addresses.
- Debugging IPv6 problems can be a pain, because you have to check several more moving parts than with IPv4. Route advertisements, neighbor advertisements, DHCPv6, routing tables, IGMP/multicast snooping (which on some NETGEAR switches will drop IPv6 multicast traffic necessary for advertisements), etc.