There was a comment that IPv6 in general is the same complexity as IPv4. Hence, my reaction: it is not.
OK. Returning to the problem scope: - Missing NAT is the biggest challenge for MHMP. - The second challenge is many IP addresses per host. It is possible to position it as a feature, but this feature creates a lot of complexity. IPv4 did not mandate that every host should support it. IPv6 does. It is a big difference that everybody in IPv6 is involved in it (like he or not). Anybody is welcome to read RFC 6724 (SASA) to see the consequences. How many people worldwide understand it well? One hundred or two? Of course, it is a value for these people. Ed/ -----Original Message----- From: Fernando Gont <[email protected]> Sent: Sunday, March 9, 2025 19:00 To: Vasilenko Eduard <[email protected]>; [email protected]; [email protected] Subject: Re: [ipv6-wg] Re: IPv6 Multihoming with Load Balancing 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: [email protected] PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
