Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 23 June 2020 16:36 UTC

Return-Path: <pthubert@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 982AC3A0890; Tue, 23 Jun 2020 09:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=DbThpfQM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EWi2LlKl
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 7N65EbAfRg1N; Tue, 23 Jun 2020 09:36:35 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B001C3A0893; Tue, 23 Jun 2020 09:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21368; q=dns/txt; s=iport; t=1592930194; x=1594139794; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mrj0+yJjYzgeG9922lDr/AmYtBS/MzbTnzTUy8u0GlQ=; b=DbThpfQMIbO04X0VQxFKRiNsCi54fXpVL25mTVSWsjBxIQlSzklx09kd HvGASreaM0KI1TZq3tv4YKuRtKv2qvw00miDwnY73bZJ0NzBqIAxg/2Pw uY7JXetuXOHRNheYlKDvoP/zlsBVhSuuDkKTLNMcyAKCcHodB/1HifFpZ Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3ARZxAhBPUWJlBZ44Ts3ol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3lDOWorf5rRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8H5aFnf5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiBQDQLvJe/4sNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoEjLyMGKAdvWC8shCSDRgONRpNthGiCUgNVCwEBAQwBAS0?= =?us-ascii?q?CBAEBhEcCF4F8AiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQEDEhEKEwE?= =?us-ascii?q?BNwEPAgEIEQQBASgDAgICMBQJCAIEDgUIGoMFgX5NAy4BrGACgTmIYXaBMoM?= =?us-ascii?q?BAQEFhSEYgg4JgTiCZ4JMRYZrGoFBP4EQAUOCTT6EFBEaJBCCXjOCLY8hLYJ?= =?us-ascii?q?ehjwmm1IKglqOZ4VdhQeCcYkkgzuPK6tehBwCBAIEBQIOAQEFgWoiNoEgcBU?= =?us-ascii?q?7gmlQFwINiFmFRQwXgQIBB4JEilZ0NwIGAQcBAQMJfI0agkYBAQ?=
X-IronPort-AV: E=Sophos;i="5.75,271,1589241600"; d="scan'208,217";a="778846168"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 16:36:33 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 05NGaXgG006371 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jun 2020 16:36:33 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 11:36:33 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 12:36:31 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 23 Jun 2020 12:36:31 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CcH3URax2G7OGpPm4LiXOmOgCjnINbToZQFmb/xWa6EOD5cAuZjMNQPv0Vdee/m/BzstFp0hl0w7vOM9yXdWrNEXManpbScHEbaT+l4Wt51TG/6sT6vMLE1fxB+S5gzjz6gr/4wH/6GO4LZeGTLJh7n4EcgZNLvxqKP4lxVvOGmXVpkXZ5lpbpvomWMzO0SzQnXJJt/YMCruCZDdybRo/lBV8rr4pZ7Hh9r7s50a8bpCs6cJjsLx+vyEGVmA6bHn5GCZdSyBW7+b6Vz9Kbugc58GmU0+zw49CgofwTD5wTKXQR+SAsd6uRQ9PUDcUgBCYzz5yd7Z+jR3xQAdRa9SAA==
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=Mrj0+yJjYzgeG9922lDr/AmYtBS/MzbTnzTUy8u0GlQ=; b=awuTQCaJrGg49uLLzh0EEoHgmhhwu45jApY8gL4wOyoR9phqwR87ACFyODxq17JR9uDS9N9huX43zawUUwPvKJxmlGCkHr4pNcoL1Wrlpiw8RiP5C4fK447lMOev8y0fdvFJOCDUocR3Bc6m/0wPyi2BliPjW6tgbc2AOr4uyHYXC6niLnxaqp2tAno2QjApleuJU0aNP75JLcL+UZY47p/D/waDecYFjH0ryZmaENq2ZSL5wz+yrnzmEVUuoCF1vupmruu7B0V4GaPzSaEL3BfiRFV6bpkIDpyK1lru5rONIimPNkMCgJhWH1940WQ7tx6cQuzPt9JvUh15ePzRfA==
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=Mrj0+yJjYzgeG9922lDr/AmYtBS/MzbTnzTUy8u0GlQ=; b=EWi2LlKlG4Yfd+Vrqpo1WxVx6J3zk3wEcxC9YLGUPEZ1TmGvHThUFRsR1mjSgT8dFK98Rz+z44Ygsv+bHv6fX+IckhtrRgOcXP617V8yfSRVzT07lPFkCmworrh2iD3sXXWAeivSpTK9nuF/qhjyCwd/9nZZFMCfKPCVTR9XV6Q=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3919.namprd11.prod.outlook.com (2603:10b6:208:13b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Tue, 23 Jun 2020 16:36:31 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108%6]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 16:36:31 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-v6only.all@ietf.org" <draft-ietf-dhc-v6only.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Iotdir last call review of draft-ietf-dhc-v6only-03
Thread-Index: AQHWSXCz500xj5hBFEOHJgQP4qEuFajmYcrQ
Date: Tue, 23 Jun 2020 16:36:12 +0000
Deferred-Delivery: Tue, 23 Jun 2020 16:35:29 +0000
Message-ID: <MN2PR11MB356540C90067D188E624CA3FD8940@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <159290613429.20258.90107321879676135@ietfa.amsl.com> <CAKD1Yr0m637ft_H43r8kw3868X51OcUE+gUZPQ7OvgEbosL8VQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr0m637ft_H43r8kw3868X51OcUE+gUZPQ7OvgEbosL8VQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:28d8:3f75:82a3:e7ff]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b92f6c68-0f8b-45b2-e9b9-08d8179395c3
x-ms-traffictypediagnostic: MN2PR11MB3919:
x-microsoft-antispam-prvs: <MN2PR11MB39197D2C5FB0ECFD4E94DF6CD8940@MN2PR11MB3919.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BTimaXhxk+kDI2BplBZAMWJmcLWohQstFAXBKclSGwWacu1Qn4YdOs1FyOY1h+yglc9ucPe2pzX3GdFIfugHp4i8ioYylz/Ql/g1+HFb4aURBKXy2+iHrhe8vHtR9MsSy0le4iOjEjFxT5ysBzGwDCBsyYU6KILM/kv4uFSPcU2N5ufZqPs+wA67eyEOiX10truyojtJQuYSzFR7l1bMxY+g59NEADhMCSEYk40tfoJEBGGqRv6IDkM9FefKIiXK7VB41HoKD+/0AnOkl5fa4CjGTxKkUX5ytc0rD26+noWNRnGuzNoAoDfoGUweEvcwf8unnUJwVaz1KtSGtWLSxQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(376002)(39860400002)(366004)(396003)(6916009)(71200400001)(83380400001)(6666004)(8936002)(5660300002)(2906002)(6506007)(52536014)(7696005)(55016002)(53546011)(64756008)(66446008)(66476007)(66946007)(478600001)(66556008)(33656002)(316002)(86362001)(76116006)(4326008)(186003)(54906003)(9686003)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Q7TXyHVjRgX3YG3ZkYJGrUUIrZYxzk8AlQGJIB8RSz7MRMP8CsjCpUU6mC4wVb70F52ZJgu3Lg6/l/2+wJxPDFFnnkovphsBnMs8UXvg3RqyA9wISDiVLXaEk7MR5E6vXn7AOSlBm8J0UKzBJef94MLjRfQAuexyGPSJABFQsD24v8QF51QLqglkrSR+U8KYalUfZYMTAmTJd+gSnBeRXu3zmplq1G4fv9geWpA7dxbrOzVBEa+h5S/MXtYa7jeNmv6IDINNns5dyLAk5ZeWaVdCCauNUjoRjgP0csLS3B2OIf8GD9qqhOtHq/6g7gZRmcY/HLQIh/oCf+IGmdxfW53841xJCJkIGnDTsC9rsPSpx6uAmBcm5dHLTBxhrfUGMjNzr6y4+inPCwPlk1AJbVKB049u4KXpU2/RtMJfuqniegE5NyITi4jtEzOUtXohfauWzjBpkPacvmVCEgBI+lAXOwk6J0FTG8AKJct6UiW5Zrr2rdjQ6QU177wqhuXmyGXKviw1MQryfpg5DYxUOy1tEzUozJSh6unluyeL6pDNyxayQlwIzL9tujkaOHxj
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356540C90067D188E624CA3FD8940MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b92f6c68-0f8b-45b2-e9b9-08d8179395c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 16:36:31.1641 (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: qj8dv7oBR8/gVyItlkc3dvJKipXgFg9jHdjf8LLTZH42OfPeM9/ppNKogIyAYOKETgrVjLoIu071oIcnjYxwjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3919
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/jvheuV8ryHEfSBjimdZ6gMpa2ug>
Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03
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, 23 Jun 2020 16:36:38 -0000

Hello Lorenzo:

I agree with 1 2 and 3. 1 and 2 in particular are not overly complex to specify and code, and seem pretty useful. 3 is more complex and more on the nice-to-have side. I would have done one and 2. But hey, the consensus can be otherwise.

I’m concerned because this transition seems to last a lot longer than we thought. It may last 20 more years, or never really end. We may not have seen something coming that will make it so that a node that needs NAT64 may be fooled in a network that has something newer.

Now, if you have an escape strategy for that day like this other option and you can prove there’s no place for backward compatibility problem at that time, then fine with me. Also fine with me is if that draft is only for NAT64, in which case you could even have NAT64 in the name of the option to make things clearer.

If the consensus is to go without any of the above, well, that what consensus is for. I’ll keep fingers crossed…

Take care,

Pascal


From: Lorenzo Colitti <lorenzo@google.com>
Sent: mardi 23 juin 2020 17:12
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: iot-directorate@ietf.org; dhcwg@ietf.org; draft-ietf-dhc-v6only.all@ietf.org; last-call@ietf.org
Subject: Re: Iotdir last call review of draft-ietf-dhc-v6only-03

On Tue, Jun 23, 2020 at 6:55 PM Pascal Thubert via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
   However it seems unlikely that any new transition technology would
   arise and be widely adopted in any foreseeable future.  Therefore
   adding support for non-existing technologies seems to be suboptimal
   and the proposed mechanism implies that NAT64 is used to facilitate
   connectivity between IPv6 and IPv4.
   "

   I have a hard time with that one. Adding a byte or 2 of flags in the
   IPv6-Only Preferred option to indicate that the network supports NAT64
   and having the host request the address if it needs the service and it's not
   there does not seem to cost a lot and protects the future.

We (the authors) did discuss this at some length and we opted for the current behaviour for reasons of simplicity. Here are a few reasons why:

  1.  Typically, DHCP clients do not often provide information to the DHCP server in options (except perhaps the vendor class identifier). Mostly, the client puts options in the PRL, and the server includes (or not) the options that were requested. So, using only one option the client cannot easily indicate to the server "I support transition mechanisms A, B, and D". The server would have to return a bitmap of all the transition technologies that the network supports. The client would then have to check whether it supported one of those technologies, and if it did not support any, would proceed with a DHCPREQUEST as normal. This means that the server must consider the case where the client asked for the IPv6-only option but then proceed to request IPv4. This complicates server implementation compared to the current draft, where the server can simply respond with 0.0.0.0 and the client MUST NOT request it.
  2.  A bitmask of transition mechanisms would require defining a new registry, a process for creation of new options, etc.
  3.  A bitmask of transition mechanisms would not be sufficient if the network operator wished to place the transition mechanisms in some priority order ("use NAT64 if you support it, otherwise use 4rd and otherwise MAP-T"). This would then have to become a list of options.
That complexity is a downside of supporting multiple transition mechanisms. And the upside is limited. We do feel that the likelihood of another transition technology becoming widely used by end hosts is low, because NAT64 is already so widely deployed and so easy to implement in hosts. (In fact, if the host doesn't care about IPv4 literals or IPv4-only apps, the work required to implement NAT64 is actually zero.) Additionally, if a new transition technology does end up being widely supported by hosts, it's always possible to define a new DHCP option code for it.

So we felt that it was best to keep this option simple. IIRC (but other authors and chairs, please correct me if I'm wrong) there was not much discussion in the WG that this should be changed, so I think the WG was pretty happy with the current semantics.

Cheers,
Lorenzo