Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 28 September 2017 08:06 UTC
Return-Path: <prvs=14445c1049=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DD913555E for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 01:06:00 -0700 (PDT)
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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 2AzbA5iTWU87 for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 01:05:58 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260D2135562 for <v6ops@ietf.org>; Thu, 28 Sep 2017 01:04:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506585844; x=1507190644; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=yKXkvYSjG2xdgHW8oii1o9VbB w9cGWNv+hBQJJmqHkI=; b=Hn48cxpFIVqDWq0DAikO3EU2hlNuCZeH+GDX3B643 MMNpKfMmjk+eJKR3bcH7aoO1cQvtNuR2/gnEvLIrG1DTVj6uJYvJdSU5ivczjhg5 qD3CRVckvE4JWoTU+MH2Ncsj2L7BMDU833ENZNS6FcYrc/iFZdMEze+iFC7KGimx uk=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=difA0lhvM5Y0TyMSPslpl5W7Y51eo7zGL0Y0ZGUN1M3U8hnRCHC9D7XeI+IH m8hBr3Z4bznjB2ZMQYEi1ckaTaTLGx+0QEe7AALy27lUDlSfIfG8/DKoC 9R6hd62sacVBUZvP9OpSVO5QQ5Ajpc7mcSmpm4B9y62T3amF4iyS7U=;
X-MDAV-Processed: mail.consulintel.es, Thu, 28 Sep 2017 10:04:04 +0200
X-Spam-Processed: mail.consulintel.es, Thu, 28 Sep 2017 10:04:03 +0200
Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005570486.msg for <v6ops@ietf.org>; Thu, 28 Sep 2017 10:04:03 +0200
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170928:md50005570486::tAKFKfTZRgkzV8Tg:00003JjI
X-Return-Path: prvs=14445c1049=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.26.0.170902
Date: Thu, 28 Sep 2017 10:04:03 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <911FED7C-63A7-4F55-A3FE-F97B492E4E82@consulintel.es>
Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <46045DAA-9096-43BA-A5FD-571232767726@google.com> <CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.com> <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com> <LO1P123MB0116805F9A18932E2D0694FEEA780@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com> <CAKD1Yr03zsuSBqPegs6RNbBqnJizUOLZwH+rNDi1Ocg4k+mARQ@mail.gmail.com> <20170928030630.DD2D08867238@rock.dv.isc.org> <alpine.DEB.2.20.1709280753080.18564@uplift.swm.pp.se> <20170928074105.BCB99886E538@rock.dv.isc.org>
In-Reply-To: <20170928074105.BCB99886E538@rock.dv.isc.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jNsC2t1oWXqVAGpgISW5gU_yO28>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 08:06:00 -0000
You can have a DNS validator, aware of DNS64. In the worst case, if you don’t like having a DNS validator aware of DNS64, a much simpler solution is to NOT use DNS64. 464XLAT works also in that scenario, you just force all the IPv4-only traffic to be translated at both sides the CLAT and the PLAT. This is not worse than when you do NAT44. As this traffic is going to be less and less IPv4, again this is not an issue. Regards, Jordi -----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en nombre de Mark Andrews <marka@isc.org> Responder a: <marka@isc.org> Fecha: jueves, 28 de septiembre de 2017, 9:42 Para: Mikael Abrahamsson <swmike@swm.pp.se> CC: "Heatley, N, Nick, TQB R" <nick.heatley@bt.com>, IPv6 Ops WG <v6ops@ietf.org>, james woodyatt <jhw@google.com> Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) In message <alpine.DEB.2.20.1709280753080.18564@uplift.swm.pp.se>, Mikael Abrah amsson writes: > So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually > doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't > have to do DNS64 (apart from the well-known "prefix detection" zones. You do know the RFC 7050 doesn't work with DNSSEC validation enabled. RFC 7050 specifies CD=0. ipv4only.arpa/AAAA (CD=0) -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA (CD=0) -> DNS64 server ipv4only.arpa/AAAA ANCOUNT>0 -> validating recursive server (or local validating cache) rejected as ipv4only.arpa is signed. SERVFAIL -> client Lets try with CD=1 ipv4only.arpa/AAAA (CD=1) -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA (CD=1) -> DNS64 server (no synthesis as CD=1) ipv4only.arpa/AAAA ANCOUNT=0 -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA ANCOUNT=0 -> client (no prefixea found) To get it to work the validating recursive server has to detect that prefix discover is occuring. Perform its own prefix discovery. Synthesis a prefix discover response. So yes 464XLAT does require DNSSEC to be broken. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
- [v6ops] 464xlat case study (was reclassify 464XLA… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Simon Hobson
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… james woodyatt
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… james woodyatt
- Re: [v6ops] 464xlat case study (was reclassify 46… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… james woodyatt
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Ole Troan
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Ole Troan
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Ole Troan
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Erik Kline
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Erik Kline
- Re: [v6ops] 464xlat case study (was reclassify 46… Rajiv Asati (rajiva)
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Gert Doering
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] DHCPv6-PD presence on OSs, and GTP qu… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Erik Kline
- Re: [v6ops] DHCPv6-PD presence on OSs, and GTP qu… Mikael Abrahamsson
- Re: [v6ops] GTP questions Alexandre Petrescu
- Re: [v6ops] GTP questions Ca By
- Re: [v6ops] GTP questions Rajiv Asati (rajiva)
- Re: [v6ops] GTP questions Alexandre Petrescu