IETF Logo Mail Archive

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

Roy Marples <roy@marples.name> Thu, 05 December 2019 14:48 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 30DAB12004F for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2019 06:48:07 -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=unavailable 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 N_IFdv6raeAK for <v6ops@ietfa.amsl.com>; Thu, 5 Dec 2019 06:48:06 -0800 (PST)
Received: from relay2.marples.name (relay2.marples.name [77.68.23.143]) (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 F2A71120019 for <v6ops@ietf.org>; Thu, 5 Dec 2019 06:48:05 -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 8D84379B for <v6ops@ietf.org>; Thu, 5 Dec 2019 14:48:03 +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 F0F121CD5DA; Thu, 5 Dec 2019 14:47:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575557224; 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=liLiXgXnqpwpjvxsTWMYCgQCELQWyqzDf0Y8FoLDjTg=; b=PLTQBxmR0INwC8lkIajS7Px4AD4y/qH2bQGSkeeGEDYHPpLF8lRGArCrjKvAaG4NH8ydts 4U5HJDmSLDNVvJHOXHSzMMNcIB6pNqu2ZobuCKn/bPEClLJeGbXdKqgiiHOY7z1gbdBPan +kJbe3mWx7vdJrXerAr1VYOFi1hpzxM=
To: Ted Lemon <mellon@fugue.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg@ietf.org, V6 Ops List <v6ops@ietf.org>, draft-link-dhc-v6only@ietf.org
References: <a6035aba-cab5-c779-c977-8b1a995eccfd@marples.name> <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com>
From: Roy Marples <roy@marples.name>
Message-ID: <e816e5b8-3db8-009f-fbb2-cf08ddd10237@marples.name>
Date: Thu, 05 Dec 2019 14:47:59 +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: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mNvUxpZSz93_VJvgTCHkpFLl1kU>
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 14:48:07 -0000

On 05/12/2019 14:39, Ted Lemon wrote:
> On Dec 4, 2019, at 8:46 PM, Roy Marples <roy=40marples.name@dmarc.ietf.org> wrote:
>> So in simple terms.
>> The server offers some information.
>> Given this information (in current DHCP semantics) we can RENEW (T1) or REBIND (T2).
>> If the client does not request the offer (hey! I see this new fangled option here that says NO DHCP) the client can still accept the T2 timer at the very least.
>>
>> Think of the analogus RFC 7083 - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new timers.
> 
> There is a reason why DHCP includes a parameter request list option.  If the client doesn’t ask for this newfangled option, it shouldn’t see it.  And so we can know for sure that the client supports this capability, because it asked for it.
> 
> Is there any reason why we /wouldn’t/ want to do this?

None at all.

I think it's a good option to have, but I strongly believe it should 
just be a boolean on/off option.

The host should be as dumb as possible.
If the server knows *something* else is around that it should use 
instead it can disable DHCP via this option.

The *something* else is probably IPv6 but I don't see why this RFC 
should mention it other than a use case.

Roy

v2.23.0 | Report a Bug | By Email