Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 25 September 2017 11:07 UTC

Return-Path: <prvs=1441fc161e=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 C602E1320DC for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 04:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 HK_tU_XwUdFj for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 04:07:17 -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 E4B44134218 for <v6ops@ietf.org>; Mon, 25 Sep 2017 04:07:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506337634; x=1506942434; 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=G56+8Yjp/u/QwvKklYJhyRLZA e5dqFaT11z6cNXDMIk=; b=tsYXVrBP41h8On8HSEQnVFPXKBYq84LrbJhvRdC4n uUfHfbVd1pYqz1bkmb+9RJnVJ/FYZhevMZXLe55NR+357Hxzq2G9jZJqnq4UGi0O RF5/MiF/H77HALl1oUJIkWW+OaBLJUjLU5lxX7z7cq8YBrXKPRykhvA59anLIMev LM=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=SUjQbB5pp+OvzwE13qmGZnBcC2Jrl/ga6THTsz2JVY+vJhzXq6UfMZlKr748 PUGmmeL6c89I0XRzaG1HhBkJqBwsJW7jXsD5NoycONoRkM8tq6u3wFDVf PShLnRKlst3d2E0Z6G73TMGEYxLyHBjfOPHDdTGdDWmNgleORUKOCg=;
X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 13:07:14 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 13:07:13 +0200
Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566725.msg for <v6ops@ietf.org>; Mon, 25 Sep 2017 13:07:12 +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:170925:md50005566725::jm7NB5mrkl3q6SWC:00001OED
X-Return-Path: prvs=1441fc161e=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: Mon, 25 Sep 2017 13:07:05 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <31CF5D7F-6A46-463E-883E-16F4DA4CBEE8@consulintel.es>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence
References: <D5E8043B.86B21%lee@asgard.org> <E48DDA04-C058-4992-906E-8C8BC0E102AB@consulintel.es> <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <FA8911A1-CE3E-40E2-A11F-12303A3B4D1C@asgard.org> <e38bb7d2-1376-e790-8c20-19d54ec6b163@gmail.com> <alpine.DEB.2.20.1709251025270.18564@uplift.swm.pp.se> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <alpine.DEB.2.20.1709251152340.18564@uplift.swm.pp.se> <e5e878a2-c26e-57d4-5e23-718a16e7bc5a@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> <dc7cf11f-c184-6872-da29-f3892c373d77@gmail.com>
In-Reply-To: <dc7cf11f-c184-6872-da29-f3892c373d77@gmail.com>
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/qrIa3CeHJJDfJmmGEeUxaQ9pyN0>
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence
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: Mon, 25 Sep 2017 11:07:19 -0000

Many operators have not CGN yet, so IPv6-only solutions even if they require NAT64 are more efficient (you have even open source for NAT64) and IPv4 usage of a few IPv4 public addresses scale much better with NAT64 than in CGN. And of course, if you have IPv6-only-access it means more and more of your traffic is going thru to IPv6 destinations, so you have less and less usage of any transition stuff.

In addition to that there are implications in terms of battery and radio bandwidth (keep-alives for CGN), which have much less impact if the access network is IPv6-only.

I’ve not seen any native IPv6 app that gets impacted by transition. I agree that transition is always imperfect, one way or another for IPv4, but we need to balance between long-term strategy or staying forever with IPv4.

Actually 464XLAT is really inexpensive, much less CapEx and OpEx than any other transition and even than dual-stack-access.

