Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

"Bernie Volz (volz)" <volz@cisco.com> Tue, 10 December 2019 16:11 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87D1200E5; Tue, 10 Dec 2019 08:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D68TsrzJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YW5srO1u
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 rGU1orS4LG5v; Tue, 10 Dec 2019 08:11:21 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D0A1200E0; Tue, 10 Dec 2019 08:11:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8423; q=dns/txt; s=iport; t=1575994281; x=1577203881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EMMTGfvGFUgpw8eXvUK5irmsQT9qgI6bc4E02CRAx4M=; b=D68TsrzJTPwdbDl4dPGaNSzTB/aTSHnbr8udQMbjMFGgVnJq6oNOFoPh hDFM+a4IOjeDHYQDDtiunWOP1umAlZOrIg5A/jMOQlYiZFoXGT0sOF4Vm OGAihNKFs20/ROdSvTSft8eFSFfs4pbG3FUim/u2BnA8IjvtpKjxdZ3i0 U=;
IronPort-PHdr: 9a23:ySnWGRVNfUI/0tDsch6/kyupJTLV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdEwd4TgxRmBceEDUPhK/u/cSs+DuxJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CyAABlw+9d/40NJK1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF+gUskBScFbFggBAsqCoc/A4sFgl+JW44rglIDVAkBAQEMAQEYCwoCAQGEQAKCAyQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBEC4BASwJAgELBAIBCBEDAQEBKAchBgsUCQgCBAENBQgTB4I1TIJGAy4BAgyidwKBOIhhgieCfgEBBYE5Ag5BgwsNC4IXCYE2hRyGfBqCAIERR4JMPoIbSQEBAgEBGIExGINAgiyNOgeIXmCWdy9DCoIvhyOKLYQ7gkJ0hwKQAI5KiEWCF4tvg2YCBAIEBQIOAQEFgWkiN4EhcBUaIYJsCUcRFIxmBwIag1CFFIU/dAGBJ4xzAYEPAQE
X-IronPort-AV: E=Sophos;i="5.69,300,1571702400"; d="scan'208";a="379841184"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 16:11:20 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAGBKCW024317 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2019 16:11:20 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 10:11:19 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 11:11:18 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 10:11:18 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PUF3ScbJvD+oLAjcROnowm/JcpJ54A3P6livKyaR3CAtn7yeUnOZdUpsGCf/PtrEzSJ8RdToi0JlxTMia4OSZU9PNmxHaNFWo53S7PdfBKJ/HWtSPLmTmr7Y3O6CTxOn+85GaVXZQklSDz8pf55+4xpyGVJRs2t+UNxjDhgeV36Ajjdvb/mHwP+d5Yx1QA4N2Vd2Nyl6idym7Rok67wjPd0UcHDFMSDD2mNZ50Og1yvyCXUaErc9i4FU8h97E11oRxgG+61G71RwMyPO6D9fWnr4nY2qIAnFOWPa5VUiCEguR7O0biZZYJf1lKjujR0oiNLoKRuRjb1wlbd5yZi/kw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9zhTjfoXFVdXmiF/A72XY2lzmR3+DPSnLPK/2GbVjA=; b=WF9vd63lJx1BIg7fzA/GHS0BvnKTUsOcECkVTx4D1hVqJAR51nNm8HPcTIkijY/Fp7ma6l7HLjT7Ulp71bfav/hSsynleP999SxKzxO5W+FAhHhpD+gmPcaAc4HgHFdX8Q1zA/LbmhlMfQgthsvLeXpzQyGCFU4uEVxkLO23KPoS/jg3IseQRkuIwIfUcfgAldI/rMwvio1cC34L8C15XEZVRiuCazwnOwMvYKbbeUzAwCjnmbg3MBAKCSxQUDvjJVehEaMHnlvDLiadVuAEgqxZ6XOwM+/mamD6O2EZRUnKJPpXjl8DRUyNrH6URDqfFQxCtmRXa6QwS0VA753pNA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9zhTjfoXFVdXmiF/A72XY2lzmR3+DPSnLPK/2GbVjA=; b=YW5srO1uxFJHDLJh7YwP4cX05wPCk4U3DCmeIwDvHfhFZWZatpltE4QcaOs+lQQBh+91mkqBrFTCJUKLX22QDV8MTtVcuF6TmRZKcZq/RsngsMIVmYsDDv2LwgZtjI6DfCwZ3GovlXgOw49S/XhtwUM2CjPqg1e8o0wobsSslF4=
Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3466.namprd11.prod.outlook.com (20.176.123.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Tue, 10 Dec 2019 16:11:17 +0000
Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 16:11:17 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Jen Linkova <furry13@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
CC: V6 Ops List <v6ops@ietf.org>
Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt
Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfA==
Date: Tue, 10 Dec 2019 16:11:16 +0000
Message-ID: <DM6PR11MB41379502CE18C7AF513181F0CF5B0@DM6PR11MB4137.namprd11.prod.outlook.com>
References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <CABKWDgx5SSBP_K7BWxe4aPn9DKm-VPo62OXjsVZP8PRjfu0C2w@mail.gmail.com> <CAFU7BAQHkYh-EDLopUbWvw-gq8i5jttacVogKXUaJvJcBTdCOA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com;
x-originating-ip: [161.44.67.100]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 72bb1441-85de-4ae1-8ada-08d77d8b9648
x-ms-traffictypediagnostic: DM6PR11MB3466:
x-microsoft-antispam-prvs: <DM6PR11MB3466ADB2401F04509F9A293ECF5B0@DM6PR11MB3466.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(346002)(376002)(366004)(189003)(54164003)(199004)(13464003)(8936002)(9686003)(81166006)(86362001)(966005)(33656002)(8676002)(81156014)(52536014)(19627235002)(2906002)(478600001)(26005)(186003)(110136005)(66556008)(76116006)(7696005)(316002)(4326008)(66476007)(66446008)(66946007)(71200400001)(53546011)(6506007)(15650500001)(5660300002)(55016002)(64756008)(66574012)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3466; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pzOul8RWnPlc9AoprgRWwuiYfapG5pfgdVW+I6BDTr/EXGiMA43CSOlQ5JM4ZxKW4rYNrlILPN6Y14hso8FaLTdKowzSc4fBV9hHEsz+Pyf9P2lQNoPoGoSCslw3nlhQXpFNzziQl2PRkP5cLo2oZqzmYFLRDw3E42ZEqI1XQm/QBD6X7XW0h3hdU2LmDA0XhxhYeOdYRlUsGaSAssi7rIJHzkqRZVcxWkh6HtjJhgrVloZQ9h0gb7BFfPkB8z03QcFMmL375FwNc4Shvl+pe2d/yeAZy9OXbK8jPK7VW26jfcxiY3mhLdmC0+I2tFPtpv3KayuudoQ2fYOJSpYTORPazFjye+KKWaAyz9zerLpoiPZM1gAqf1hmgCqeZc7HlVIWaaQc+m+nKrCY9SOAy9iGV3BJjWe/n5ztyXByhwbzhUNUK8rZ8LJ/Tb+Jo8cDoOqGSYyfCr2pK07IrUh8UeLMfVv3X9DtTyUBLyQDQF6g27IHXY9vxvPX1mM2QGzlBUk157GaxlDBtouJexJCEMMh8kxoRIIz1rF4B/Ek/ipRxMdUTcW396HlFYpeiLP6JrYyr+DDhclSu0XAJvCuoQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 72bb1441-85de-4ae1-8ada-08d77d8b9648
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 16:11:16.9448 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZWmElGz6PCDiHsNooUE9uc0vmuOjoKzjEULB2fJopb2F7MnMJJswpX1OA3684wP9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3466
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/59W0r7qUATzenZ5HGqxlNccSAtI>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 16:11:23 -0000

Hi:

Is (8):

	(8) Consider returning an address from the range defined in RFC7335 for IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-only hosts (those with a CLAT for example).

	====
	   The result is that 192.0.0.0/29 may be used in any system
	   that requires IPv4 addresses for backward compatibility with IPv4
	   communications in an IPv6-only network but does not emit IPv4 packets
	   "on the wire".
	====

But RFC7335 says (in section 4):

   IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333],
   which is dedicated for DS-Lite.  As defined in [RFC6333], this subnet
   is only present between the B4 and the Address Family Transition
   Router (AFTR) and never emits packets from this prefix "on the wire".  <---
   464XLAT has the same need for a non-routed IPv4 prefix, and this same
   need may be common for other similar solutions.  It is most prudent
   and effective to generalize 192.0.0.0/29 for the use of supporting
   IPv4 interfaces in IPv6 transition technologies rather than reserving
   a prefix for every possible solution.

