Re: IPv6 only host NAT64 requirements?

Jen Linkova <> Wed, 15 November 2017 03:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A81E126C22 for <>; Tue, 14 Nov 2017 19:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 w92YoAWJ_5_V for <>; Tue, 14 Nov 2017 19:05:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76B80126B72 for <>; Tue, 14 Nov 2017 19:05:41 -0800 (PST)
Received: by with SMTP id x68so581333lff.0 for <>; Tue, 14 Nov 2017 19:05:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qp8xSLcqMnHPEZbW2XD8HgMYeBtLPdfU2KL2wYvDVoY=; b=V+SE83bSAZ+9Pg7tqSzxK+cmKSWF5+mnS6WIDRVjfabimb6fR8cQAoxyIZwnpfEfDM UHmP7g1qjfKzi+5pJzBr7oxMC8RlGOcH5RW8FjbmWaTe7C2LPuo7n76zy8FSzm8kiIxr U3AZTsTKKDNSkknHQZEvAZ9mUO/rkU2YODbfHaTQKZDYLyydUiA4vTJ7qfeIgSd6D/Uy vz/IK0zpMwQCEuKQPXH5urwG2eOt9N/B6Wz3DmGtVmInkVK6yYxzCHErupMJt3vAVTBK LQJZZcnNDvfEMGbfY+bCD01TBM4esvsqIeBBLBOfDplb5bRWWab9EF1TZZonKHn/r4OD 6WOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qp8xSLcqMnHPEZbW2XD8HgMYeBtLPdfU2KL2wYvDVoY=; b=bN0XsnDOWabAjMm+kXwn9GAfNJ9SDKfUi+MzawXH8NNiI0/0gQ7oS1YQZK79jy6j9S 9LIlzhCyHnggjLlf7S2Ht5pDRBefWAcMbwQ4Ue2EhEBjLxO72xPk0r57kY67grmbJqxx 3kv1YEeQ9LFkk1pP7JhkJ0ovGv7XU0z35UHsIDX+XM/AmZ5Rjwk3a8Z1IBoMWL4dj2YW HVttNVuCqWdCXJ984Ur52AanqrDEQLO5IDkXC5a6O2dTv/J0XlQUi0vvM+bRRF7rDnRo 4xGfGO2Uezw0T3Fuybj7GD2nvmrlBhnYEo4a8luqC/j3lPidhB3pCyTNqw4Nbk8LakmB tWrg==
X-Gm-Message-State: AJaThX4jvpqxq4PrlglIxBU2ZgWxKAZay1ICO6VmzDfJlEGnLAECJyGC /Vs2MKFCVNw2GEYw3q03IeZk8jybdaQZHCnbbEA=
X-Google-Smtp-Source: AGs4zMbjj4SUzB+izlBykZiGUKmaI5TWVBpKZHXF5aqFQmIlxKuKFt4cKm0OnN0gd/t7OpvXfaKtdGm4P8xqFUm5oCU=
X-Received: by with SMTP id i74mr4551283lfa.46.1510715139607; Tue, 14 Nov 2017 19:05:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 14 Nov 2017 19:05:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Jen Linkova <>
Date: Wed, 15 Nov 2017 14:05:18 +1100
Message-ID: <>
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan <>
Cc: Mark Andrews <>, 6man WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Nov 2017 03:05:44 -0000

On Wed, Nov 15, 2017 at 1:07 PM, Ole Troan <> wrote:
> If I may try to suggest a solution based on what you are saying:
> - Remove (external) DNS64 from the solution
> - Replace NAT64 prefix discovery with some sort of local configuration. e.g. put it in DHCP or RA
> Which has the implications that:
>  - host learns NAT64 prefix via RA/DHCP
>  - host is free to use whatever DNS recursive resolvers (instead of the must be local (and on correct interface where the NAT64 is) resolver
>  - host synthesises addresses itself. And does validation before synthesising (if that's required).
> Is this the solution you would be looking for?
> And yes, you need host changes. But we need that anyway.

NAT64 is a band aid, a tactical solution to deal with IPv4-only hosst
while we are waiting for them to die. Requiring *mandatory* changes on
majority of devices which are working on NAT64 networks just fine
currently to solve problems for those who either a) sign their zones
but do not enable Ipv6 b)doing some smart things in their host
resolvers looks like an overkill to me..

