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

[Jeroen Massar <[e-mail]>]

On 2014-11-13 23:48, Alexandru Petrescu wrote:
[..]
>>> 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'll have to come up with plausible requirements though.

The ones you are giving are satisfied by various means that are able to
provide you with proper connectivity for well over 10 years already.

>> 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).

The protocol used is irrelevant to the ability to assign reverse DNS.

Unless you are talking about Teredo where it is just too troublesome to
do so.

Please see:
https://www.sixxs.net/faq/connectivity/?faq=comparison

for a list of pro/cons for each protocol. There is also a 'reverse DNS'
column there. All of the protocols have "optional" reverse as it depends
on the provider providing it.

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

Check:
https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

for a nice feature comparison.

>>> 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).

Automating the generation & distribution of those configs helps a lot.

Also, you could have requested a prefix from the three bigger Tunnel
Brokers who have been operating for well over 10 years and you could
have had a static prefix for all that time already...

Greets,
 Jeroen