So, this address is only used "on the host" (not on the wire), so why would there be any need for the DHCP server to assign this address?

And as the IPv6-only option means that the host never completes the DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be used to assign any address.

- Bernie

-----Original Message-----
From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, December 10, 2019 5:32 AM
To: Jen Linkova <furry13@gmail.com>; dhcwg@ietf.org
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Hi Jen,

Thank you for sharing this updated version. Below some points that I do think need more clarification in the I-D: 

(1) The document is too NAT64 centric. The proposal may apply as well for other IPv6-only deployment scenarios (typically, unmanaged IPv6-only CPEs with IPv4aaS).

(2) A discussion on the benefit of this extra signal compared to relying on existing signals (pref64, aftr_name, map_container...). For example, a host that supports the option is ready to wait at minimum 300s and disable its IPv4 configuration regardless of what is happening on the IPv6 leg. How is that superior to a host delaying DHCP process by xxx ms should be explained further.  

(3) How "IPv6-only preferred" mode is supposed to be set at the host side:

==
   A DHCP client SHOULD allow a device administrator to configure
   IPv6-only preferred mode either for a specific interface (to indicate
   that the device is IPv6-only capable if connected to a NAT64 network
   via that interface) or for all interfaces.  
==

* I guess the default value when the option is supported by a host is to disable including it in the request. The document should include a discussion on the default behavior. 
* If an explicit action is needed from the user to enable including the option, having a discussion to what extent the feature is likely to be enabled would be needed.

