IPv6 dual stacking and route tables

Philip Dorr tagno25 at gmail.com
Fri Feb 3 20:25:51 UTC 2012

You should accept the full v6 table, because some IPs may not,
currently, be reachable via one of the carriers.

On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- <bhmccie at gmail.com> 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.
> 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 reasoning was that DNS could
> potentially introduce some latency.
> "If you have a specific route to a AAAA record but a less specific route to
> an A record the potential is for the trip to take longer."
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
> Any guidance would be appreciated. Thanks.
> -Hammer-
> "I was a normal American nerd"
> -Jack Herer

More information about the NANOG mailing list