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

Philip Homburg <> Tue, 23 June 2020 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB6E03A087F; Tue, 23 Jun 2020 10:39:49 -0700 (PDT)
X-Quarantine-ID: <4fBJemKvX0MR>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4fBJemKvX0MR; Tue, 23 Jun 2020 10:39:48 -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 C51B63A085B; Tue, 23 Jun 2020 10:39:47 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jnmtd-0000OoC; Tue, 23 Jun 2020 19:39:45 +0200
Message-Id: <>
Cc: Michael Richardson <>
Cc: "draft-ietf-dhc-v6only.all\" <>, "iot-directorate\" <>, "last-call\" <>, "dhcwg\" <>
From: Philip Homburg <>
References: <> <> <> <> <32056.1592933199@localhost>
In-reply-to: Your message of "Tue, 23 Jun 2020 13:26:39 -0400 ." <32056.1592933199@localhost>
Date: Tue, 23 Jun 2020 19:39:44 +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: Tue, 23 Jun 2020 17:39:50 -0000

>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 ancien
>t protocols).

I don't know if you consider an ancient protocol, but this
is typically something that breaks with NAT64.

However, NAT64 is also a complete violation of core IPv6 standards.
1) RFC 4443 (ICMP6) Section 2.4, (c):
    Every ICMPv6 error message (type < 128) MUST include as much of
    the IPv6 offending (invoking) packet (the packet that caused the
    error) as possible without making the error message packet exceed
    the minimum IPv6 MTU [IPv6].

  There is no way an NAT64 gateway is going to make that work. Worse, RFC 4884
  put funny bits at ofset 128. 

2) IPv4 links can have MTUs lower than 1280. Again this is incompatible with 
   IPv6 specifications.

Then, if you say no host changes required, you imply the use of DNS64, which is
incompatible with a DNSSEC validating resolver on the host (unless that 
resolver is aware of the presence of DNS64).