IMHO the optimal solution is:
- the network SHOULD provide a host with NAT64 prefix information in
RA (I do not believe that information needs to be duplicated in DHCP
at all);
- an application MAY use that information to do AAAA synthetics
(validating resolvers SHOULD do that).
- network still provides DNS64 servers to hosts so all unsophisticated
hosts (majority of devices falls into that category) continue to use
network-provided resolvers.

>> On 15 Nov 2017, at 08:06, Mark Andrews <> wrote:
>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <> wrote:
>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <> wrote:
>>> Is there any reason to run DNS64 at all these days? can be a preconfigured
>>> zone which allows CLAT to get its mapping.  All the phones have CLAT support.
>>> That's an interesting idea. It would work in theory, but such a network would completely break devices that don't support 464xlat. That gives up one of the major advantages of NAT64/DNS64, which is that it's a 90% solution even just by itself - yes, IPv4-only applications and address literals exist, but most simple client/server applications Just Work behind it.
>> And that 90% “solution” has lots of down sides.  It basically requires EVERY DNS VALIDATOR ON
>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first mooted.  It keeps on
>> requiring more and more highly invasive node changes to support.  It was from the very beginning
>> bad engineering.   To get IPv4 as a service some node changes are required.  Lets make sure they
>> are MINIMAL ones.
>> Just for the record DNSSEC validators need to send BOTH CD=0 and CD=1 queries to get answers
>> though a upstream VALIDATING server which includes a VALIDATING DNS64 server as CD=0 and
>> CD=1 address different DNSSEC threats.  I tried very hard to point that out when RFC 6147 was
>> being written but the working group decide that CD indicated whether the client was validating or
>> not.  There is NO SUCH INDICATION in a DNS message.
>>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>>   (CD) bit set, it is an indication that the querying agent wants all
>>   the validation data so it can do checking itself.  By local policy,
>>   vDNS64 could still validate, but it must return all data to the
>>   querying agent anyway.
>> CD=0 queries causes the upstream validating servers to reject incoming spoofed answers
>> or stale answers (this is a common operational problem).
>> CD=1 queries allow the validation to succeed when the upstream validator has a bad trust
>> anchor or a bad clock which is rejecting legitimate answers.
>> A validating client can’t just send CD=1 queries as the upstream validator doesn’t kick in.
>> The upstream validator can lock onto a stale answer source.  It needs to send CD=0 queries
>> on validation failure to force the upstream validator to try multiple sources.
>> A validating client can’t just send CD=0.  It needs to send CD=1 on SERVFAIL in case the
>> upstream validator has a bad trust anchor (likely with the upcoming root KSK roll) or has
>> a bad clock (these usually get fixed fast).
>> Now to get a answer from a signed zone with servers with stale answers a validatiing DNS64 client
>> needs to send:
>> a) send CD=1 and validation failure send CD=0 then on AAAA validation failure send CD=1 and
>>    hope the TTL was not 0 and that is not cachable and there is no assurance that you won’t get
>>    a answer from a stale source.
>>       or
>> b) send CD=0 and on validation failure of the AAAA send CD=1 and hope the TTL was not 0 as
>>    that is not cachable and there is no assurance that you won’t get a answer from a stale source.
>> TTL=0 answers exist.
>> Note none of this is documented in a RFC.  You have to understand how both DNSSEC and DNS64 work to
>> realise this.
>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix discover for DNS VALIDATORS.
>> Note “ad” is set in the flags.  Yes, I’ve submitted a errata.  Yes, I’ve opened a ticket to get it fixed but
>> based on past experience that could take months if it happens at all.  You will note that the recursive
>> server is running on the loopback interface so all DNS answers are being validated here.
>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>> ;; BADCOOKIE, retrying.
>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> ; EDNS: version: 0, flags:; udp: 4096
>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>> ;IPV4ONLY.ARPA.                       IN      A
>>                26574   IN      A
>>                26574   IN      A
>> ;; Query time: 0 msec
>> ;; SERVER:
>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>> ;; MSG SIZE  rcvd: 115
>> [rock:bind9/bin/named] marka%
>>> It's not true that all phones have clat support. Notably, Apple not only does not support it but appears ideologically opposed to it on the grounds that it does not have a good exit strategy (because it makes it possible to run IPv4-only apps forever).
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET:
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

SY, Jen Linkova aka Furry