[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6to4 public anycast relay considered a bad think (was Re: 6to4 connectivity test)



On 2008-02-02 12:23, Alain Durand wrote:
> 
> 
> On 2/1/08 4:56 PM, "Gert Doering" <gert@space.net> wrote:
> 
>> Hi,
>>
>> On Fri, Feb 01, 2008 at 03:46:22PM -0500, Alain Durand wrote:
>>> Essentially, expecting to get a functioning 6to4 relay is expecting a free
>>> lunch. Who is going to pay for it?
>> If enough ISPs provide working 6to4 relays, serving their own customers
>> (that pay for the bandwidth, be it IPv4 or IPv4-encapsulated IPv6), the
>> model would work just fine.
> 
> Why should ISP X pay to run a 6to4 relay that would in essence offer transit
> for customers of other ISPs? And let's say that ISP X offer the outband
> relay for its customers only, how would the packets come back from the real
> IPv6 Internet to ISP X IPv4 network? Is ISP X suppose to announce a
> de-aggregate of 2002://16? That would create a huge increase in the routing
> table size...

Not allowed by RFC 3056. As stated there, the scope of advertisements
for 2002::/16 needs to be *managed*, because you're going to have to
encapsulate anything that arrives, on the assumption that there will
be a 6to4 router at the specified V4ADDR. So you'd better make sure
that only the IPv6 locations you want to serve can see your particular
2002::/16 advertisement, because you have no choice about the
V4ADDR destination.

Similarly, the scope of IPv4 advertisements for your relay (whether
it's 192.88.99.0/24 or anything else) needs to be limited to
IPv4 locations that you're willing to serve for 6to4. You have no
choice about the IPv6 destination.

In neither case do those locations have to be your own customers,
however. And there's no reason to expect symmetric paths.

I always expected 6to4 relay deployments to be altruistic,
not related to revenue.

    Brian