[85637] in North American Network Operators' Group
Re: Deploying 6to4 outbound routes at the border (was Re: IPv6 news)
daemon@ATHENA.MIT.EDU (Todd Vierling)
Fri Oct 14 22:49:02 2005
Date: Fri, 14 Oct 2005 22:45:33 -0400 (Eastern Daylight Time)
From: Todd Vierling <tv@duh.org>
To: Daniel Roesen <dr@cluenet.de>
Cc: North American Noise and Off-topic Gripes <nanog@merit.edu>
In-Reply-To: <20051014223145.GB368@srv01.cluenet.de>
Errors-To: owner-nanog@merit.edu
On Sat, 15 Oct 2005, Daniel Roesen wrote:
> > It's as simple as setting up a route to 2002::/16 at the border
> > with a 6to4 conversion.
>
> The problem is building a high performance gateway. Currently you have
> about the following two options:
>
> a) set up / configure a Cisco used as 6to4 gateway
> b) set up a dedicated host (Unix box) as 6to4 gateway
>
> Approach a) is good for only few traffic, really.
<reminiscence>
You know, I still barely remember when I thought IOS could do just about
anything efficiently. Wow, have times changed.
</reminiscence>
Maybe to start -- but again, what kind of 6to4 traffic level are we
expecting yet? It's the chicken and egg all over again.
> Approach b) is more complex.
Yes, unfortunately.
> I'm waiting for vendor J to enable option c)... implementing 6to4 via
> the Tunnel PIC (or other PICs including the Tunnel PIC functionalities
> like Link Services PIC). It's a very simple translation/encapsulation
> which doesn't require any state keeping, shouldn't be a big deal. I can
> imagine a few larger IPv6 ISPs then suddenly implementing 6to4 gateways.
The only thing that makes 6to4 more complex, compared to a plain IPIP (or
GRE, or any other point-to-point vanilla tunnel protocol) tunnel is that the
far-side endpoint changes based on the tunneled payload.
That said, it should *not* be an unsurmountable problem -- if the demand is
there. Has anyone seen if the chicken laid the hatching egg yet?
--
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
