> 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.
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.