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

Philip Homburg <> Fri, 26 June 2020 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 669843A1273; Fri, 26 Jun 2020 04:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.622
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PAHMTl69y1lX; Fri, 26 Jun 2020 04:53:39 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id C331D3A127A; Fri, 26 Jun 2020 04:53:37 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jomvC-0000N2C; Fri, 26 Jun 2020 13:53:30 +0200
Message-Id: <>
To: Jen Linkova <>
Cc: Lorenzo Colitti <>, "" <>, "" <>, "" <>, "" <>
From: Philip Homburg <>
References: <> <> <> <> <20606.1592969356@localhost> <> <> <> <>
In-reply-to: Your message of "Thu, 25 Jun 2020 09:14:13 +1000 ." <>
Date: Fri, 26 Jun 2020 13:53:29 +0200
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: Fri, 26 Jun 2020 11:53:41 -0000

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

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

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?

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