IPv6 dual stacking and route tables

Jeroen Massar jeroen at unfix.org
Fri Feb 3 20:28:38 UTC 2012

On 2012-02-03 21:10 , -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers
> and carriers with IBGP) multi-site business. Starting off with a lab of
> course.

Dear "Hammer",

Welcome to the 21th century. 2012 is going to "the year" (they claim,
again ;) of IPv6 thus it is better to start before the big launch event
that is this year, (of which there was also one back in in 2004:
http://www.global-ipv6.org/ for the folks who have IPv6 for some time
now ;) Better late than never some would say.

> Circuits and hardware are a few months away. I'm doing the
> initial designs and having some delivery questions with the carrier(s).
> One interesting question came up. There was a thread I found (and have
> since lost) regarding what routes to accept. Currently, in IPv4, we
> accept a default route only from both carriers at both sites. Works
> fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
> heard some folks say that in a multi-homed environment it is better to
> get the full IPv6 table fed into both of your edge routers. Ok. Fine.
> Then, The thread I was referring to said that it is also advisable to
> have the entire IPv4 table fed in parallel. Ok. I understand we are
> talking about completely separate protocols. So it's not a layer 3
> issue.

The only advantage of more routes, in both IPv4 and IPv6 is that the
path selection can be better. An end-host does not make this decision
where packets flow, thus having a full route or not should not matter
much, except that the route might be more optimal. No DNS involvement
here yet.

The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
Lion and up which does not follow that spec and in which it cannot be
turned off either, which is awesome when you are debugging things...)

Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.

Chrome has it's own HE implementation, thus if you run Chrome on a Mac
you will have sometimes one sometimes another connect depending on if
you are using Safari or Chrome for instance as Safari does use the
system provided things. Ping will pick another again etc. It will be
quite random all the time.

The fun with the Mac OS X implementation is that it keeps a local cache
of per-destination latency/speed information.

If you thus have two default routes, be that IPv4 or IPv6, and your
routers are swapping paths between either and thus don't have a stable
outgoing path those latencies will vary and thus the pretty HE
algorithms will be very confused.

This is likely why your "source" recommended to have a full path, as per
sub-prefix the path will become more stable and established than if you
are doing hot-potato with two defaults.


More information about the NANOG mailing list