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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 25 September 2017 10:27 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 7B833134224 for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 03:27:45 -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 xswqpHEjaxqV for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 03:27:44 -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 946461320DC for <v6ops@ietf.org>; Mon, 25 Sep 2017 03:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506335260; x=1506940060; 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=1OJQ7UNf3qEIScyBTnrkcSzw5 qYxD6QI/WnkNpBNTb4=; b=d4J5IY9acosXVEzCGQcMZMsQE5ZkrSuK2lkJFshEz 3GwSbNp7RdYfJ5Po0pkLv0CgkqZv6+Hum/st6nhLetNaGnWqKq9nSpyIie4Lo3ec pbGHLqNqX03PyRMZpHEDXXZh/TSBlVqR2LPRLqi9qyg9ukNB2wwpov2VWLhj5+CR t4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rzRZkRNLH5YvvMLl1u6926pqCxU5IbuzUZEhrBp/rwzl8yQtVqk8MSgyA4eF o5S+nqNSp1agic9IcF9jkYJ003pyrDLh5avtQF3ljvqgD8mErRU34E3P3 Bsdj+3MvGLzl7Hcek9bWzhuzYG4mmJcpjTvHjhJB6qY8csfjK5FgTo=;
X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 12:27:40 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 12:27:40 +0200
Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566650.msg for <v6ops@ietf.org>; Mon, 25 Sep 2017 12:27:39 +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:md50005566650::lEE4s71KC9aXBBqB:00001x3d
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 12:27:36 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <7CBE3779-8A7F-4A77-A83A-A73B20600C92@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>
In-Reply-To: <e5e878a2-c26e-57d4-5e23-718a16e7bc5a@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/OkjIrdO7DwsDgk4dPP9_ZkAomMU>
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 10:27:45 -0000

Maybe you’re not there, but operators live in a world where they don’t have any more IPv4 addresses, 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.

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

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.