Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

Iljitsch van Beijnum iljitsch at muada.com
Wed Sep 19 14:01:30 UTC 2007


On 19-sep-2007, at 11:58, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

> Are you saying that 6to4 relay servers should be dedicated to that  
> task?

No, of course not. However, even though today IPv6 traffic is fairly  
minimal for pretty much everyone, it has the potential to grow  
quickly now that more stuff comes with IPv6 support out of the box.  
If someone then adds an AAAA record to a service that generates a lot  
of traffic, a noticeable amount of traffic can move from IPv4 to IPv6  
over night.

So I wouldn't be comfortable doing any form of IPv6 that is limited  
to, say, 200 Mbps on a router that can handle many gigabits worth of  
IPv4 traffic. That way, if more than a few percent of the traffic  
moves from IPv4 to IPv6, you're in trouble.

Note that this equally applies to tunnel en/decapsulation and regular  
IPv6 forwarding if those are not hardware accelerated.

However, if you have a box that has the same IPv6 as IPv4  
capabilities, you won't have any trouble. And if you have a somewhat  
limited box handle IPv6 and then IPv6 grows beyond the capabilities  
of that box, at least your IPv4 traffic isn't affected.

> I.e. you should either dedicate a pair of routers per PoP or set up a
> couple of BSD/Linux boxes per PoP?

No need to do tunneling at leaf nodes (i.e., ones where all the  
traffic goes into one direction) and if you have at least two in your  
network one location can be backup for another, so then one per  
location would be enough. If I had some old 7200s lying around I'd  
use those, in locations where replacing drives isn't a huge deal a  
BSD box (Linux if you insist) would be a good choice because they  
give you a bigger CPU for your money.

But doing it on non-dedicated routers is fine as well as long as  
you're sure an excess of IPv6 traffic isn't going to cause problems.



More information about the NANOG mailing list