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

Doug Barton <dougb@dougbarton.us> Thu, 13 November 2014 22:39 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC311AE0DB for <v6ops@ietfa.amsl.com>; Thu, 13 Nov 2014 14:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YnudXY7zP_H for <v6ops@ietfa.amsl.com>; Thu, 13 Nov 2014 14:39:06 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF051AE0D0 for <v6ops@ietf.org>; Thu, 13 Nov 2014 14:39:06 -0800 (PST)
Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id EC36A22B1C; Thu, 13 Nov 2014 22:39:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1415918346; bh=ESCK/4h6aHa8WajQpzmGXsoXOh53Sq+c8wIX4ZUMFy4=; h=Date:From:To:Subject:References:In-Reply-To; b=k7kXggvbLgD2yret9/VehUwsDEtN9bDOFpB76y16x4PmBq3VxR+gn3BwQv7nmPSAu BocMnzDkAQtcUZ5wPf84Ogu4fi2ygeqsM0x3zXjZSWThy7cLOzqrupSc869Du3XTaM gYHzwJQpmB2XavbYkvEnB9TJ6QAxyqHLIEqw3xNo=
Message-ID: <54653309.6010407@dougbarton.us>
Date: Thu, 13 Nov 2014 14:39:05 -0800
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, Jeroen Massar <jeroen@massar.ch>, v6ops@ietf.org
References: <20141111054026.11197.49784.idtracker@ietfa.amsl.com> <5461A23D.5020506@gmail.com> <546264A5.4050309@umn.edu> <546271A2.907@gmail.com> <5463C716.1030805@umn.edu> <54646DBE.9060800@dougbarton.us> <20141113084029.GT31092@Space.Net> <5464E4F6.9070401@gmail.com> <5465021A.2080305@dougbarton.us> <546509F1.5060508@massar.ch> <54652069.30805@gmail.com> <54652E05.1020402@dougbarton.us> <5465300C.8050206@gmail.com>
In-Reply-To: <5465300C.8050206@gmail.com>
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D_YY1oKRbW8UF1a_56vOiIDQ0rM
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt - software bugs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Nov 2014 22:39:07 -0000

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

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. At least for HE, that assertion is demonstrably false.

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

Doug