Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

Roy Marples <roy@marples.name> Thu, 05 December 2019 00:30 UTC

Return-Path: <roy@marples.name>
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 3AFF712008A for <v6ops@ietfa.amsl.com>; Wed, 4 Dec 2019 16:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name
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 34cUyA6aciVs for <v6ops@ietfa.amsl.com>; Wed, 4 Dec 2019 16:30:39 -0800 (PST)
Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::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 5A84212003F for <v6ops@ietf.org>; Wed, 4 Dec 2019 16:30:39 -0800 (PST)
Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 40504796 for <v6ops@ietf.org>; Thu, 5 Dec 2019 00:30:36 +0000 (UTC)
Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 0B72B1CD619; Thu, 5 Dec 2019 00:29:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575505780; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aTdJtT8krm7CSf8OYu6zxfF4oXG3YzRZPhCAyYjPTvE=; b=ndzzf1aUwgfFztywo7PhR+HG9UNCpJIizaSaH07BkFvcy6CK1GEuAbDfXIDxAZ1Gch2KcW DambZcoKILnJChniS+/V+jWwnFB+JcXEY5jT78M3NlbI6YMbrrNyffjOT99i4MUXSmJr6B 2gEBkCL9b9VTVPaVkJhGFAwhNOOREdU=
To: Jen Linkova <furry13@gmail.com>, dhcwg@ietf.org
Cc: draft-link-dhc-v6only@ietf.org, V6 Ops List <v6ops@ietf.org>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com>
From: Roy Marples <roy@marples.name>
Message-ID: <da078a21-b606-f0d9-3833-d66b20410853@marples.name>
Date: Thu, 05 Dec 2019 00:30:33 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/HoB7Hr5lrkt52EOS7eqQ4fjYV24>
Subject: Re: [v6ops] [dhcwg] 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: Thu, 05 Dec 2019 00:30:41 -0000

Hi Jen!

I maintain dhcpcd, a fairly popular DHCP and DHCPv6 client.

On 04/12/2019 12:09, Jen Linkova wrote:
> 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:

I disagree with a fair chunk of this.
It assumes that IPv6 is the be-all and end-all. Maybe one day we will 
have IPv8?

It would be much better to say that DHCP as a whole is disabled.
See RFC 2563 for an equivalent DHCP option for IPv4LL. This is fair 
enough because it's all IPv4 addresses. Set both options and you're golden.

BUT - what if we need to enable DHCP again? Should clients still listen 
for FORCERENEW? It does pose a small dilema because there isn't actually 
anything to renew.

So maybe we could let this new option fit in with T1 and T2 timers 
(well, effectively T2 as there's no address to unicast from) and you can 
even set this to infinity if you wanted to.

Roy