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

Lorenzo Colitti <> Tue, 23 June 2020 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 299153A0E2F for <>; Tue, 23 Jun 2020 08:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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 gVL1Je0ll0jF for <>; Tue, 23 Jun 2020 08:12:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FC813A0E10 for <>; Tue, 23 Jun 2020 08:12:21 -0700 (PDT)
Received: by with SMTP id a12so10407458ion.13 for <>; Tue, 23 Jun 2020 08:12:21 -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=ge+39vFjVSWLXX2Anxw9tNR9Mll/t/Sx7ArhFDa1ydQ=; b=tk8Xgp9/N9M6lWGo7LPTwfgtS+VPlTMYMDTiHSwgJEHuAVMc5mIhfzNfmJDC84wp6H 1dcOdbQCwnE1qnQuN51JqF7b9+kKIK2+yYq+77evphW0DCzIkyeaVzr+aapM5utya1DT kfT0kcZye+F13Tk+ayK2tXQC4of3Ox1u3iNW62ldtkIbfNzWljQ7K5WG7bR6LrYrFyj5 8KWLbo4mbgUvBYqLNgJ/HhKzsDoE5S2gQlPvOtsUIbxb0rV5dk9qBxA3EZ9DZ5hsTK/w QalxPGZaNzkpZaQl+Fy+ocYZdOoXmLnFxd10eB6Kt/F8jmTI0pMUbnmFh4BpbhYla4Y+ eDNw==
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=ge+39vFjVSWLXX2Anxw9tNR9Mll/t/Sx7ArhFDa1ydQ=; b=S6JwVajXCXD0kqOWSA3n4bG3kcv5/OBGCEQ1+N1Mfr/JWSqJ7A8WbkMm6l8DT8/bdR 3FirjYTzj4cMlyBBytpaMnZldV8xF4g5nz1DcSJkfx/EnWLF16fcbRqbt4aBQIeeyjlQ mZYeCabv2ZG/ZZUzs+FVODCUMbT1A1xZm+i5ec8XaRrl1LyTYAYv7liAQNJxHAfPgGhq yXH0WX49GSms6UyNXklNaBon6VjcQ6pXsZFgINsoGF8JMFbMVTANimsXuiZfLpAn5CSG HQv9YQRRNRbxVcBE86WbLChabIjGPlpTrKwf4eLaQh2ViztzWlK8Zqm5ltJ4mHV0tdt/ EyUQ==
X-Gm-Message-State: AOAM532TNG2yrQ2S0pHl7WCN+kGSDh7tE22IU8kCXFt84u4Z6ucao3Y+ aMEdIq0ZCWHilqYEkdeYQthhiQ7/U4maOAcQRd/Ebg==
X-Google-Smtp-Source: ABdhPJymVRVm0hhSG/MfTo/ZYKl6pltJlQ5blMlgYNFRRhOJncLTCfxxvrsqFjEee1R2BL4H/HFXA0zuAJalrbxXRxs=
X-Received: by 2002:a02:b006:: with SMTP id p6mr23743098jah.45.1592925140415; Tue, 23 Jun 2020 08:12:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lorenzo Colitti <>
Date: Wed, 24 Jun 2020 00:12:08 +0900
Message-ID: <>
To: Pascal Thubert <>
Content-Type: multipart/alternative; boundary="0000000000002670ba05a8c1c94c"
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: Tue, 23 Jun 2020 15:12:24 -0000

On Tue, Jun 23, 2020 at 6:55 PM Pascal Thubert via Datatracker <> wrote:

>    However it seems unlikely that any new transition technology would
>    arise and be widely adopted in any foreseeable future.  Therefore
>    adding support for non-existing technologies seems to be suboptimal
>    and the proposed mechanism implies that NAT64 is used to facilitate
>    connectivity between IPv6 and IPv4.
>    "
>    I have a hard time with that one. Adding a byte or 2 of flags in the
>    IPv6-Only Preferred option to indicate that the network supports NAT64
>    and having the host request the address if it needs the service and
> it's not
>    there does not seem to cost a lot and protects the future.

We (the authors) did discuss this at some length and we opted for the
current behaviour for reasons of simplicity. Here are a few reasons why:

   1. Typically, DHCP clients do not often provide information to the DHCP
   server in options (except perhaps the vendor class identifier). Mostly, the
   client puts options in the PRL, and the server includes (or not) the
   options that were requested. So, using only one option the client cannot
   easily indicate to the server "I support transition mechanisms A, B, and
   D". The server would have to return a bitmap of all the transition
   technologies that the network supports. The client would then have to check
   whether it supported one of those technologies, and if it did not support
   any, would proceed with a DHCPREQUEST as normal. This means that the server
   must consider the case where the client asked for the IPv6-only option but
   then proceed to request IPv4. This complicates server implementation
   compared to the current draft, where the server can simply respond with and the client MUST NOT request it.
   2. A bitmask of transition mechanisms would require defining a new
   registry, a process for creation of new options, etc.
   3. A bitmask of transition mechanisms would not be sufficient if the
   network operator wished to place the transition mechanisms in some priority
   order ("use NAT64 if you support it, otherwise use 4rd and otherwise
   MAP-T"). This would then have to become a list of options.

That complexity is a downside of supporting multiple transition mechanisms.
And the upside is limited. We do feel that the likelihood of another
transition technology becoming widely used by end hosts is low, because
NAT64 is already so widely deployed and so easy to implement in hosts. (In
fact, if the host doesn't care about IPv4 literals or IPv4-only apps, the
work required to implement NAT64 is actually zero.) Additionally, if a new
transition technology does end up being widely supported by hosts, it's
always possible to define a new DHCP option code for it.

So we felt that it was best to keep this option simple. IIRC (but other
authors and chairs, please correct me if I'm wrong) there was not much
discussion in the WG that this should be changed, so I think the WG was
pretty happy with the current semantics.