IETF Logo Mail Archive

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

<mohamed.boucadair@orange.com> Thu, 05 December 2019 08:58 UTC

Return-Path: <mohamed.boucadair@orange.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 020A11200F6; Thu, 5 Dec 2019 00:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 QUbHWitn599U; Thu, 5 Dec 2019 00:58:56 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3D81200F1; Thu, 5 Dec 2019 00:58:55 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 47T8lf3355zywd; Thu, 5 Dec 2019 09:58:54 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 47T8ld6sYWzDq8l; Thu, 5 Dec 2019 09:58:53 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 09:58:54 +0100
From: mohamed.boucadair@orange.com
To: Lorenzo Colitti <lorenzo@google.com>
CC: Jen Linkova <furry13@gmail.com>, Bjørn Mork <bjorn@mork.no>, "dhcwg@ietf.org" <dhcwg@ietf.org>, V6 Ops List <v6ops@ietf.org>, "draft-link-dhc-v6only@ietf.org" <draft-link-dhc-v6only@ietf.org>
Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option
Thread-Index: AQHVq0Py0EzcIgM90k+qjQhPGFF0raerPXRQ
Date: Thu, 05 Dec 2019 08:58:53 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAFU7BARiwGZohd5d-hqUUpH5jzjFerbLGcOBVc+S9BC3OYMFcw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAKD1Yr2ZuCXWvRGi-hTj3g0A24WHr=ept9CqFx6_mP3vKUcaqA@mail.gmail.com>
In-Reply-To: <CAKD1Yr2ZuCXWvRGi-hTj3g0A24WHr=ept9CqFx6_mP3vKUcaqA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E429BOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6BWVX96Vjz-neNL7mXfpxE9QHvY>
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 08:58:59 -0000

Lorenzo,

IMO, a host will need to “pause” the v4 configuration for xxx ms to make sure the configuration (v4/v6) is consistent.

Consider the example of an application that needs CLAT to work. Even if the DHCPv4 returns a signal that it is safe to release the IPv4 address, that application will need to wait for the PREF64 to work. The delay for that application will be the same.

Cheers,
Med

De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoyé : jeudi 5 décembre 2019 09:14
À : BOUCADAIR Mohamed TGI/OLN
Cc : Jen Linkova; Bjørn Mork; dhcwg@ietf.org; V6 Ops List; draft-link-dhc-v6only@ietf.org
Objet : Re: [dhcwg] IPv6-Only Preferred DHCPv4 option

On Thu, Dec 5, 2019 at 4:55 PM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
> I agree that in theory pref64 presence is a very good implicit signal
> for 'you don't really need IPv4'. However when a host connects to a
> network it does not know if pref64 is available when it starts DHCPv4
> process. So to use RAs as a signal you need to either delay DHCPv4 (==
> penalize v4-only and dual-stack networks) or do all those undesirable
> RELEASE tricks later.

[Med] The machinery will be almost the same as you are doing with your new option. You don't need to delay DHCPv4. The only difference is the signal on which to rely to make the decision.

I don't think that works. What is needed is a signal to the host that IPv4 should not be used if the host is capable of IPv6-only operation. That signal *must* be available before DHCPv4 assigns an address to the interface, because once an address is assigned, the host will not wait for anything else and will allow apps using it immediately. This is by design; it ensures that IPv4-only networks are as fast as they possibly can be. Therefore, this signal cannot be in any IPv6 packet, including an RA, a RFC 7050 DNS reply, a PCP NAT64 option, or a DHCPv6 option.

v2.23.0 | Report a Bug | By Email