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

[Alexandru Petrescu <[e-mail]>]

Le 13/11/2014 22:43, Jeroen Massar a écrit :
> 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.

I agree.

>
>> 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 - sponsor) is so broken, then they currently have
> a broken setup anyway. Hence, nothing to be fixed there.
>
>> Do not deprecate until you offer a solution satisfying a number of
>> requirements (currently unsatisfied by eg tunnel brokers).
>
> Which requirements are these?

Ones one would have to lay down and agree on before engaging in new work.

For example -1- must allow for reverse DNS ok, -2- must be secureable by 
existing e2e IPsec, -3- to the extent of possible be easy to set up for 
Clients and not involve intervention of another party (like when 
requesting an IPv6 address from an administrator, delayed paper forms, etc).

Alex

>
> Greets,
>   Jeroen
>
>
>