IPv6 dual stacking and route tables
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
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
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@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
On Feb 3, 2012, at 3:25 PM, Philip Dorr wrote:
You should accept the full v6 table, because some IPs may not, currently, be reachable via one of the carriers.
Definitely agreed here, and this is why we take full v6 tables. Especially since one of our upstreams does not peer with at least one other large network; if we took just a default from them, we would likely be sending them traffic which they in turn do not have a route for whereas the other upstream of ours does.
On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- <bhmccie@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
On Fri, 3 Feb 2012, -Hammer- wrote:
"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.
We currently take full v4 and v6 routes, however we do not yet have end-users officially on v6 (users doing their own 6to4 tunnels and stuff like Teredo notwithstanding), so I don't have any experience with the A/AAAA resolution asymmetry you're describing. jms
On Fri, Feb 3, 2012 at 12:10 PM, -Hammer- <bhmccie@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.
Well. I don't really follow the above text. But, the principle is the same for IPv4 or IPv6. If you take a full or partial table, your router can make a better choice than just getting default (only maybe, BGP is never guaranteeing anything about performance). That said, in v6, it is a little bit more important, IMHO, to take the ISP routes instead of just a default since the v6 peering is not as robust out on the Internet. There are still turf wars going on or some SPs are still not peering IPv6 in all the places they peer for IPv4. Less peering = longer latency. But, this situation has improved dramatically in the last 12 months. In the end, my guidance is to take "provider routes" or "customer route" + default. This helps your router make an educated guess without absorbing all the churn and gunk that a full BGP feed hits your router with. Make the SP trim those routes on their side so you don't see it. CB
-Hammer-
"I was a normal American nerd" -Jack Herer
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
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
On 2012-02-03 21:37 , -Hammer- wrote:
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.
Why you want non-defaults in both IPv4 and IPv6: - more possible paths - less chances of blackholes. And of course, those paths will be more stable and you don't get hot-potato swapping between two defaults. And that in turn allows the Happy Eyeballs mechanisms to do their jobs much better as they keep a history per host or prefix, they assume IPv6 /48's and IPv4 /24's from what I have seen, in some cases. Greets, Jeroen
OK. Looking forward to getting the lab up. Since I can handle the volume I'll take both tables. At least in the lab. Looking forward to doing some experiments with DNS just to see what all the fuss is about. Looks like I'll need to order a Mac for the lab. No harm there. :) -Hammer- "I was a normal American nerd" -Jack Herer On 2/3/2012 2:47 PM, Jeroen Massar wrote: > On 2012-02-03 21:37 , -Hammer- wrote: >> 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. > Why you want non-defaults in both IPv4 and IPv6: > - more possible paths > - less chances of blackholes. > > And of course, those paths will be more stable and you don't get > hot-potato swapping between two defaults. > > And that in turn allows the Happy Eyeballs mechanisms to do their jobs > much better as they keep a history per host or prefix, they assume IPv6 > /48's and IPv4 /24's from what I have seen, in some cases. > > Greets, > Jeroen > >
On Feb 3, 2012, at 12: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-
"I was a normal American nerd" -Jack Herer
On a purely theoretical level, mores specific routes are always better than default. So, on a purely theoretical level: IDEAL: Full routes, both protocols Advantage: Most information available, theoretically best decisions possible. Disadvantage: Router cost rivals national debt of third-world country. Second best: Full routes IPv6, default or partial routes IPv4 Advantage: Lots of information available, theoretically best IPv6 decisions. Disadvantage: IPv6 might outperform IPv4 (not really a problem in most cases) Bigger disadvantage: Some IPv4 destinations might get blackholed from time to time. Third choice: Default both protocols Advantage: At least you're still dual-stacked. Disadvantage: All the disadvantages applied to IPv4 above now apply to IPv6, too. Worst choice: Don't implement IPv6 Advantage: Absolutely none. Disadvantage: You can reach progressively less and less of the internet over time. However, the real answer is more complex than that. Sometimes the route that looks the best in BGP might not actually be the best and so in some cases with full tables you might send to the provider with the less effective path even though default would have had you going via the more effective path. These circumstances are rare, however, but, BGP has lots of knobs and depending on how well you and your upstreams set those knobs, your experience can be radically better or worse as a result. If your trip to the A destination via default takes longer than your trip to the AAAA destination via specifics, I'm not seeing a problem. Clients that have IPv6 capability will get a better user experience and clients that don't have IPv6 will get the same experience they got with default-based IPv4 prior to you implementing IPv6. Owen
participants (7)
-
-Hammer- -
Cameron Byrne -
Jeroen Massar -
Justin M. Streiner -
Owen DeLong -
Philip Dorr -
Ryan Rawdon