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

Michael Richardson <> Tue, 23 June 2020 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 727623A08FB; Tue, 23 Jun 2020 10:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RZbQV3rCAA1v; Tue, 23 Jun 2020 10:26:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C08E3A08B0; Tue, 23 Jun 2020 10:26:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8ACC0389AC; Tue, 23 Jun 2020 13:23:59 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id 92yMjGjehPUt; Tue, 23 Jun 2020 13:23:59 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id DB18E389A2; Tue, 23 Jun 2020 13:23:58 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6A392486; Tue, 23 Jun 2020 13:26:39 -0400 (EDT)
From: Michael Richardson <>
To: Philip Homburg <>
cc: "Pascal Thubert \(pthubert\)" <>, Lorenzo Colitti <>, "draft-ietf-dhc-v6only.all\" <>, "iot-directorate\" <>, "last-call\" <>, "dhcwg\" <>
In-Reply-To: <>
References: <> <> <> <>
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: <>
Subject: Re: [dhcwg] [Last-Call] Iotdir last call review of draft-ietf-dhc-v6only-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2020 17:26:57 -0000

Philip Homburg <> 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 <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-