[throw0101a]

> For IPv6, this doesn't work anymore, because the IP prefix is set by the provider, without NAT the second provider will simply refuse to forward any packet which originates from an IP which doesn't have their prefix.

Is multi-WAN without a static IPv6 assignment common? For home users, generally you get one assignment. If you do need this, then you can use IPv6 ULA internally and NPTv6 for prefix translation. You can still get mostly end-to-end connectivity because the external-internal is stateless. See "IPv6 Multihoming without Network Address Translation:

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

> SLAAC works by simply taking the prefix from the router and filling the rest with the mac address. Which means that anybody on the internet gets to know your mac address.

Except that this hasn't been how its worked on most OSes by default for several years; see "Temporary addresses", "Cryptographically generated addresses", and "Stable privacy addresses":

* https://en.wikipedia.org/wiki/IPv6_address#Stateless_address...

> - Captive portals: SLAAC does not directly support assigning DNS servers.

For SLAAC to work you need Router Advertisements (RAs), and and with-in those you can put DNS servers (and have since 2010):

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

> So it's very easy for malicious devices to flood routing tables of switches by telling them that they own all IPv6 for the whole /64. Makes the whole network abysmally slow, or completely down.

And the same thing can be done with in the IPv4 world by trying to overflow a switch's ARP table. I think switch manufacturers have figured that out.

> Most of these issues are solved by using NAT6 (or NPT), but the issue with it, is that it breaks some applications. Ipv6 promised to get rid of NAT

Except that NAT re-writes both the IP and port and thus you have to use state tracking for replies and port mapping with IPv4 NAT. Whereas NPTv6 is stateless:

   This document describes a stateless, transport-agnostic IPv6-to-IPv6
   Network Prefix Translation (NPTv6) function that provides the
   address-independence benefit associated with IPv4-to-IPv4 NAT
   (NAPT44) and provides a 1:1 relationship between addresses in the
   "inside" and "outside" prefixes, preserving end-to-end reachability
   at the network layer.

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

So you can send a message to a packet to a public IP:port combo and it will be mapped to an internal IP:port without much fuss since only the first /64 needs to be re-written. Of course only if your router/firewall is configured to allow new connections, which most consumer CPEs are not by default: they only allow replies to previous outgoing connections.

IMHO, most of the problems you describe haven't been a problem for years.

[yardstick]

> Is multi-WAN without a static IPv6 assignment common?

Yes, it’s incredibly common in the small business/retail/food/shop business with fibre primary and cellular backup. These places don’t have the budget for BGP, but can afford an extra €$£20-50/month for a backup cellular circuit. They don’t need static IPs, they just need working outbound internet access. And they want failover to occur within a few seconds, not 30s or 2-3mins.

[njibhu]

> And the same thing can be done with in the IPv4 world by trying to overflow a switch's ARP table. I think switch manufacturers have figured that out.

Not really though, because in Ipv4, a DHCP server can be authoritative, and switches can ignore IPs which are not assigned by the DHCP server. That's how it's usually figured out for Ipv4.

> Except that NAT re-writes both the IP and port and thus you have to use state tracking for replies and port mapping with IPv4 NAT. Whereas NPTv6 is stateless.

Yes, I didn't meant to state anything contrarily to that, but you still break applications which assumes that the local IP is the same than what is visible from a remote server on the internet.

For the captive portals, I stand corrected, and wasn't aware that you can now embed DNS directly in RAs, but stayed with the original implementation which delegates the DNS part to DHCP.

I probably have an outdated understanding of Ipv6, but to be fair it's quite a challenging exactly because of all the amendments that you linked. These are only some of the problems I encountered personally, and as you showed, each individual problem has a different RFC to solve it. You never know how stable they are and if they are properly implemented. And most of the time the safe default is to only work with the initial standard.