Re: [v6ops] Please review the No IPv4 draft

Gert Doering <gert@space.net> Mon, 14 April 2014 20:12 UTC

Return-Path: <gert@Space.Net>
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 94B281A039D for <v6ops@ietfa.amsl.com>; Mon, 14 Apr 2014 13:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.572
X-Spam-Level:
X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no
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 qk0cj89wivNG for <v6ops@ietfa.amsl.com>; Mon, 14 Apr 2014 13:12:39 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E41F21A02AC for <v6ops@ietf.org>; Mon, 14 Apr 2014 13:12:35 -0700 (PDT)
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BEE13629C5 for <v6ops@ietf.org>; Mon, 14 Apr 2014 22:12:31 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 92EA962994 for <v6ops@ietf.org>; Mon, 14 Apr 2014 22:12:31 +0200 (CEST)
Received: (qmail 80702 invoked by uid 1007); 14 Apr 2014 22:12:31 +0200
Date: Mon, 14 Apr 2014 22:12:31 +0200
From: Gert Doering <gert@space.net>
To: Simon Perreault <simon.perreault@viagenie.ca>
Message-ID: <20140414201231.GZ43641@Space.Net>
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> <534C17B8.8030209@foobar.org> <534C27C9.80701@viagenie.ca> <20140414194824.GY43641@Space.Net> <534C3F7D.3040406@viagenie.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="av70RPuHaysFRWqx"
Content-Disposition: inline
In-Reply-To: <534C3F7D.3040406@viagenie.ca>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GWrh6tfo1z8D3TyrebBobO7hsM4
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: Mon, 14 Apr 2014 20:12:41 -0000

Hi,

On Mon, Apr 14, 2014 at 04:05:17PM -0400, Simon Perreault wrote:
> Le 2014-04-14 15:48, Gert Doering a écrit :
> >> $ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient
> >>
> >> - Is that too hard to implement?
> > 
> > Yes.  My DHCP client is called "dhcpcd".  Nick's might be "pump".
> 
> I'm sorry, I don't see your point.

There are at least 3 different IPv4 DHCP clients on "Unix", and the
author and maintainer of the IPv6 DHCP client that is installed might
not know which IPv4 DHCP client you're using.

So either there is a standard way to communicate this across, as in
"all *IPv4* DHCP clients need to learn that", or it will fail in some
scenarios, no matter what the IPv6 DHCP client maintainers do.

(Also, I'd consider "just kill a foreign process" to be very rude - and
depending on the environment you're doing this in, it will be futile
as well, because a "service manager" of some sort could just report an
error, and restart the "failing" dhclient process).

> >> - Why does that need to be standardized? It would be part of an OS'es
> >> scripts and that usually doesn't get standardized.
> > 
> > Who do you expect to maintain that on the DHCPv6 client side, for all
> > possible combinations with DHCPv4 clients?
> 
> Why would anyone want to maintain that for all combinations of
> implementations?

"To make it work"?

[..]
> > To the contrary.  A network that does not provide IPv4 would want to set
> > that option.  You might just not have public IPv4 here, because it's
> > a zeroconfo network with only IPv4 link-local (169.254) addresses.
> 
> I'm not following your reasoning, sorry.

More bluntly: what makes you think that a network that has no IPv4 has IPv6?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279