Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Bjørn Mork <bjorn@mork.no> Wed, 04 December 2019 13:31 UTC

Return-Path: <bjorn@mork.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07BE12011E; Wed, 4 Dec 2019 05:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.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 TQfXLsOmXLTu; Wed, 4 Dec 2019 05:31:30 -0800 (PST)
Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 D4374120816; Wed, 4 Dec 2019 05:31:29 -0800 (PST)
Received: from miraculix.mork.no ([IPv6:2a02:2121:2c8:26c5:b15d:7b70:572:cc53]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id xB4DVNT4031099 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Dec 2019 14:31:23 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1575466285; bh=xhW1IhRuzDb+2S11lEAq+ILKsI3AWcdHr+TLnJn2hW4=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=nS7+b1+8ID8/xtXcYsfxHvtag7ShFUzcIeecZzHDY783TyLFXvYXkpBw+TZSEPBBQ LMyV7HlbCSXYFZyqXPC56RmXSm42/hpHX+OIFHHEM4wTNNCQWuM0ZRy2bAbv6Ik3+d AfGCuWVR40rU68+M0JbjiOvpmr4lPOXkxlqU2pyQ=
Received: from bjorn by miraculix.mork.no with local (Exim 4.92) (envelope-from <bjorn@mork.no>) id 1icUkP-0002tB-V2; Wed, 04 Dec 2019 14:31:17 +0100
From: Bjørn Mork <bjorn@mork.no>
To: Jen Linkova <furry13@gmail.com>
Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List <v6ops@ietf.org>
Organization: m
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com>
Date: Wed, 04 Dec 2019 14:31:17 +0100
In-Reply-To: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> (Jen Linkova's message of "Wed, 4 Dec 2019 23:09:08 +1100")
Message-ID: <8736e0gqu2.fsf@miraculix.mork.no>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.101.4 at canardo
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jQzgfKQTZfPKmRluZlrwy9hfel8>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Dec 2019 13:31:33 -0000

Jen Linkova <furry13@gmail.com> writes:

> Hello,
>
> One of the biggest issue in deploying IPv6-only LANs is how to do it
> incrementally, when some hosts work just fine in NAT64 environment
> while some legacy devices still need IPv4. Doubling the number of
> network segments (having an IPv6-only and dual-stack segments of each
> type) is an operational nightmare. So it would be just awesome if all
> devices can co-exist in the same network segment and hosts capable of
> operating in IPv6-only environment do not consume IPv4 addresses.
> So here is the draft proposing a new DHCPv4 option to help saving IPv4
> addresses and deploying IPv4-as-a-service:
>
> Name:           draft-link-dhc-v6only
> Revision:       00
> Title:          IPv6-Only-Preferred Option for DHCP
> Document date:  2019-12-04
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
> Htmlized:       https://tools.ietf.org/html/draft-link-dhc-v6only-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only
>

  "While IPv6-only capable devices might use a
   heuristic approach to learning if the network provdes IPv6-only
   functionality and stop using IPv4 if it does, it might be practically
   undesirable.  One important reason is that when a host connects to a
   network, it does not know if the network is IPv4-only, dual-stack or
   IPv6-only.  To ensure that the connectivity over whatever protocol is
   present becomes available as soon as possible the host usually starts
   configuring both IPv4 and IPv6 immidiately.  If hosts were to delay
   requesting IPv4 until IPv6 reachability is confirmed, that would
   would penalize IPv4-only and dual-stack networks, which does not seem
   practical. "


Why can't the client just release the IPv4 address when it finds it has
IPv6 connectivity?  This would also avoid the problems you introduce
when the network falsely claims IPv6 support.



Bjørn