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

Philip Homburg <pch-ietf-7@u-1.phicoh.com> Tue, 23 June 2020 17:07 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 2F4FA3A086A; Tue, 23 Jun 2020 10:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 mSUkCfGjqij6; Tue, 23 Jun 2020 10:07:27 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DCD3A086C; Tue, 23 Jun 2020 10:07:21 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jnmO9-0000NZC; Tue, 23 Jun 2020 19:07:13 +0200
Message-Id: <m1jnmO9-0000NZC@stereo.hq.phicoh.net>
To: "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: 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>
From: Philip Homburg <pch-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <159290613429.20258.90107321879676135@ietfa.amsl.com> <CAKD1Yr0m637ft_H43r8kw3868X51OcUE+gUZPQ7OvgEbosL8VQ@mail.gmail.com> <MN2PR11MB356540C90067D188E624CA3FD8940@MN2PR11MB3565.namprd11.prod.outlook.com>
In-reply-to: Your message of "Tue, 23 Jun 2020 16:36:12 +0000 ." <MN2PR11MB356540C90067D188E624CA3FD8940@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Tue, 23 Jun 2020 19:07:12 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Y9Ncpy_ENQTtGlns6re3DVclLw8>
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:07:28 -0000

>    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.

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

NAT64 looks good from a network management point of view because a large part
of your network can unaware of IPv4. However, with this option all of your 
network needs to provide native IPv4 and you need to deal with NAT64 as well.

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?

In the unlikely case we get there, we can probably allocate a new option.