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

6to4 to non-6to4

On 2009-03-26 08:25, Rémi Després wrote:
> Rémi Denis-Courmont  -  le (m/j/a) 3/25/09 10:16 AM:
>> On Wednesday 25 March 2009 18:05:36 james woodyatt wrote:
>>   
>>> [moving discussion into V6OPS from 74attendees]
>>>
>>> On Mar 25, 2009, at 08:03, Rémi Després wrote:
>>>     
>>>> RFC 3068 (An Anycast Prefix for 6to4 Relay Routers) does more harm
>>>> than good. IMHO, it should be deprecated.
>>>>       
>>> I would support that, providing first that 6RD is A) adopted as a
>>> proposed standard, and B) comes to see more widespread deployment than
>>> 6to4.  I also believe the latter is very likely to happen contingent
>>> on the former, so I would vigorously support taking up 6RD as a
>>> working group activity.
>>>     
>>
>> Anycast 6to4 has problems. I guess Nathan Ward will present some of those. 6RD 
>> solves many of the shortcomings of 6to4, _assuming_the_ISP_deploys_it_.
>>
>> But lest we deprecate the entire scenario of automatic IPv6 setup without ISP 
>> support, I fail to see how 6RD can replace anycast 6to4.
>>   
> Thanks for your comment.
> 
> Using 6to4 between two 6to4 user sites is NOT a problem, and indeed MUST remain 
> possible.
> But using a source 6to4 address to reach a non-6to4 destination IS a problem, 
> and IMHO MUST be deprecated ASAP.

I'm sorry but this makes no sense. 6to4 users (they exist) need to
reach the IPv6 Internet, and a 6to4 relay is the only way to do that,
so they have to exist too. Otherwise we are creating IPv6 islands, which
is a bad idea for encouraging adoption.

The fact that the anycast technique leads to black holes is well known;
I've been a victim of it myself. I'd be much happier if 6to4 had been
deployed as described in RFC3056, but we have to deal with reality.
Once again, see draft-nward-6to4-qualification for one way to
do that.

> 
> 6to4 to non-6to4 being the only reason for 6to4 relay routers, and for the 6to4 
> anycast address to reach them, they are what needs being deprecated.
> 
> I guess RFC 3484 should also be updated to say that a 6to4 address MAY be used 
> if both source and destination are 6to4, but ONLY in this case.

Absolutely not. That would make the black hole problem global instead of
localised. 6to4 was given its own /8 global prefix so that longest match
would do the right thing, within the scope of the 3484 rules. (Yes,
3484 was published after 3056, but there was coordination.)

    Brian