IPv6 dual stacking and route tables

Ryan Rawdon ryan at u13.net
Fri Feb 3 20:20:03 UTC 2012


On Feb 3, 2012, at 3:10 PM, -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. 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-

We have been accepting our upstreams' connected and customer routes only (v4) and full routes (v6) without issue.  I can't say that I have previously heard of the DNS performance example/concern you provided above



More information about the NANOG mailing list