IETF Logo Mail Archive

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

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Tue, 10 December 2019 01:25 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
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 D9A5512002F; Mon, 9 Dec 2019 17:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P6ZijcW-R4qB; Mon, 9 Dec 2019 17:25:12 -0800 (PST)
Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86533120020; Mon, 9 Dec 2019 17:25:12 -0800 (PST)
Received: by mail-lf1-x143.google.com with SMTP id n12so12307282lfe.3; Mon, 09 Dec 2019 17:25:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4j2ZzxUwW8ccA7KFsVVKICg1o+x1H/1VxfohGIeBxm4=; b=TxrpdVbFhOEEP6ubOX0SIe1nSGYz8jPT2T6N2sG45uXxF1w7ucmfkkqNEtyW/gI2iL 2+MNL3ZZgj1UGHMi8mAY0HvxDH9w0b53A7Dd/ZnH0hHul/kCCSRcnmmrwMmJGfxv+cqw Y8aqhuDcI8o6XacUl/Uuhk+HRCR4RzDtODeLG+CWz3IpzEHGVvOojGQs/lkWvm82Hb8j 2zBuwP3YnKUrEc8WsTPJsUrQYgQxtm1YusfMibIIGRvxHyv7vVNfO6gHj+JGjmo5p6R/ xElsoklOJHwPuv9yFf2snBv29AysLbsoVtRztawj09or8jilK9qCMeC3O6Jp6JygeAgv ReQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4j2ZzxUwW8ccA7KFsVVKICg1o+x1H/1VxfohGIeBxm4=; b=nWbj5m4JJb8GLmXQ6vuXstb5UBhvxU0pZkRH/4bIRqgv6vd0KH8hHasxhfxNg80SLE qtdnQR54GvqQicAMTtnrQ+5uGj9RkKuZnbEyuoAN3I7d5Fm8vnlpeB+6QisFqSXaF/IW nXbguSMPVnVoLM6NxEyimNlMP9kUF3hoABWq9y0+pnAwrEHX5G0BjEaloDt+2SLtEjV7 +g5vrLi1yS7UWAxMk6C1bvIL9TD7MkB/R3ihGKNnDPzO3jPRvjWAyg9jL7UCOhynM4aw HcRbsXft4A4n+EBKzngRrWSs6lkQxcakmOADWW3tmZj05xR1sjaFWEAp50is3dyZC5eZ Tu4w==
X-Gm-Message-State: APjAAAXMlbsJPF5n5TqcOvjDMzl2Ju3Mc0nfMAvJYuI2Y4Ddaui8yDqb u0aiEr2CVRF0MeRub2OC7QSa9Ui0YNRBWw==
X-Google-Smtp-Source: APXvYqwp7bZ1CH08pcvTWM+6WgZIujGxQv8Thkezt6LUqo3/X4a/EvR2ffWFmFOo9JVvz3Mk1w9BPA==
X-Received: by 2002:a19:ac43:: with SMTP id r3mr17349614lfc.156.1575941110471; Mon, 09 Dec 2019 17:25:10 -0800 (PST)
Received: from ?IPv6:2001:470:6111::5d1? ([2001:470:6111::5d1]) by smtp.gmail.com with ESMTPSA id y29sm746158ljd.88.2019.12.09.17.25.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 17:25:09 -0800 (PST)
To: Roy Marples <roy@marples.name>, Lorenzo Colitti <lorenzo@google.com>
Cc: Jen Linkova <furry13@gmail.com>, dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List <v6ops@ietf.org>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <da078a21-b606-f0d9-3833-d66b20410853@marples.name> <CAFU7BASdWZv1RTVa5v4thbKPqCrmG886G+hK2J0UoZ3TbELDnw@mail.gmail.com> <b52fdd35-9663-e7df-7303-748a6b3a57ce@marples.name> <CAKD1Yr0vp2gaVRza+wei0qM6T9oN=iu39jRjK-cvhheorgE=Xg@mail.gmail.com> <67155c63-2442-2846-57f2-82fa4da16251@marples.name> <CAKD1Yr3y9eycfenN-t9oU_zgPHEZPy-AVXs3qXkWOBe9UXxVUQ@mail.gmail.com> <a6035aba-cab5-c779-c977-8b1a995eccfd@marples.name>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Message-ID: <c4512681-a064-adff-67f2-e26d58186db0@gmail.com>
Date: Tue, 10 Dec 2019 02:25:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <a6035aba-cab5-c779-c977-8b1a995eccfd@marples.name>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XYlwJSGNvdjINU29-1bv1B9Edeo>
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: Tue, 10 Dec 2019 01:25:15 -0000

On 05.12.2019 05:45, Roy Marples wrote:
> On 05/12/2019 03:48, Lorenzo Colitti wrote:
>> On Thu, Dec 5, 2019 at 11:50 AM Roy Marples <roy@marples.name <mailto:roy@marples.name>> wrote:
>>
>>      > The T2 timer is about the validity of the address that is offered
>>
>>     Wrong.
>>     The T2 timer addresses the lease as a whole. At this point the address
>>     is just meta data, just like domain or dns servers.
>>
>>
>> Regardless: the T2 timer is about the validity of the information that is offered. The V6ONLY_WAIT timer is different: it's about when the client should ask again if the client *does not request* the offer.
> 
> 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.
That's a good analogy. Would it be helpful if the V6ONLY_WAIT description was update to say something similar to: "Upon reception of the V6ONLY_WAIT option, the client sets its reverts back to DHCPDISCOVER retransmission and sets its retransmission timer to V6ONLY_WAIT seconds"? The effect would be mostly the same, with two changes:

1. technically it would not introduce a new timer
2. it would most likely require update of RFC2131

I don't particularly like that approach, but could live with that if that's what the consensus is.

>>     Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP
>>     should not depend on any IPv6 settings - or vice versa. Is it too much
>>     to ask to keep protocol setup separate?
Perhaps it's poorly named, but it's very much DHCPv4 option. The option is not supposed to affect any IPv6 behavior.

How about calling it what it really is: DISABLEV4? 

Tomek

v2.23.0 | Report a Bug | By Email