Re: IPv6 only host NAT64 requirements?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 15 November 2017 10:24 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0D512706D for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 02:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpCQLhmF0FH0 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 02:24:31 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E454A128B88 for <ipv6@ietf.org>; Wed, 15 Nov 2017 02:24:30 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id b6so16463523pff.10 for <ipv6@ietf.org>; Wed, 15 Nov 2017 02:24:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YD0f3zO/O2aEmYliACWB7f6CggSaV2yMv9k1B7IIpV4=; b=VxlDxHxkruEGoEghONdBwN2Hd1ckOj/bt+fxbYAvO6Kgfqw/FlkpKz7jxrD/TkT/2i ZSyWcpSOVVCy3xiDEAWAuDDUwLdyl7lQK/94dm3duyrgvM3sqOPNn/rP2Fd5ManBjjEl L4rks0OrUNhsfCykOAfmL/BSh4sI5jnoXW8390TASp6WOvVELcnb36hkYxOK6UmRCSvI Uo6NSUVdvpfMNgRF/E/pJJ4uA+ViX4gc4Y7YGbYjCBxIJBYb3COeI5yxZ63WTU++3hoH hYmEfJcpMuunKxH+wdZhvOeA+kifUsxtUTHlJPrqfR1rsywSr6ABHNEQq+fsFzbU5xzb CZJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YD0f3zO/O2aEmYliACWB7f6CggSaV2yMv9k1B7IIpV4=; b=TnWkpZElMkWinO5PIYLNBxNu39pLPUxFM2JWEi10HyyxPStsXJiRcDYZ+j67zqzeXF MBGl7Hh4vqJHhwFcQqRJtJ40pjYywEZhuxpv+HPF+Cu6XPfiFIkW3dVV98hvwUIqhGow NMkgqWMv3VAU7Gv1ioA5vd7P+LbpENKDbkBckznSfVyUVYWbnlF/hnfFp2O+mVyLJV3W e4HMUtqmVn1FCEWNRSW8yi5FbSbX1z+HmgcEyQ3g/BvJZqTk0wkTvyUaFb89mV8nC/qk vQiiI2wMB0AZplLIkfhumv/FMpP+RdrZqQTli1ed/1XIaY0oZoKSIGYoCvlPKf6adS6Z Zsww==
X-Gm-Message-State: AJaThX40vZElcyeCtWejxNqHY2sZO1TdiLaoit7FoVIF4He7lqVLbNaN elolfE8A+r6BVrxWOGL6IibRuA==
X-Google-Smtp-Source: AGs4zMZ+FfWifVkgTJiRqLUIqEOvxcqibT6am5Bm6bTdkNXqjOL8nyCvKlHJ5sSJ+TRD2ziUJ1iKdw==
X-Received: by 10.84.131.6 with SMTP id 6mr15697751pld.100.1510741470360; Wed, 15 Nov 2017 02:24:30 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s65sm43811852pfj.81.2017.11.15.02.24.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 02:24:29 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Jen Linkova <furry13@gmail.com>, Ole Troan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <449b423b-9d60-82e9-19ea-a9e8fc197086@gmail.com>
Date: Wed, 15 Nov 2017 23:24:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Q1MfvlY2o3-XFwYl1oPVTuxQbVs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 10:24:33 -0000

Excuse front posting but +1, this is IMHO just about the
last thing worth saying on this thread.

Regards
   Brian

On 15/11/2017 16:05, Jen Linkova wrote:
> On Wed, Nov 15, 2017 at 1:07 PM, Ole Troan <otroan@employees.org>; 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 <marka@isc.org>; wrote:
>>>
>>>
>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <lorenzo@google.com>; wrote:
>>>>
>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <marka@isc.org>; wrote:
>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa 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
>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SERVER.
>>>
>>> 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
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>> ;; QUESTION SECTION:
>>> ;IPV4ONLY.ARPA.                       IN      A
>>>
>>> ;; ANSWER SECTION:
>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>> ;; 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: marka@isc.org
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
>