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

[Alexandru Petrescu <[e-mail]>]

Le 13/11/2014 23:39, Doug Barton a écrit :
> On 11/13/14 2:26 PM, Alexandru Petrescu wrote:
>> Le 13/11/2014 23:17, Doug Barton a écrit :
>>> On 11/13/14 1:19 PM, Alexandru Petrescu wrote:
>>>> 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.
>>>
>>> Alexandru,
>>>
>>> This is merely a special case of the general proposition, "6to4 does not
>>> work well, and needs to go away." I think your analysis is correct, but
>>> your conclusion is the exact opposite of what I think the facts dictate.
>>>
>>> Meanwhile, I'm interested in learning more about "a solution satisfying
>>> a number of requirements (currently unsatisfied by eg tunnel brokers)."
>>> What are those requirements, and why don't the tunnel brokers meet them?
>>
>> Requirements or goals whatever one calls them, should be agreed before
>> embarking on new work.
>
> But you're begging the question on the new work in the first place. :)

I am begging to give a replacement before deprecating.  If you dont 
deprecate and if vendor fixes bugs then one is fine (except reverse DNS, 
and _any_cast trust matters).

> You're asserting that tunnels cannot do things that you think we should
> be able to do, making sure that a) you're correct, and b) those things
> are worth the cost should be a precursor to any discussion on new work.
>
> For example, in response to Jeroen you asserted that tunnels don't allow
> reverse DNS.

The IPv6-in-IPv4 tunnel does not (I didnt mean IPv6-in-IPv6 tunnel not 
to allow reverse dns - I think it does).


> At least for HE, that assertion is demonstrably false.

Yes.

>> What do you think the goals would be?
>>
>> For example, the current tunnel brokers are very good but (1) are not
>> trustful, (2) force into later efforts to renumber when going native,
>> (3) require filling in forms.  6to4 has the advantage of not requiring 3.
>
> ... and yet I would assert that unless we're talking about something
> that is provider managed (such as 6rd) then automatically enabling it
> for the user is a bad idea. It will create more problems than it solves,
> and cause a lot of support calls, which ISPs are not going to like.
>
> I'm also pretty sure that to the extent I understand it, your point
> about renumbering is also invalid.

Ah no, please, dont plan on renumbering.  I dont even have software to 
renumber all these devices and all these radvd.conf files...

I can give up my 6to4 address space, but just once.  I dont want to do 
it again in 2 years or so. (I already did it once in the past, its painful).

(now I am a particular case and people could discuss theirs, if any).

Alex

>
> Doug
>
>
>
>