Saludos,
Jordi
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Alexandre Petrescu <alexandre.petrescu@gmail.com>
Responder a: <alexandre.petrescu@gmail.com>
Fecha: lunes, 25 de septiembre de 2017, 12:42
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence

    
    
    Le 25/09/2017 à 12:37, JORDI PALET MARTINEZ a écrit :
    > Are you going to pay from your pocket the operators for the extra CGN
    > cost? They may agree in that case!
    
    Look to be clear, I am not paying anything from my pocket.
    
    Moreover, what I am saying is less cost.
    
    CGNs and all computers in the world already run IPv4.  Continue do that 
    for IPv4.
    
    If you need new IPv4 address space, use NAT.
    
    And if you want IPv6, then use all the available IPv6 software for it.
    
    It's called "double stack".
    
    Dont do v4-v6 translations, because they prohibit you from running some 
    native IPv6 apps.  And they are expensive.
    
    Alex
    
    > 
    > Regards, Jordi
    > 
    > 
    > -----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en
    > nombre de Alexandre Petrescu <alexandre.petrescu@gmail.com> Responder
    > a: <alexandre.petrescu@gmail.com> Fecha: lunes, 25 de septiembre de
    > 2017, 12:34 Para: <v6ops@ietf.org> Asunto: Re: [v6ops] reclassify
    > 464XLAT as standard instead of info - double stack coexistence
    > 
    > 
    > 
    > Le 25/09/2017 à 12:27, JORDI PALET MARTINEZ a écrit :
    >> [...] but operators live in a world where they don’t have any more 
    >> IPv4 addresses,
    > 
    > False, they always have access to NAT space.
    > 
    > Keep NAT for IPv4, leave IPv6 alone.
    > 
    >> so double-stack is over in the access networks. However, there are 
    >> devices and apps (in both cellular/tethering and non-cellular),
    >> that are IPv4-only, so user networks/LANs, need some transition
    >> support to make IPv4 transparently available end-to-end.
    > 
    > That need can not be satisfied to a large scale.  Make it work
    > inside some domain, with some translation, but cant work for all.
    > 
    > It's plain NAT.
    > 
    >> Last week I did a presentation and I was making a joke:
    >> 
    >> - I’ve been told that the only secure thing in this life is death
    >> … well not anymore, some scientifics said they are close to find
    >> the way avoid death … So. the new “for sure” thing in this life, is
    >> that we are going to an IPv6-only world (and I’m referring here to
    >> access networks, maybe even some core/distribution networks).
    > 
    > I agree.
    > 
    > Saludos,
    > 
    > Alex
    > 
    >> 
    >> Saludos, Jordi
    >> 
    >> 
    >> -----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en 
    >> nombre de Alexandre Petrescu <alexandre.petrescu@gmail.com>
    >> Responder a: <alexandre.petrescu@gmail.com> Fecha: lunes, 25 de
    >> septiembre de 2017, 12:07 Para: Mikael Abrahamsson
    >> <swmike@swm.pp.se> CC: <v6ops@ietf.org> Asunto: Re: [v6ops]
    >> reclassify 464XLAT as standard instead of info - double stack
    >> coexistence
    >> 
    >> Le 25/09/2017 à 11:53, Mikael Abrahamsson a écrit :
    >>> On Mon, 25 Sep 2017, Alexandre Petrescu wrote:
    >>> 
    >>>> I mean GTPU protocol that uses IPv4 addresses, and carries
    >>>> IPv6 packets
    >>> 
    >>> This is not something the end user device sees or cares about.
    >> 
    >> But the end-user device connects to a network, and you claim that 
    >> network is IPv6-only.
    >> 
    >> You claim that because there are networks that are IPv6-only then 
    >> devices must run CLAT.
    >> 
    >> But what is "IPv6-only networks"?  Do they use IPv4 though?
    >> 
    >>> Why are you bringing this up?
    >> 
    >> Because I need to understand whether the APNs dedicated to CLAT
    >> run IPv6-only.  Do these networks do GTP-v4?  And PDP type
    >> IPv4-IPv6?
    >> 
    >> One would like to have coherence between IPv4, IPv6, APN type, PDP 
    >> type, encapsulations, translations.
    >> 
    >> The ideal is "double stack" - no encap, no translation, no IN A in 
    >> UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6.
    >> 
    >> Alex
    >> 
    >> _______________________________________________ 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
    >> 
    > 
    > _______________________________________________ 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
    > 
    
    _______________________________________________
    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.