One limitation to IPv6 widespreading is the way we still handle multihoming.
Things have not fundamentally change since definition of PA/PI prefixes and the way we have been achieving multihoming in IPv4 world
Many people have been looking for the best way to avoid what we usually do today.It is a strong challenge since IPv6 space is really HUGE.
You will find here a map of IETF HomeNet WG contributions to this topic.
the prefix length that grows the most rapidly is /48.
Each new /48 comes from a end-user who wants to announce its own prefix, in order to overcome « provider assigned » limitations, thus contributing to the global fragmentation, just like /24 in IPv4…
This article intends to expose a simple way to practically achieve multihoming in your home network, while keeping « PA prefixes ».
First of all, we will stick to the paradigm described in RFC7157 :
"Whenever a host or small network (that does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks, an IPv6 address is assigned by each respective service provider resulting in hosts with multiple global scope IPv6 addresses with different prefixes. As each service provider is allocated a different address space from its Internet Registry, it, in turn, assigns a different address space to the end-user network or host."
OK, let’s say I have two providers, I will call them S and H 🙂
All was broken, and roughly half of the flows were not working !!!
The problem :
When the source IPv6 address and the gateway are not aligned, packets coming from my HomeNet are filtered by the provider because they are sourced by prefixes that the provider didn’t assigned… (don’t remember the RFC number though…).
The solution : After some thoughts, this head scratching becomes simpler when I decided to let the end devices do what they want !!
I mean :
- let them choose their source address with a total compliance to RFC6724, or partial (RFC 3484), or… whatever they want as long as they pick a valid routable address from the set of global prefixes provided by S and H.
- let them choose a proper default-gateway, with total conformance to RFC6724 (rule 5.5), or not, as long as they pick the LL (link-local) address of one of the available SLAAC routers in my HomeNet (I also decided to give up with GW preference…)
You may think that everything is still broken because the probability that the end device picks the wrong gateway is close to 50%.
That is true but does not matter : the piece of magic here is the simple policy routing rule that I have implemented on both routers.
This rule « realigns » the address selected with its according gateway. On a Linux based router, you only have to type two lines of configuration to make it work :
- on the router connected to « S » :
ip -6 rule add from prefix_from_H::/64 lookup HE ip -6 route add default via gateway_H_LL_address dev eth0 table HE
- on the router connected to « H » :
ip -6 rule add from prefix_from_S::/64 lookup SIXXS ip -6 route add default via gateway_S_LL_address dev eth0 table SIXXS
Et voilà !
you don’t have to do anything else… everyhing works like a charm !
Room for improvement : force end devices to choose one gateway depending on real time quality of both networks service providers, by using a probe system that can influence the SAS process.