
On 8/3/25 14:07, Vasilenko Eduard wrote:
Strongly disagree with you both. IPv6 has enormous complexity (compared to IPv4) on the 1st hop. Root causes for this: - many IP addresses per host - blocked DHCP on the most popular OS and all smartphones - strong push against NAT (that resolves many problems for connection to Carriers) - address resolution that is on L3 not on L2
What does that have to do with the problem at hand, or what we said? Let me go one by one:
- many IP addresses per host
This, by itself, has nothing to do with the problem at hand. IN IPv4, if you had implementation configure multiple addresses via DHCPv4, or you were to manually configure multiple addresses manually, you'd get the same. The problem is not the multiple addresses, but rather than IP hosts routes packets on the destination (vs more complex policy routing, e.g. considering the source prefix).
- blocked DHCP on the most popular OS and all smartphones
Same as above. If every host had DHCPv6 support, but you didn't have policy routing (e.g., RFC8028), the situation wouldn't change a single millimeter.
- strong push against NAT (that resolves many problems for connection to Carriers)
I explicitly noted that "NAT is particularly demonized in IPv6 world", yes. -- but, again, NAT for IPv6 solves the same problem as IPv4 NAT -- so nothing different here.
- address resolution that is on L3 not on L2
What does this have to do with the problem at hand?
IPv6 was a political compromise between people pushing IP, IPX, AppleTalk, DecNet, and a few other funny networking technologies. It inherited a lot of complexity from them.
It inherited a lot of complexity, created additional one, and was deployed 20 years or so after the original design. Nobody is arguing otherwise. The discussion here was on the specific topic of multi-ipv6: In that regard, it boils down to: IPv4 has a de-facto constraint where each host configures a single address via IPv4, and this is a private address (RFC1918). NAT is widely deployed, so the end host is not exposed to the public address that is used to communicate on the public Internet. So while the theoretical problems are the same, in virtually all practical cases you are shielded from them, thanks to NATs (same as for RFC8978). It is also the case that a lot of folks have demonized NATs, while at the same time deluded themselves that some of the issues that NATs shield you from either doesn't exist, will somehow disappear, or will solve themselves. slaac-renum is one of such examples (RFC8978 and friends). multi-ipv6 is yet another. (In that regards, <https://datatracker.ietf.org/doc/draft-gont-v6ops-multi-ipv6/> is essentially a document that says "this is a problem that needs a native solution", and these are the core scenarios that such a solution should address.) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494