Hi Jonas, You can find much more information and comparison here: https://datatracker.ietf.org/doc/html/draft-fbnvv-v6ops-site-multihoming-03 This draft is blocked in IETF because some participants (Google is the most vocal but not exclusive) are strongly against mentioning any NAT (including NPT) - they believe that such information should be blocked from dissemination - you could listen to video from any IETF meeting discussed this draft. Hence, pay attention, that the current IETF consensus is to create as many problems as possible for people using NAT/NPT in the IPv6 world. The MHMP problem will not be resolved very soon because there is PVD technology (provisioning domains) that is patented and pushed by some influential individuals in the IETF. I could not comprehend why they believed that PVD could resolve MHMP. Because PVD is the router (and host) link virtualization: if a router plays the role of a few virtual routers on the link then the MHMP problem immediately aggravates, it is not becoming easy in any way. Nobody steps down from the throne to explain to me why - I did ask many times. Probably because money likes silence. But we have what we have: MHMP is left for PVD. You did mention RFC 8678. Then probably you have a multi-hop routing site because this RFC concentrates only on this aspect of the MHMP problem (all other problems are out of the scope). Then look to section 6 of our draft (comparison table) - you will have big challenges with the provider's addresses - this option is probably blocked for you. Actually, RFC 8676 is pretty useless yet, because there is no way to propagate ISP uplink loss through the site (to withdraw the particular carrier IPv6 PA address) - the blackholing is guaranteed. Then the advice to get your own address space and become the full BGP speaker is probably a good one. Actually, the problem is very complex (you could look at the draft) - IPv6 flexibility on the 1st hop always translates to tremendous complexity. Are you sure that you need multi-homing in IPv6? This rabbit hole is very deep. You could stay with multi-homing in IPv4. PS: Shim6 was NOT a solution for resiliency, because the address space of one carrier was used for tunnel identification. If this particular carrier is lost, all tunnels should be down (and everything should be started from scratch-election of the new carrier as the basis for tunnel addressing). Moreover, the mechanism to inform hosts about the loss of a particular carrier (and respective PA address space) is pretty broken, even now, not to say 10 years ago. Hence instead of adopting a new carrier for the identification, we would get blackholing with a timer measured in a week. Shim6 was useful only for load balancing. No wonder why it did not fly. The people who developed shim6 are very respected in IETF - it is taboo to talk about a deficiency of any solution they developed. (Actually, I respect very much the leading person on shim6. Just I do not agree that a solution is prohibited from discussion). Shim6 is mentioned everywhere just for politeness and respect to the people who did a lot for IETF. (they really did!) If you mention shim6 then you would just have more chances for document publication. Does not matter that it does not work at all, even theoretically. Hence, you would still see shim6 in some documents. It is pure politics. Eduard -----Original Message----- From: Jonas Lochmann <ripe-ipv6-wg@jonaslochmann.de> Sent: Thursday, March 6, 2025 15:47 To: ipv6-wg@ripe.net Subject: [ipv6-wg] IPv6 Multihoming with Load Balancing My goal is to use multiple uplinks, but not only for redundancy. Most of the time, all (in my case 2) uplinks are available and then the question is how to make use of both of them. With IPv4, NAT is common and thus the solution is quite simple. In my case, I am using the mwan3 package from OpenWrt. It uses iptables rules to add firewall marks to connections. If multiple uplinks are available, then the mark/uplink is chosen randomly and assigned to this (e.g. TCP) connection. This firewalls marks are used during a policy based routing. With a masquerade/source NAT, the right source address for the used route is picked and everything just works. In case of IPv6, everything is different. NAT is uncommon. One solution is to enable NAT and then everything works as with IPv4. Alternatively, RFC 8678 describes that clients can be informed about multiple uplinks. The limitation: I do not see any option for load balancing. RFC 8678 references other solutions. Shim6 seems to be not widely implemented. The Multipath Transports look like a solution for the future with Mulitpath TCP. The last solution is NPTv6. RFC 8678 does not like the solution. It is no NAT, but it still rewrites the addresses. The disadvantage: Stateless address rewriting seems only usable if there is only one prefix known to the network. If this is the global prefix of one uplink, then all connections are interrupted if the prefix of this uplink is changed. If this is the local prefix, then the clients do not know their public addresses. I tried to use a stateful source address rewriting instead. With nftables, this is easy to implement and it works if the prefix length of the uplink is longer (smaller subnet) than the internal network: Just keep the prefix and replace the bits after it with the original source address. With this, I can use local addresses in the local network and additionally provide the public address/es of one or more uplinks. I am using this in production at one location since multiple years and thus know that this works. I am interested in other approaches, experiences and feedback for this method. ----- 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/