RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Wed, 15 November 2017 13:35 UTC

Return-Path: <mohamed.boucadair@orange.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 014F7127137 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 05:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 inAmEgjUcPqJ for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 05:35:33 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5A2124B17 for <ipv6@ietf.org>; Wed, 15 Nov 2017 05:35:33 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id B5C74A0E6A; Wed, 15 Nov 2017 14:35:31 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 8BD461C0075; Wed, 15 Nov 2017 14:35:31 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 14:35:31 +0100
From: <mohamed.boucadair@orange.com>
To: Jen Linkova <furry13@gmail.com>, Ole Troan <otroan@employees.org>
CC: 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXWdFi4OqdfTJ20KXt2XmNGUMBaMUf56AgAAh5QCAABAMAIAAvzQQ
Date: Wed, 15 Nov 2017 13:35:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eb2cZqDcCmEkKCXuM9WXj6lMVJQ>
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 13:35:36 -0000

Hi Jen,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Jen Linkova
> Envoyé : mercredi 15 novembre 2017 04:05
> À : Ole Troan
> Cc : 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> 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);

[Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3 

Things may get complex if multiple NSPs are used for load-balancing or if destination based NAT64s are deployed. A list of issues is elaborated in https://tools.ietf.org/html/rfc7225#section-3.1 

> - 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
> > --------------------------------------------------------------------
> >
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------