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

Jen Linkova <> Mon, 29 June 2020 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 141743A1022; Sun, 28 Jun 2020 18:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9fM440Sx6jvI; Sun, 28 Jun 2020 18:38:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2F8A3A101F; Sun, 28 Jun 2020 18:38:54 -0700 (PDT)
Received: by with SMTP id q22so5228850qtl.2; Sun, 28 Jun 2020 18:38:54 -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=jGHRKuLHMSIeEdPt5fJSaLRsRk73836UTVP3/UzTZ2k=; b=Aih15h6UMrBNZDUkecbW01JyaT6XAUlECNiYcK5x2ZUTLuB+aQlhFU+GGQJ3w5ANqx 2A+J9OnfMURaRIPO/6YA385Wm3Jf9lwecjFfKYkKxssg7PSr8ujXjdh4kQDd1gg4IUIA zEyDcEXfvIvTqCETnYHpntvfefHGVSFyMYoA6buHDjxIRTzshpZWc1tC16eVzwbO/4cx srqgbuvdHuuEzheAKoXbXymxbyZrpxc0CoublMTq8rI1cOWHBvDFBdUAY9qo86hsDQJc xMO7ZP6mFo2z1M4Keu/rxN3u9KcRsfDNd04VtWiTVrnBqB4O4V4g9TH/13eEyNh6xNNM mX0g==
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=jGHRKuLHMSIeEdPt5fJSaLRsRk73836UTVP3/UzTZ2k=; b=LqMhGhcaWQ7fyeb8zxVlyU5bHNMSvYRUlWBAA82IdVy2Zkw6lUyVv8Z6VXKQQJNXNb Yboh8l1Gb4rGc3aXbE92dFlzIj+nSPp+99oJHyvZIDUelLWDW3Cblxo3wjEJGF00x2Mk 3eZjTwM1upT24MMQvCemcStDSAasqswAE4ZdBmTzFZO52dyKaTEvdsob9/hkrZTUGubb liJq1TREvmhUj2R6bg7kWrc/IC7xTjBJ8W7ABw4q8314tkeNTpk8KSFBY8paXnosw/eH UzMxENl34Zs4/F/pAn0O8Qrvg9uTuPwFjH2t2VDVV/oWDA16p+GEp6fTAhqOf3YrXPyc AFhA==
X-Gm-Message-State: AOAM530ijKOIg3RlYw8lRNWLhBoKG1fuGr0zQJtKQELJYLNAu5v8I6YF 8kVij347UFtbp1gqyJKos2s+FqssVlRGKZROHkVr6A==
X-Google-Smtp-Source: ABdhPJwn4Hx3/RRXZXuyTpNSllX/2MZc38W+Zl88Tzo5dYooV1H2d8DT5ZxYsiJkfSpBz3r5tMwpi7NCgWi6/Bha6Ek=
X-Received: by 2002:aed:3081:: with SMTP id 1mr13982862qtf.118.1593394731880; Sun, 28 Jun 2020 18:38:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <20606.1592969356@localhost> <> <> <> <> <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Mon, 29 Jun 2020 11:38:40 +1000
Message-ID: <>
To: Philip Homburg <>
Cc: Lorenzo Colitti <>, "" <>, "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 29 Jun 2020 01:38:58 -0000

On Fri, Jun 26, 2020 at 9:53 PM Philip Homburg
<> wrote:
> >> Of course, any host can avoid that by running 464xlat. Which just comes at
> >> the cost of hard to diagnose network problems. Of course this proposal makes
> >> it even worse by running native IPv4 next to pure NAT64 and 464xlat (and of
> >> course native IPv6 as well), making it extra hard for any operator to figure
> >> out what is going on.
> >
> >I'm not sure how this proposal is different from having two VLANs -
> >one is dual-stack and one is IPv6-only. The only difference is that
> >all hosts belong to one IPv6 subnet.
> The difference is that you know what you can expect. On a dual stack vlan you
> have completely standard native IPv4 behavior.
> On a NAT64 vlan you know you can expect a lot of weirdness that is hard to
> debug, but atleast you don't have native IPv4 also included in the mix.

I'm comparing two troubleshooting flowcharts, one for "a dual-stack
vlan + NAT64 vlan", another one is for "a single vlan, the host
behaviour is controlled by the host setting the DHCPv4 option".
In both cases the logic is:
- check if the host  is IPv6-only or not;
- check if the host is supposed to be IPv6-only or not (either by
checking what network segment the host is attached or by checking the
DHCPv4 client option config);
- check if making host a dual-stack solves the issue (either by moving
the host to a dual-stack segment or by changing DHCPv4 client config)
- if the issue is IPV6-only related  - troubleshoot.
I really do not see how/why it matters if I have two segments or one
(ex. having one segment is much easier actually - we eliminate a
randomness of 'what SSID was that device connected when the issue

> >Actually you can say exactly the same about any dual-stack network.
> >It's hard to troubleshoot because sometimes the device is using IPv4,
> >sometimes it's using IPv6...
> Which is an unfortunate side-effect of the current state. However, on a dual
> stack lan, there is exactly one way to do IPv4 and one way to do IPv6. There is
> not traffic that is actually IPv4 translated to IPv6.

Unless I provide hosts with DNS64 on a dual-stack LAN ;-P

> On dual stack, an DNS A query is just that, same for AAAA. On NAT64 with DNS64
> as is strongly suggested by people in the discussion, AAAA can return a
> translated address, or is can avoid doing that if a DNSSEC validating resolver
> asked. A host that uses 464xlat can send A queries and use them. A host without
> 464xlat may still send A queries and fail, for whatever reason.
> What if a host receives a broken (according to IPv6 specs) error ICMP and
> ignores it? Howmany network engineers would correctly diagnose such an issue?

If an engineer is not willing to diagnose such a complex issue they
are welcome to configure their DHCP servers so they do not respond
with the option.
Problem solved.

> >Are you suggesting we move to run IPv4-only hosts and 464xlat on the
> >first-hop routers?
> I'm saying that the only sensible way to deploy NAT64 is to do 464xlat on the
> first hop router.
> >Unfortunately there are networks where this would not work.
> I'm not saying that NAT64 should be deployed at all. So if NAT64 doesn't work
> for a network, then use one of many other ways of providing IPv4, including
> just providing dual stack.

I do not think many people deploy NAT64 just for sake of deploying NAT64.
All cases I know about are driven not by strong affection for NAT64
technology but by the need of migrating to IPv6-only hosts, because
dual-stack hosts are not an option anymore.

SY, Jen Linkova aka Furry