Re: [v6ops] Please review the No IPv4 draft

Doug Barton <dougb@dougbarton.us> Wed, 30 April 2014 08:25 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 612C31A0757 for <v6ops@ietfa.amsl.com>; Wed, 30 Apr 2014 01:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.047
X-Spam-Level:
X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 PUQkeOfNl4H3 for <v6ops@ietfa.amsl.com>; Wed, 30 Apr 2014 01:25:33 -0700 (PDT)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7EACE1A6F14 for <v6ops@ietf.org>; Wed, 30 Apr 2014 01:25:33 -0700 (PDT)
Received: from [192.168.1.39] (rrcs-67-53-121-163.west.biz.rr.com [67.53.121.163]) by dougbarton.us (Postfix) with ESMTPSA id A92B522B1A; Wed, 30 Apr 2014 08:25:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1398846331; bh=jyUdU/z4jcSkvcpQvX6wrYzdrCUI9TfTl8lm04d5yhA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Szdu5+EzV/LUI86ZTaPwHjc/eoFhndZVt/hDiFqoig4odT/Xyyd4T6AapcrV4Zlsy MndIwoGvUVAX1yiwocp60/EujKEdeI2kmNZHfrDQAUKmt0mvBnF3XflpVKAWymQgPc v7Gb4rX4gE6I9Sgk+rpMNeyw0FTuNIXuYEoQRyVc=
Message-ID: <5360B37B.8010908@dougbarton.us>
Date: Wed, 30 Apr 2014 01:25:31 -0700
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>
References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <F08AF14D-22C6-4F4C-9388-670EB4CD8453@nominum.com> <F2A0EC2F-6B41-4560-88BA-CEBF3E921B61@delong.com> <CAEmG1=oK8iHAms2_uVBsCtpCG7xBdhRfh9QQrd+JXUXgjBPqPA@mail.gmail.com> <0901D65B-EA79-4E20-987D-9BA01CEDDAB3@delong.com> <B3942C2F-C08E-42F2-9038-92C3C63E0023@nominum.com>
In-Reply-To: <B3942C2F-C08E-42F2-9038-92C3C63E0023@nominum.com>
X-Enigmail-Version: 1.7a1pre
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/0X0jV9tqV4X8h2bDn0kaGB0d72g
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Please review the No IPv4 draft
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: Wed, 30 Apr 2014 08:25:41 -0000

On 04/14/2014 12:42 PM, Ted Lemon wrote:
> On Apr 14, 2014, at 2:30 PM, Owen DeLong <owen@delong.com> wrote:
>> Seems to me that the same potential for abuse exists with either situation.
>
> This is true, and the remedy exists as well.  It's worth pointing out that "please review" doesn't mean "please redesign this."   It means "please point out technical flaws that you see."   None of what you or Nick has said sound like technical flaws to me—they sound like "I would prefer to do it this other way."

Ted,

Sometimes ideas that are cooked up in one environment don't stand the 
light of day when they escape the environment they were created in. I 
think this is one of those times.

First, any draft that suggests adding new options to RA is going to get 
a negative reaction from me, for reasons I've stated ad nauseum in the 
past, and I really don't want to open that can of worms on this point.

Second, as others have pointed out this is layering violation of 
monumental proportions, and thinking about this as an implementor (even 
if the RA stuff was dropped) I would not be keen to try and navigate 
this. Services which start up listening on IPv4 networks which suddenly 
have those networks yanked out from under them comes immediately to 
mind, but I haven't even started thinking hard about the problem(s) yet.

Third, this draft doesn't pass a simple laugh test. If you don't want 
IPv4 on your network, configure it away ... and you're done. There is no 
need for any of this.

Fourth, it doesn't pass the "stop tinkering with the protocol and let 
the installed base settle on a feature set" test.

Finally, and please pardon me for being brutally honest, this whole 
concept seems childish. When I saw the subject line I was deeply 
concerned that this was going to turn out to be a "We hate IPv4 so much 
we want a knob to make it go away" type of thing. As much as the authors 
may not have intended it that way, that's exactly how it reads.

So with all due respect to the authors, and the working group, this is a 
terrible idea, and the draft should be allowed to expire.

Doug