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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 29 June 2020 16:17 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 D1D453A078C; Mon, 29 Jun 2020 09:17:07 -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=BnpvgKvc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EjOP7Egi
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 L2mLxjw00Ggg; Mon, 29 Jun 2020 09:17:05 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D3A3A078A; Mon, 29 Jun 2020 09:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26064; q=dns/txt; s=iport; t=1593447425; x=1594657025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ptFEucJqYr9Z9DUdKNEUnYArLh8BUNMDyoQYSHYucR4=; b=BnpvgKvcftJ2ItYoam4S2O3TQDIWSb5AOytBEsKLtqPRGfQBq8czaSYt JvG3nwW7No02d2nOlokcLhQws4Q7RNax/oWAkM9uVb5a5ULjB1tQ1oVwG k+EPN7zVKqfOvzLOa9DWLGk6bMppJeC02MRBPMgYdi8XLqS5IrDUGiFEP w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AYSq+ExcAWpzbG1g6sMrP3B26lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9fU7PVLj+eQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLVpXK24HgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABYE/pe/5tdJa1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBgXkCAQEBAQsBgSIvUQdvWC8sCoQng0YDjUu?= =?us-ascii?q?KAYlthGuCUgNVCwEBAQwBAS0CBAEBhEcCF4ITAiQ3Bg4CAwEBCwEBBQEBAQI?= =?us-ascii?q?BBgRthVsMhW4BAQEBAxIRChMBATcBCwICAgEIEQQBAQEnAwICAhkGERQJCAI?= =?us-ascii?q?EDgUIEweDBYF+TQMuAQOiBgKBOYhhdoEygwEBAQWFJA0Lgg4JBYEzAYJmgkx?= =?us-ascii?q?Ghm0agUE/gRFDgk0+ghqBWyAQGjSCYDOCLYsMhBsqgiYBPIZBJpsUTQqCXJN?= =?us-ascii?q?nZwSFCoJznCGTMosNjUWEHwIEAgQFAg4BAQWBaSM2gSBwFYMkUBcCDY4dg3G?= =?us-ascii?q?KVnQ3AgYBBwEBAwl8jUEQF4ENATBgAQE?=
X-IronPort-AV: E=Sophos;i="5.75,295,1589241600"; d="scan'208,217";a="504618858"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jun 2020 16:17:03 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05TGH1K6017457 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Jun 2020 16:17:03 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 11:17:01 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 12:17:00 -0400
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.1497.2 via Frontend Transport; Mon, 29 Jun 2020 11:17:00 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=neCmvNDjJLtxalMOzj+1cm7wc7EZa7i8OmxzKAT7SAtzx00k/hy8g9zOtOxgvRMQQPebeYopD32F6KyyekBt1UdMkvaGmLRi7fwrfpe/Jtc6vlCVzjSthfMhKjyvC+1Dycfu9s2LIc1UO00kTbEP4P4jSerqiOqAnJhMQ0FE8UcZgPOC3HyKrZnMeCHGVKZxlT05ryC4VAoPzfXAf0HJeqRiGHf0ZpBt0UpOn1/nkQ9eKrgPWbgvufMLZ5g/RhKiNwbWMLJodJ3T0OPNNLn9zauelrxd8W/n2VWfqI7+Foh8JofDCmeAJIVwQfehAY21+0kj63SMg2HFTd0Rjhhq1w==
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=ptFEucJqYr9Z9DUdKNEUnYArLh8BUNMDyoQYSHYucR4=; b=VMSbDENsdDj/6Fs894jH68aLoayeGpV0TpRSy+t/zmR9PCzC4tQAiqA97nrUBZi4M12bI9AqxVQSg9CPmlhKluwxKwrq0WedhLdV9K3WPxH1dPFsgov10G0NnYVq5SD+vWyt9DVcy+NYvPtwx7pp26R4Md2ANTnQqpkpWxxKwMLBR/SpKR4X2JHGoXpIw0N8nb+asMZhejFiuBKZm+xtEsMUNK35XKsYXobHblcShbv3AqMAIzV/iP1HULJKzOLe12X6lowNUYxZeoK7Tl5mAb4arFF2WB5FoWqo74SuDEj/4AXCX5D8eXJx3poV1PisZeYpYYxCwFroCV3h+toW6g==
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=ptFEucJqYr9Z9DUdKNEUnYArLh8BUNMDyoQYSHYucR4=; b=EjOP7EgilTpHUmFzJTe0Mh4zXGpm4BfEjZdiW/Wt4GvD+9xBI4cn6rBQKgq9MIxFkuEGbxjMwOVOxHUeKk79/5PfmBe1PhfdaUpvQ2I957tIgfe07DX2HIOYIHJwI5G9PEJu4CuCeZRQFOKb3P+pWId2VA+RR0L3ghEytqEtGxI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3712.namprd11.prod.outlook.com (2603:10b6:208:f6::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Mon, 29 Jun 2020 16:16:57 +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.3131.026; Mon, 29 Jun 2020 16:16:57 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: Jen Linkova <furry13@gmail.com>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "draft-ietf-dhc-v6only.all@ietf.org" <draft-ietf-dhc-v6only.all@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03
Thread-Index: AQHWSb1F6Hmu6PPnmE23mP0vaw3Yv6jnYrAwgAhlFwCAAALQkA==
Date: Mon, 29 Jun 2020 16:16:36 +0000
Deferred-Delivery: Mon, 29 Jun 2020 16:15:59 +0000
Message-ID: <MN2PR11MB3565665B1A7065BCF3117B65D86E0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <159290613429.20258.90107321879676135@ietfa.amsl.com> <CAFU7BAQ9XPkM0Rymn4ATqCDf0eVyvNr0SOBS4s4JbgMeg=4MHA@mail.gmail.com> <MN2PR11MB3565BBD67491654DD816F55FD8950@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr1DCgjmxVCPeR7JH-7fdBVQrfOqPdd9qC=47tVfUdFJJA@mail.gmail.com>
In-Reply-To: <CAKD1Yr1DCgjmxVCPeR7JH-7fdBVQrfOqPdd9qC=47tVfUdFJJA@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: [90.118.155.232]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93764c6c-c34a-4e10-3f4e-08d81c47d8d4
x-ms-traffictypediagnostic: MN2PR11MB3712:
x-microsoft-antispam-prvs: <MN2PR11MB37127F4680F6EAA8C7109484D86E0@MN2PR11MB3712.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 044968D9E1
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Xy8MVSrE9wxtQRuIIrfbj7MS0X9/6GAk+CKZUAbSPH0gFt6J0L6g9za6PeW0r7OnZVOIP0Ub494A7Z3ucsj9WBWWVCYsGuMeZ8pABrOjUfwMzWnlwIYdu5b76thD27Okjy5C2j2BuzwAw1i/L+0nEGaShJkaWN7b3tHBV9fuw5yxLACLrEOFHCDxNehKvINxETQkowNdfbFA3gjyN0lcvhQuN/Ifhp/UfG1d0o+75i0mEDFqLCjYJwdBO64hp9bD1vWxJJk+/vBeKbNzP8Aq7CaWt6ucqSUrvzcpeZFllNwi+C3ueJdaWepaB33omaU/yoK8GT8WNOOMlJhvdsInZA==
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)(366004)(376002)(346002)(39860400002)(396003)(8676002)(478600001)(6916009)(66446008)(64756008)(66556008)(66476007)(76116006)(66946007)(83380400001)(9686003)(33656002)(6506007)(53546011)(8936002)(55016002)(7696005)(186003)(4326008)(2906002)(6666004)(71200400001)(316002)(26005)(54906003)(5660300002)(86362001)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Pj6yS1mNbqdHYmeBVxfEk+J8F43+LBqUwx6fEGkYDJ/YZIYmbGqhj1RWNUL5bUhri9w2so0KW7tuPMBzk4JP5MyCe7KhagS++d8MfZREcH1dji/8J7d2ArYi1sSv03NDXcyr+vskkVQ9mq7CNQvdvmE3woAHQyDVzggFq3joLVYYyWN1ArogFMYXwwqnEkMI13Lflo9p8mhBRHk+e3GYMg/nbQT0bFrIJTqrP402DHuGE4IAgk8Rqo0/UvqhYGJqISsmtI1A+1IHWdTdblO6t0YK8IDyGojKM3S1ZvxiZunX4u8Ow1HO9MWjHBDHwNA4maeQI+UvsJmUoEzpY0jeawvw4a3rlSXcQ25dGySlZTrhl1kzRQGRJkU5JVhCt+bBOdeNKP5kFKh7/IF5d+Ia4mW14UlfcVqiKcabof5pWQZN0UxhL5llUnehZ8dg0K4rwoK6AURq3nJNIx9S5MBVg7yH+rmAqY5yVCvxMN+Jyn4iWaAseGJYVfe4ScoZeuDp
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565665B1A7065BCF3117B65D86E0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93764c6c-c34a-4e10-3f4e-08d81c47d8d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 16:16:57.7999 (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: odZBTUrv5Mnps4SHzstOYIqD8ldx132A8f+iCRitCDmTrU0XLy3Rww6sA25rb7LSIJYSWuvjVXoKnYwDtqhKrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3712
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/6oy1r3voU-XZbACQ9YHWwG9dgwE>
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: Mon, 29 Jun 2020 16:17:08 -0000

Sure it would, Lorenzo.

As you point out, NAT64 is a wide enough scope to justify the introduction of option. So if you drink from that cup, we’re all set.
My initial suggestion was along those lines, naming the option based on its scope of applicability, the scope being a network that does NAT64.

The alternative to define transparent etc… was in the case you wished to allow the option in a context that is not NAT64 and not known by a legacy stack that uses the option. In that case you effectively enter the complex game of describing what works and what works not and limit the DHCP server sending the option in the what works case. I agree that’s more complex than useful for the foreseeable future.  I figured you wanted that at some point when you and Michael reacted against placing NAT64 in the name of the option.

Take care,

Pascal



From: Lorenzo Colitti <lorenzo@google.com>
Sent: lundi 29 juin 2020 17:55
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Jen Linkova <furry13@gmail.com>om>; iot-directorate@ietf.org; draft-ietf-dhc-v6only.all@ietf.org; dhcwg@ietf.org; last-call@ietf.org
Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03

So, to come back to the original reason for this thread: after thinking about Pascal's suggestion, I'm not sure that we can come up with a definition of "transparent" that we can confidently state will match as-yet-undefined transition mechanisms for which this option would be appropriate.

The first part of Pascal's definition ("accessing IPv4 services via a fully transparent mapping system such as NAT64") seems easy to understand/define. But the implementation of the second part ("translating or tunneling IPv4 traffic to traverse the v6-only network such as 464XLAT") is, if you think about it, actually very specific to NAT64 and 464xlat. If we introduce a new 4underover6 transition mechanism that is transparent, but is not compatible with implementations that do IPv4 using 464xlat, then is the option appropriate or not? I don't think it's easy to make that determination today because we don't know how 4underover6 works. But when we do define 4overunder6, and know how it works, it will be easy to decide whether this option is appropriate. And in fact, 4underover6 might even be intentionally designed to work well with this option. At that time, it will be easy to update this RFC saying whether networks that use 4underover6 can use the option and under which circumstances.

So I think I would still prefer to leave this option as being NAT64-specific. And I really don't think there's much of a downside, because, well... YAGNI. I really don't see another transition technology becoming widely deployed at this point, given that NAT64 is already basically free for hosts to implement.

We could update the document to say that NAT64 is widely deployed, and at the present time, the wide deployment in hosts of a new transition technology seems very unlikely given that on IPv6-only networks IPv4 is a legacy service, and given that NAT64 already provides good compatibility with little to no implementation required on the host. We could say that if this is not the case, then a new DHCP option may need to be defined for that new transition mechanism, unless that new transition mechanism is such that legacy hosts that only implement NAT64 and 464xlat can use it.

Pascal, would that work for you?

On Wed, Jun 24, 2020 at 4:57 PM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
Hello Jen

That's great. I realize that I'm asking you to state the perfectly obvious for someone who designs a phone in 2020.
Still that context scopes the applicability of the draft, which is a lot more than that.

Ideally that definition would indicate that the IPv6 only mode may include:
1) accessing IPv4 services via a fully transparent mapping system such as NAT64
2) translating or tunneling IPv4 traffic to traverse the v6-only network such as 464XLAT

This way we can say later in the spec that
-if the transition mechanism is not fully transparent to the host then the server MUST NOT place the option,
- the mechanism is compatible with solutions based on NAT64, DNA64 and XLAT, and also any other fully transparent mechanism.

The goal is to be prepared for that future where another mechanism becomes prevalent that requires host attention.

Take care,

Pascal


> -----Original Message-----
> From: Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>>
> Sent: mercredi 24 juin 2020 02:20
> To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
> Cc: iot-directorate@ietf.org<mailto:iot-directorate@ietf.org>; draft-ietf-dhc-v6only.all@ietf.org<mailto:draft-ietf-dhc-v6only.all@ietf.org>;
> dhcwg@ietf.org<mailto:dhcwg@ietf.org>; last-call@ietf.org<mailto:last-call@ietf.org>
> Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03
>
> Hi Pascal,
>
> Thank you for reviewing the document.
> I believe Lorenzo explained why the draft supports NAT64 only.
>
> Re: the terminology comment:
> On Tue, Jun 23, 2020 at 7:55 PM Pascal Thubert via Datatracker
> <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
> >    "
> >                                              ... IPv6-only mode (either
> >    because the OS and all applications are IPv6-only capable or because
> >    the host has some form of 464XLAT [RFC6877] deployed),
> >    "
> >    Do we have a good reference of what we mean by the v6-only mode of a
> host
> >    - or an interface for that matter ?
> >
> >    Else it would help to define it before we use it. Note, the terminology
> >    defines a "IPv6-only capable host" but not the "mode".
>
> I'll update the Terminology section with the following definition:
> IPv6-only mode as 'a mode of operation when a host acts as IPv6-only capable
> and does not have IPv4 addresses assigned (except for IPv4 link-local
>    address [RFC3927]).
>
> Would it address your comment?
>
> --
> SY, Jen Linkova aka Furry