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

Michael Richardson <mcr@sandelman.ca> Wed, 24 June 2020 03:29 UTC

Return-Path: <mcr@sandelman.ca>
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 C0D733A0766; Tue, 23 Jun 2020 20:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8qflOrad6OsO; Tue, 23 Jun 2020 20:29:18 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D33C3A0764; Tue, 23 Jun 2020 20:29:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D678D389D6; Tue, 23 Jun 2020 23:26:35 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YuKW0CPVeATG; Tue, 23 Jun 2020 23:26:35 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3608E389D4; Tue, 23 Jun 2020 23:26:35 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 26849486; Tue, 23 Jun 2020 23:29:16 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Lorenzo Colitti <lorenzo@google.com>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, "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>
In-Reply-To: <CAKD1Yr0cExR2hNcFPG1jf2_m+owcj36PjBo5K2AfkbQbbBu4bQ@mail.gmail.com>
References: <159290613429.20258.90107321879676135@ietfa.amsl.com> <CAKD1Yr0m637ft_H43r8kw3868X51OcUE+gUZPQ7OvgEbosL8VQ@mail.gmail.com> <MN2PR11MB356540C90067D188E624CA3FD8940@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr0cExR2hNcFPG1jf2_m+owcj36PjBo5K2AfkbQbbBu4bQ@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 23 Jun 2020 23:29:16 -0400
Message-ID: <20606.1592969356@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/PQ14yM_POkdk6j466LXkZ4ObnlA>
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: Wed, 24 Jun 2020 03:29:21 -0000

Lorenzo Colitti <lorenzo@google.com> wrote:
    > As for putting NAT64 in the name of the option, I'm not sure that's
    > particularly useful. The only case in which this would make a difference is
    > if a new transition technology becomes widely deployed - otherwise it
    > doesn't matter what the name is. If the new technology is mostly
    > transparent to hosts just like NAT64 is, then we would want to continue to
    > use the same option. If we put NAT64 in the name of the option we might not
    > be able to do that easily. So that argues against making the option more
    > "NAT64 specific" than it already is.

I strongly agree with you -- putting the name in does not particularly help,
I think.

I am less convinced that having the name would harm us in the end, if we
picked it carefully, but I have a hard time finding that name.

The key point of the option is that host does not need IPv4.
I agree with some commenters that it isn't obvious that it implies that NAT64
is available.  But, we have other signals for that, I think.

NAT64 puts *no* requirements on the hosts (except that they be willing to
succeed network attachment without IPv4).
I can imagine some other v6-over-v4 mechanism (inspired by 6to4, or Teredo perhaps) could
perhaps be introduced which did not involve the network creating state.
But in that case, it would also be transparent to the end host, as you say.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [