Re: [v6ops] Please review the No IPv4 draft

Nick Hilliard <nick@foobar.org> Tue, 15 April 2014 15:21 UTC

Return-Path: <nick@foobar.org>
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 73E801A06B5 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 08:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bRjjBGS28Bs6 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 08:21:17 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED021A06BC for <v6ops@ietf.org>; Tue, 15 Apr 2014 08:21:15 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.dyn.netability.ie (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s3FFLBp1090035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2014 16:21:11 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.dyn.netability.ie
Message-ID: <534D4E85.5040104@foobar.org>
Date: Tue, 15 Apr 2014 16:21:41 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <534BF5A5.5010609@viagenie.ca> <CAKD1Yr0j5+r6K8APoFageJz2RESKj5vkk10Ybom0p3Vec_G0YQ@mail.gmail.com> <534D319C.3030800@viagenie.ca>
In-Reply-To: <534D319C.3030800@viagenie.ca>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IIDCZeWvP7BKtD9ptVBjmCDI76I
Cc: "v6ops@ietf.org WG" <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 15:21:20 -0000

On 15/04/2014 14:18, Simon Perreault wrote:
> Basically we're trying to make DHCPv4 clients shut up.

then there's confusion about the draft's aims.  A good deal of the draft
goes into detail about completely stopping all ipv4 services on the client
system (which is something that is not going to be simple to achieve in
practice), whereas your stated aims and justification in the draft are all
about getting dhcpv4 clients to stop making noise.

Getting DHCPv4 clients to shut up is an admirable goal and I think it's
worth pursuing this by using the front-door method of creating a dhcpv4
no-service option (suggestion: use dhcpv4, implement a timeout, make it
interface specific, i.e. don't attempt to apply the configuration to
multiple interfaces, and don't attempt to complicate things by creating a
requirement to completely disable ipv4).  This would not be difficult to
achieve either operationally or from a protocol point of view; it would be
both clear and unambiguous, and it would not suffer from the technical /
implementation problems that either Ray or I brought up.  As a side issue
you may want to consider renaming the draft -nodhcpv4- instead of -noipv4-.

Getting hosts to stop talking ipv4 completely is a much more difficult
problem.  If you want to write a draft about this, then you need to start
from the beginning explaining the problem you're trying to solve, why
you're trying to solve it and then provide guidance on how it should be
handled.  This analysis is not present in your current draft.

At the very least I would be curious to know how and why a DHCP or RA
request coming in on any random interface should have the authority to
completely disable an entire communications protocol, O/S wide.  As a
client, I might well have multiple interfaces configured, only one of which
has ipv6 disabled, and it would be difficult to understand how e.g. my 3g
provider should have the right to tell me that my operating system should
completely shut down ipv4 while my computer was connected to my home wifi.

Nick