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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 23 June 2020 17:26 UTC

Return-Path: <mcr+ietf@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 727623A08FB; Tue, 23 Jun 2020 10:26:45 -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=unavailable 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 RZbQV3rCAA1v; Tue, 23 Jun 2020 10:26:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C08E3A08B0; Tue, 23 Jun 2020 10:26:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8ACC0389AC; Tue, 23 Jun 2020 13:23:59 -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 92yMjGjehPUt; Tue, 23 Jun 2020 13:23:59 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DB18E389A2; Tue, 23 Jun 2020 13:23:58 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A392486; Tue, 23 Jun 2020 13:26:39 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Philip Homburg <pch-ietf-7@u-1.phicoh.com>
cc: "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org>, Lorenzo Colitti <lorenzo@google.com>, "draft-ietf-dhc-v6only.all\@ietf.org" <draft-ietf-dhc-v6only.all@ietf.org>, "iot-directorate\@ietf.org" <iot-directorate@ietf.org>, "last-call\@ietf.org" <last-call@ietf.org>, "dhcwg\@ietf.org" <dhcwg@ietf.org>
In-Reply-To: <m1jnmO9-0000NZC@stereo.hq.phicoh.net>
References: <159290613429.20258.90107321879676135@ietfa.amsl.com> <CAKD1Yr0m637ft_H43r8kw3868X51OcUE+gUZPQ7OvgEbosL8VQ@mail.gmail.com> <MN2PR11MB356540C90067D188E624CA3FD8940@MN2PR11MB3565.namprd11.prod.outlook.com> <m1jnmO9-0000NZC@stereo.hq.phicoh.net>
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 13:26:39 -0400
Message-ID: <32056.1592933199@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/W_yg-j7nLkLQodxtqhzN0iv7TdE>
Subject: Re: [dhcwg] [Last-Call] 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 17:26:57 -0000

Philip Homburg <pch-ietf-7@u-1.phicoh.com> wrote:
    >> 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.

    > Another way to look at it:
    > I consider NAT64-to-hosts a really bad idea. Implementing 464xlat in a CPE
    > or other router is not that bad, but making sure that every host in your
    > network can properly support NAT64 or 464xlat is not something you should
    > want.

Huh? NAT64 can involves no host changes at all (other than not having IPv4 to
succeed in network attachment, and as Lorenzo said, IPv4 literals in some ancient protocols).

    > What if some of your hosts are doing native IPv4 and some NAT64, that makes
    > troubleshooting even worse.

Yes, what if.

You'll know which hosts are doing native IPv4 (native, to me, btw, means
public IPv4. I think you mean NAT44. Some hosts do NAT44 and some do NAT64 to
reach IPv4 addresses)

But, hosts that support being IPv6-only will set the flag, and older hosts
will not.  So over time, all the hosts are IPv6-only.

The alternative is that lots of hosts are dual-stack.

    > In the far future, it is possible that networks will stop supporting IPv4
    > and that some hosts connect to a IPv4 service somewhere in the internet.

    > So, it is likely that any other protocol would go the same route? Is there
    > a benefit for hosts that do not implement NAT64 to set this option?

Mostly, "hosts" do not implement NAT64, they run IPv6 and avoid IPv4.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-