How do I specify a preferred source address for IPv6 multihome clients?

Question

My ISP provides an IPv6 prefix delegation but with a dynamic prefix. I want a publicly routed static prefix for some local services, so I also have a Hurricane Electric tunnel set up, which means clients must operate in a multi-address multihoming mode. The HE tunnel also requires traffic sourced in the HE static prefix to be routed through the HE tunnel; response packets are dropped upstream of my router otherwise.

The tunnel is necessarily slower than native IPv6, so I want clients to prefer source IP addresses that fall in the ISP's dynamic prefix except when connecting directly to the local services. How do I configure clients (a mix of Ubuntu and Windows) to prefer the native (but dynamic) "home"?

Answer 1

This isn't a true solution, but I recently discovered I could mitigate this issue by configuring my router to route packets based on their source address. Quote:

The ISP-delegated prefix should be the default route for performance reasons. Simple pass rules will allow inbound requests to route through the tunnel and onward to the internal server; outbound packets aren't so easy. The server's response will originate from a static address associated with the tunnel, but will usually take the default route back to the external client and subsequently get dropped by an external router that doesn't service packets from the tunneled prefix. We need to route outbound packets from the server through the tunnel; in short, we need source-based routing.

pf provides a convenient source-based routing solution with its route-to clause, but one must also disable state tracking for all inbound and outbound packets so the state tracker doesn't bypass our route-to rule. The state tracker is enabled by default, so we must disable state tracking for every interface on the route.

server = <webserver ipv6 addr>
...
pass in quick on $he_if proto tcp to $server port https no state
pass out quick on $lan proto tcp to $server port https no state
pass in quick on $lan proto tcp from $server port https route-to $he_if no state
pass out quick on $he_if proto tcp from $server port https no state
...

The use of quick may not be necessary if the rule set is cleverly crafted; I chose to emphasize legibility over cleverness. While it's possible to remove the port and protocol specifiers for these rules, I've found the interactions with other rules difficult to manage. Your mileage may vary.

Answer 2

Doing more research, it looks like the recommended method for handling this situation is to include the router preference options in the Router Advertisement. From https://www.rfc-editor.org/rfc/rfc4191#section-5.1:

The best router for the default route is the router with the best route toward the wider Internet. The router least likely to redirect traffic depends on the actual traffic usage. The two concepts can be different when the majority of communication actually needs to go through some other router.

For example, consider a situation in which you have a link with two routers, X and Y. Router X is the best for 2002::/16. (It's your 6to4 site gateway.) Router Y is the best for ::/0. (It connects to the native IPv6 Internet.) Router X forwards native IPv6 traffic to router Y; router Y forwards 6to4 traffic to router X. If most traffic from this site is sent to 2002:/16 destinations, then router X is the one least likely to redirect.

To make type A hosts work well, both routers should advertise themselves as default routers. In particular, if router Y goes down, type A hosts should send traffic to router X to maintain 6to4 connectivity, so router X and router Y need to be default routers.

To make type B hosts work well, router X should advertise itself with a High default router preference. This will cause type B hosts to prefer router X, minimizing the number of redirects.

To make type C hosts work well, router X should in addition advertise the ::/0 route with a Low preference and the 2002::/16 route with a Medium preference. A type C host will end up with three routes in its routing table: ::/0 -> router X (Low), ::/0 -> router Y (Medium), 2002::/16 -> router X (Medium). It will send 6to4 traffic to router X and other traffic to router Y. Type C hosts will not cause any redirects.

Note that when type C hosts process the Router Advertisement from router X, the Low preference for ::/0 overrides the High default router preference. If the ::/0 specific route were not present, then a type C host would apply the High default router preference to its ::/0 route to router X.