IPv6 dual stacking and route tables

-Hammer- bhmccie at gmail.com
Fri Feb 3 20:37:44 UTC 2012


Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online 
and offline responses. That was fast. The struggle is that I'm having 
trouble seeing how/why it would matter other than potential latency on 
the IPv4 side. IPv6 conversations usually involve taking the full table 
when dealing with multi-homed/multi-site setups. IPv4 I didn't really 
consider (taking the full table) until I mentioned this to some of my 
vendors technical folks and it caused a lot of reflection. Not on the L3 
part. Just on the DNS part. This appears to be a tough subject area when 
it comes to V4/V6 deployment strategies. The bottom line is that I'll 
take whatever the carrier feeds in V6. Just trying to see where I would 
be missing out by not doing the same in V4. Again, I have the hardware 
to support it and I really have no reason not to do it. I just want to 
be able to justify to myself why I'm doing it.

A lot of kinks to work out this year.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:28 PM, Jeroen Massar wrote:
> 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.
>
> Greets,
>   Jeroen
>
>




More information about the NANOG mailing list