IETF Logo Mail Archive

Re: [v6ops] Please review the No IPv4 draft

Owen DeLong <owen@delong.com> Tue, 15 April 2014 16:53 UTC

Return-Path: <owen@delong.com>
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 0D9FA1A0499 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 09:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level:
X-Spam-Status: No, score=-2.273 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.272, 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 IUadZlrScdZx for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 09:53:34 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 887B81A02E0 for <v6ops@ietf.org>; Tue, 15 Apr 2014 09:53:34 -0700 (PDT)
Received: from owens-mbp.meeting.arin.net (unknown.servercentral.net [50.31.214.180] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s3FGlewD006926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 09:47:41 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s3FGlewD006926
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1397580461; bh=E3qBxCtlp2wdwfRxXtgZiPlJqd4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QNy8BJvH2zVJYs9sJIZztfRxCwMQmAwTtiTU9jE1vOQPmATUOvrl4q83XIElrgZ+8 570cDiM7Cvv5+M9wrGj8RBvi5bes4k35gOPnxKI9sNW0P+mMtFFCxLE9CILvDw0KyM O2bfqMS//KmPWZIf75HqV+GDWwjK0mUAzzr5bNBE=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <534D5BD1.5020406@viagenie.ca>
Date: Tue, 15 Apr 2014 09:47:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <71F7DEDD-FF39-4D16-8C62-23ABC9CA4734@delong.com>
References: <534BF5A5.5010609@viagenie.ca> <CAKD1Yr0j5+r6K8APoFageJz2RESKj5vkk10Ybom0p3Vec_G0YQ@mail.gmail.com> <m2k3argftt.wl%Niall.oReilly@ucd.ie> <alpine.DEB.2.02.1404151026060.10236@uplift.swm.pp.se> <20140415083615.GB43641@Space.Net> <alpine.DEB.2.02.1404151048250.10236@uplift.swm.pp.se> <4E64CF95-F984-48F2-AEFA-A3E9FF9D38A3@delong.com> <534D5BD1.5020406@viagenie.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
X-Mailer: Apple Mail (2.1874)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 15 Apr 2014 09:47:41 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_aaWAy25utkX1l8bv3jhjlmCpZE
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: Tue, 15 Apr 2014 16:53:42 -0000

On Apr 15, 2014, at 9:18 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Le 2014-04-15 11:09, Owen DeLong a écrit :
>> I would support an RA flag that says “If you’re reading this message, don’t do IPv4 on this network”.
>> 
>> That’s not even close to what is proposed here.
> 
> Uh?
> 
> At the very least, it was our intent to propose that very thing. An IPv4
> kill switch.
> 
>> What is proposed here is a variety of IPv6 methods for telling a client to turn off it’s IPv4 dynamic configuration requests and there’s no reason to put that into IPv6 at all.
> 
> I'm sorry, I'm not following.
> 
> If your problem is with "variety of methods", then I can understand. We
> started with DHCPv6 only, then we added RA because people were asking
> for it. We expect one could be removed if it poses a problem.

IMHO, this should be reduced to a single bit in an RA if it is implemented in IPv6 at all.

Owen

v2.23.0 | Report a Bug | By Email