Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 13 June 2018 06:50 UTC

Return-Path: <prvs=17023f6860=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 4328E130EA0 for <v6ops@ietfa.amsl.com>; Tue, 12 Jun 2018 23:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 jHoitb8QVNLK for <v6ops@ietfa.amsl.com>; Tue, 12 Jun 2018 23:50:28 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37422130DFB for <v6ops@ietf.org>; Tue, 12 Jun 2018 23:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528872626; x=1529477426; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=ONHdqg8l/DT8A6C7IMB7S7 twd4EwnmSo80Ev3/HCaCY=; b=RYJtTxnHfCsG123REWJxzFO49IV7FuWqkS7PI+ sjjYi4EF1JiiLbCYsVMWiVfkDu+cQK/s2J9fYbqVnsGwt4/ydUCJq2n0Ked6VyLw Cy+kKaxDR1zoO+U68VKr+Q7oaCevl/ImuKMIFeIQ2OWxaUfJoJ/MX0kL6y82Y9Uj 88Mwo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 08:50:26 +0200
X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 08:50:26 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788527.msg for <v6ops@ietf.org>; Wed, 13 Jun 2018 08:50:25 +0200
X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Wed, 13 Jun 2018 08:50:25 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.d.1.180523
Date: Wed, 13 Jun 2018 08:50:21 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es>
Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas
References: <FEACFE5A-F2E6-4533-8602-C05F8A1FB59A@consulintel.es> <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <CAHL_VyDc1iF7T4k3J1uQvDYUpxaRg7_eOqK6poV_cZ-NAFAEDQ@mail.gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <CAKD1Yr2HpJFvW3=CQQV6HVr6tOGSW=Kj5mpO-rLLrEEuPZ4vmg@mail.gmail.com> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <CAKD1Yr3uSr-KJCOhTJvaf1xh4g7hOqwzxZSv7TNH5fB5Z1VigQ@mail.gmail.com> <C48F6BAD-84CE-4121-B862-218004A417D3@consulintel.es> <CAKD1Yr1_NeLyAmdAJitd=jUKeY0kW8qxV_9FWGCbNf1__ppecw@mail.gmail.com> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <CAKD1Yr1ohmb9BUV+KO2Ff+LJ1+pNwQ+-UJ6t7MmwY6PV3MLhyA@mail.gmail.com>
In-Reply-To: <CAKD1Yr1ohmb9BUV+KO2Ff+LJ1+pNwQ+-UJ6t7MmwY6PV3MLhyA@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3611724621_300309036"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xFoEm_eMfPVvN6ICBy-of0GL0ZI>
Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 13 Jun 2018 06:50:34 -0000

Lorenzo, you’re missing the key aspect: Being able to prioritize, when an ISP supports several transition mechanisms.

 

RFC8026 key aspect is priority. If we don’t add an option code for 464XLAT, then it can’t be managed the same way.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Fecha: miércoles, 13 de junio de 2018, 4:45
Para: <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:

You don’t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RFC7225).

 

1.       If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2.       If the operator wants to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

This doesn’t work, because the operator may be using RFC7225 instead of RFC7050. You need to try both in that case, and you aren’t providing a “priority” to a possible list of mechanisms, which is what RFC8026 does.

 

But it's the same problem again: what's the use case for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today.

  

3.       If the operator uses 464xlat, they should not allow the user to change the DNS server.

 

 

Let’s be realistic. You can’t “force” the customer to avoid changing the DNS …

 

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right?

_______________________________________________ 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.