(4) The document is still mixing the DHCP client vs. host behaviors. For example, 

   Clients not capable of operating in an IPv6-only NAT64 environment
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   MUST NOT include the IPv6-only Preferred option in the Parameter
   Request List of any DHCP packets and MUST ignore that option in
   packets received from DHCP servers.

does not make sense for a DHCP client. 

Also, how the host is able to assess/determine that it is (not) capable to behave in the IPv6 mode? 

(5) The definition of IPv4aaS is not aligned with other RFCs: e.g., RFC8585 says the following: 

   "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition
   technologies for delivering IPv4 in IPv6-only connectivity.

While yours is: 

   IPv4-as-a-Service: a deployment scenario when end hosts are expected
   to operate in IPv6-only mode by default and IPv4 addresses can be
   assigned to some hosts if those hosts explicitly opt-in to receiving
   IPv4 addresses.

(6) Do you consider a host with CLAT function as an IPv6-only host?

If so, the following definition should be updated to refer to "IPv4 connectivity" rather than "IPv4" in general. This is because an IPv4 address is required for CLAT for example.

==
   IPv6-only capable host: a host which does not require IPv4 and can
   operate on IPv6-only networks.
==

(7) Wouldn't the following add an extra delay for applications requiring CLAT?

==
The host MAY disable IPv4 stack
   completely for V6ONLY_WAIT seconds or until the network disconnection
   event happens.
==

(8) Consider returning an address from the range defined in RFC7335 for IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-only hosts (those with a CLAT for example).

====
   The result is that 192.0.0.0/29 may be used in any system
   that requires IPv4 addresses for backward compatibility with IPv4
   communications in an IPv6-only network but does not emit IPv4 packets
   "on the wire".
====

Cheers,
Med

> -----Message d'origine-----
> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova 
> Envoyé : mardi 10 décembre 2019 01:02 À : dhcwg@ietf.org Cc : V6 Ops 
> List Objet : [dhcwg] Fwd: New Version Notification for 
> draft-link-dhc-v6only- 01.txt
> 
> Hello,
> 
> Thanks to everyone for very productive centi-thread on
> draft-link-dhc-v6only-00 ;)
> Here is the improved version, -01.
> 
> The main changes:
> 
> - The option is not zero length anymore. It has 4-bytes value which 
> might contain V6ONLY_WAIT timer. Benefits:
>     --- allows the network administrators to pilot the changes and 
> rollback quickly if needed;
>     --- addressed some concern about an option having zero length 
> (allegedly it might confuse some clients)
> 
> - Using a dedicated address to return to clients is now an optional 
> optimisation. By default the server is expected just to return a 
> random address (as usual).
> 
> - Typos fixed (probably some new typos added though).
> 
> The authors would like the DHC WG to consider adopting this document.
> 
> Thank you!
> 
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Tue, Dec 10, 2019 at 10:44 AM
> Subject: New Version Notification for draft-link-dhc-v6only-01.txt
> To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Lorenzo Colitti 
> <lorenzo@google.com>, Jen Linkova <furry@google.com>, Michael C.
> Richardson <mcr+ietf@sandelman.ca>
> 
> 
> 
> A new version of I-D, draft-link-dhc-v6only-01.txt has been 
> successfully submitted by Jen Linkova and posted to the IETF 
> repository.
> 
> Name:           draft-link-dhc-v6only
> Revision:       01
> Title:          IPv6-Only-Preferred Option for DHCP
> Document date:  2019-12-09
> Group:          Individual Submission
> Pages:          10
> URL:
> https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
> Htmlized:       https://tools.ietf.org/html/draft-link-dhc-v6only-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-link-dhc-v6only-01
> 
> Abstract:
>    This document specifies a DHCP option to indicate that a host
>    supports an IPv6-only mode and willing to forgo obtaining an IPv4
>    address if the network provides IPv6 connectivity.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg