Re: 6to4 to non-6to4

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Rémis, and all,

Just to summarize for the group a coffee conversation
with Rémi D and Keith Moore, one possible way forward
is a new document describing best (and worst) practice for
6to4 relay deployment, and associated 6to4 host behaviour.

    Brian

On 2009-03-26 11:01, Rémi Després wrote:
> Brian E Carpenter  -  le (m/j/a) 3/25/09 2:23 PM:
>> 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.
>>   
> Agreed (a partial backtrack): if a 6to4 host first checks that it has a return 
> path from a native v6 site, then it may proceed rather than giving up v6 and 
> falling back to v4.
> 
> Note however that, for still some time, falling back to v4 when the quality of 
> v6 paths is not guaranteed is not a bad choice.
> Note also that Nathan's proposal checks only connectivity. Uncertainty on QoS 
> remains, due to the lack of control on which 6to4 relay routers are used in 
> return paths.
> 
>>> 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. 
> In my understanding, backing up to v4 when v6 is not fully reliable doesn't 
> create  black holes. It prevents them.
> At least where 6to4 qualification is not available yet (and substantial host 
> modifications don't come overnight), avoiding 6to4 to non-6to4 remains IMHO a 
> good way to avoid people to be disappointed with IPv6 and complain.
> 
> Regards,
> 
> RD