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

Lorenzo Colitti <> Wed, 24 June 2020 01:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D367D3A00AE for <>; Tue, 23 Jun 2020 18:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1V2-sPQFiZT4 for <>; Tue, 23 Jun 2020 18:43:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BF713A0064 for <>; Tue, 23 Jun 2020 18:43:10 -0700 (PDT)
Received: by with SMTP id a12so383052ion.13 for <>; Tue, 23 Jun 2020 18:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nykY6UGsP3oZpphyOdGaBlCXCurvakYU/eH37/z/4rg=; b=XKAzkpox3S3gB858ak5N0gBUP2h9SK9xuIxGXVWVK/Z+zCE7O0vFzPtfjLVaQK4ydr Cm8JcoK0staKmZUnmiAty3VvxKTqMoaxtOq+7uvBhtN+kDHD7eb9GCIXYERQtyTJUqc4 jjz3JRJEgBs8a3lO1Ma1RjJt++k4LzHQthB0YyXb/5iFPTPFRqsnntJqZ156nEOEJItZ EpG2+KRtkWu1W8WJ8Qh9QCwAlVL14RSd+Hc+1p55PeswCZYB6ftWQSP8ZQ5xKbkxqMXg 4VljqoscmGRq6f6i5ZO9Lrdu+TiceVMGeA1MrIy0zH+jhafunZIaLItRT64/GwtG6gMG wOmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nykY6UGsP3oZpphyOdGaBlCXCurvakYU/eH37/z/4rg=; b=YGXWDouMdJUt+dtlT8yWiJmhbYvW3aAz9LszBcfHovvAJrVnLmzhe36eq6Xz4YDGU1 BJs7bCeUfjR+CSxFtdOQfatv6lRB4kljsA1Np7KRBaRvNCVECnPEO2bWYrqHXtw4r35A 3QIGwgJoriNCBQ8c3OfEYS46Qrah3j6YgWu2TnevpdmeFvTsTd76OsOHveD5I1CqwMP6 gLuQm1FJEgS4JPw7cK26SzCd71r0t6IyHVFUp11mpCzLf5ZKp5+cJ7w22FnjLvVohLlx F9iAV5URx7eZeyQ+eywjwfcPtnrvvQJ+r+QhrkLh4pYLriLjh8zFJeXiLqijvPqa5yuO dOAw==
X-Gm-Message-State: AOAM530d/xPCqlfZU/BjAxrUc2GfeSH26UqnN4ke7q+dGS5KIBaD1zxS bLz3kcQuL38cZl6Cc57D7vQ3NFQ+LY2j1VdJGX5N3w==
X-Google-Smtp-Source: ABdhPJwK/ASZ27X0qT+lPR+f9OP0Jv5utkactLK1DBx0VKMZvT5Ws9gUhBpxQvl9VmPWuvYjqo3hOOkqijDS+4v2OHQ=
X-Received: by 2002:a6b:6b03:: with SMTP id g3mr14403023ioc.47.1592962989246; Tue, 23 Jun 2020 18:43:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lorenzo Colitti <>
Date: Wed, 24 Jun 2020 10:42:57 +0900
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000001db58705a8ca991b"
Archived-At: <>
Subject: Re: [dhcwg] 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: Wed, 24 Jun 2020 01:43:13 -0000

On Wed, Jun 24, 2020 at 1:36 AM Pascal Thubert (pthubert) <> 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.

I think the escape strategy here is to define a new DHCPv4 option, yes.

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 think the only case for making the option more "NAT64 specific" is if a
new transition technology becomes widely deployed which is *not*
transparent to hosts (i.e., it requires hosts to do work to support IPv4),
and the technology is successful enough (and enough time has passed) that
all hosts of interest support that option, and no longer support NAT64. In
that case, the option currently being defined in this draft would no longer
be useful.

Like I said, this all seems pretty unlikely to me. In particular it seems
unlikely that a transition technology would become widely deployed if it
requires hosts to do work - there doesn't seem to be much of an incentive
for that to happen given that NAT64 is widely deployed (and thus
deployable) and requires zero work for hosts. Additionally, as IPv6-only
networks become more deployed and IPv4-only apps age out, the incentive to
do that work reduces, and it seems likely that any new transition
technology that is defined will be transparent to hosts because things like
IPv4 literals and IPv6-only apps are a thing of the past.

Further, any new technology that we expect to be used on hosts will need to
consider the impact on legacy NAT64-capable hosts, and there will be an
incentive to make those hosts work. So at that time, we might find a better
migration strategy than to define a new option and we can update this
document with the result.