Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs

[Brian E Carpenter <[e-mail]>]

On 14/11/2014 10:43, Jeroen Massar wrote:
> On 2014-11-13 22:19, Alexandru Petrescu wrote:
>> Le 13/11/2014 20:43, Jeroen Massar a écrit :
>> [...]
>>> This is also what has been discussed on the list:
>>>   - deprecate anycast 6to4
>>>   - keep direct 6to4
>> YEs, I agree, and I would like to re-mention the point about software bugs.
>>
>> There is one particular 6to4 implementation in the wild which has two
>> different means to put up a 6to4 tunnel.  One is to just say '6to4' in
>> the cli, the other is to be specific and type that IPv4 anycast address.
>>
>> With the first means - it does not work.  Worse, it gets into a mode
>> where packets are output destined to random IPv4 addresses.
>>
>> Fix the bug.
> 
> That is a vendor issue. Nothing the IETF can do about.

No, but naming and shaming the implementation might be useful.

> 
>> What does this mean with respect to the deprecation effort?
> 
> That because of the bug that platform already is useless anyway, thus
> effectively it is already deprecated... ;)
> 
>> Do not deprecate the IPv4 anycast address because if so then the entire
>> 6to4 software on that platform will no longer work.
> 
> If that platform (which one btw) is so broken, then they currently have
> a broken setup anyway. Hence, nothing to be fixed there.

I agree. Definitely not the IETF's problem.

> 
>> Do not deprecate until you offer a solution satisfying a number of
>> requirements (currently unsatisfied by eg tunnel brokers).
> 
> Which requirements are these?

If anycast 6to4 worked correctly, we wouldn't be deprecating it
at all. But it's broken, we tried to fix it 3 years ago (RFC 6343),
and it's still broken. The idea of deprecating it is to help users
avoid a broken solution. Those ~100k users that Google sees would be
better off with IPv4-only.

   Brian