Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

Ole Troan <otroan@employees.org> Tue, 10 October 2017 10:18 UTC

Return-Path: <otroan@employees.org>
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 1B08F134C65 for <v6ops@ietfa.amsl.com>; Tue, 10 Oct 2017 03:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 eHY5JRsyJSIb for <v6ops@ietfa.amsl.com>; Tue, 10 Oct 2017 03:18:42 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9CE1344BA for <v6ops@ietf.org>; Tue, 10 Oct 2017 03:18:42 -0700 (PDT)
Received: from h.hanazo.no (unknown [173.38.220.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 85B472D5072; Tue, 10 Oct 2017 10:18:41 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B00102004A6F41; Tue, 10 Oct 2017 12:18:39 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <4213D38C-E6FB-4FF7-B389-5CE441810812@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_BA6880CF-79BB-4CCF-97D3-C4EBCD67D18F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Tue, 10 Oct 2017 12:18:38 +0200
In-Reply-To: <0E846EA7-2EB5-4C38-94A6-800E6E9CADA0@consulintel.es>
Cc: IPv6 Ops WG <v6ops@ietf.org>
To: Jordi Palet Martinez <jordi.palet@consulintel.es>
References: <150755581666.18336.7914755965262691836.idtracker@ietfa.amsl.com> <CB970DA1-7E14-4E38-8FE1-535108518819@consulintel.es> <CAD6AjGQJXFOEysWbDRM3JZwy2JKquxzpTTDy5_XbOm7-Db7xjg@mail.gmail.com> <alpine.DEB.2.20.1710091711380.31961@uplift.swm.pp.se> <D4D1D13A-6B68-4FF8-BF11-922813CC7F6E@consulintel.es> <0B596B2B-328C-48B0-B1A9-19184D07B889@employees.org> <0E846EA7-2EB5-4C38-94A6-800E6E9CADA0@consulintel.es>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jLLJhUtOYwnLq1Pd58y339ogMUQ>
Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt
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: Tue, 10 Oct 2017 10:18:44 -0000

Jordi,

> It is not required, but using it allows traffic from non-literals to have a single translation at the NAT64.

Yes, but then it is not 464XLAT. It is NAT64. It's a lot easier having a discussion if we agree on the terminology.

Ole


> 
> Furthermore, I believe several big mobile operator network deployments, are using DNS64.
> 
>> From RFC6877:
> 
> The 464XLAT architecture described in this document uses IPv4/IPv6
>   translation standardized in [RFC6145] and [RFC6146].  It does not
>   require DNS64 [RFC6147] since an IPv4 host may simply send IPv4
>   packets, including packets to an IPv4 DNS server, that will be
>   translated to IPv6 on the customer-side translator (CLAT) and back to
>   IPv4 on the provider-side translator (PLAT).  464XLAT networks may
>   use DNS64 [RFC6147] to enable single stateful translation [RFC6146]
>   instead of 464XLAT double translation where possible.  The 464XLAT
>   architecture encourages the IPv6 transition by making IPv4 services
>   reachable across IPv6-only networks and providing IPv6 and IPv4
>   connectivity to single-stack IPv4 or IPv6 servers and peers.
> 
> Regards,
> Jordi
> 
> 
> -----Mensaje original-----
> De: Ole Troan <otroan@employees.org>
> Responder a: <otroan@employees.org>
> Fecha: martes, 10 de octubre de 2017, 12:03
> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
> CC: IPv6 Ops WG <v6ops@ietf.org>
> Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt
> 
>    Jordi,
> 
>    I think you are confused.
>    There is no DNS64 in 464XLAT.
>    You seem to be talking about NAT64 (RFC6146), not 464XLAT.
> 
>    Ole
> 
>> On 10 Oct 2017, at 10:53, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>> 
>> Hi Mikael,
>> 
>> So, in your opinion, if I understand it correctly:
>> 1) DNSSEC must not be ignored
>> 2) DNS64 should be supported
>> 
>> Could you agree in a document that describes different deployment models supporting or not 1, 2, above?
>> 
>> Regards,
>> Jordi
>> 
>> 
>> -----Mensaje original-----
>> De: Mikael Abrahamsson <swmike@swm.pp.se>
>> Organización: People's Front Against WWW
>> Responder a: <swmike@swm.pp.se>
>> Fecha: lunes, 9 de octubre de 2017, 17:17
>> Para: Ca By <cb.list6@gmail.com>
>> CC: Jordi Palet Martinez <jordi.palet@consulintel.es>, IPv6 Ops WG <v6ops@ietf.org>
>> Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt
>> 
>>   On Mon, 9 Oct 2017, Ca By wrote:
>> 
>>> For a BCP, it may be best reflected that the *common* practice of
>>> operators is to pay no mind to DNSSEC.
>> 
>>   Comcast does DNSSEC validation from what I have understood. Google DNS
>>   (8.8.8.8) does the same.
>> 
>>   80% of Internet users in Sweden sit behind a DNSSEC validating resolver.
>> 
>>   Unfortunately at this point in time https://stats.labs.apnic.net/dnssec/US
>>   is not working so I can't give you numbers. DNSSEC has a non-trivial
>>   deployment base and needs to be taken into account. I wouldn't use that
>>   argument to stop DNS64 though.
>> 
>>   --
>>   Mikael Abrahamsson    email: swmike@swm.pp.se
>> 
>> 
>> 
>> 
>> **********************************************
>> 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 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 mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops