Re: IPv4 outage at next IETF in Chicago

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 24 January 2017 23:43 UTC

Return-Path: <prvs=1197ee1ff8=jordi.palet@consulintel.es>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EB21295A5 for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 15:43:58 -0800 (PST)
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 uv1rHS8_ur2I for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 15:43:56 -0800 (PST)
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 D230312959D for <ietf@ietf.org>; Tue, 24 Jan 2017 15:43:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1485301431; x=1485906231; 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=iFjXwixjcabv4KvmrqBITJFmq evXyYLvm/8Srix9pi0=; b=JX46Bi20w4qTUROPRpFqb3ip4QeyDGbk2LlhUJnxq aW3Gr5GITOnNnvHEJXBM42LqONenD07tYq90KYMRYJx3jyyt8+vFgXCnX8AzO7hP 5z1RPsw5lVX1a88gKcXG55GEAUzlDZfH3oqRLh+g4DnplhbkNTOhe+ySRUXulbGt i8=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=qSciRKv40XrWuGsH20HU0jgwxYIT5NJs+m8hmWJ1GDqIhuU/dA0scKkAl60c z4bdNMmmaK7T5HmTQHZTUVMoc5TEg2f5jEgUWGNQNJQuK4EzmohyLHzPi CN3cdnyig53U8Am6rCgKzglylGw9zukAF2bzMQ0Oz4yhHiBtJsf+GI=;
X-MDAV-Processed: mail.consulintel.es, Wed, 25 Jan 2017 00:43:51 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 25 Jan 2017 00:43:45 +0100
Received: from [172.20.62.10] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005351108.msg for <ietf@ietf.org>; Wed, 25 Jan 2017 00:43:43 +0100
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:170124:md50005351108::5R/x5AGXEwYWQTyW:00000Rhu
X-MDRemoteIP: 181.193.111.123
X-Return-Path: prvs=1197ee1ff8=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
User-Agent: Microsoft-MacOutlook/f.1e.0.170107
Date: Tue, 24 Jan 2017 17:41:39 -0600
Subject: Re: IPv4 outage at next IETF in Chicago
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IETF <ietf@ietf.org>
Message-ID: <DB3F2816-44DE-47BE-B593-39DE93B94379@consulintel.es>
Thread-Topic: IPv4 outage at next IETF in Chicago
References: <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org> <CAAiTEH_+ya3gdmC9Lhzgvrrk_--20MTvws0-oDaJ4EjJ7tEvng@mail.gmail.com> <WM!96c7112709147f3ce99c7eb85aad041a553342c0bd269f50eb4fdcff72852d7f0cb66c68c6a4dabe1f93681bbfadff75!@mailstronghold-1.zmailcloud.com> <286063743.114032769.1485300897019.JavaMail.zimbra@peachymango.org>
In-Reply-To: <286063743.114032769.1485300897019.JavaMail.zimbra@peachymango.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8a3p5vetqduJUZQ8laOp2x4T-fo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2017 23:43:58 -0000

NAT64 doesn’t work for ALL the apps, they may use older API/socks, literal IPv4 addresses, etc.

464XLAT does it, this is what is deployed at the cellular networks in US and many other countries.

Saludos,
Jordi


-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org> en nombre de Franck Martin <franck@peachymango.org>
Responder a: <franck@peachymango.org>
Fecha: martes, 24 de enero de 2017, 17:34
Para: Matthew Pounsett <matt@conundrum.com>
CC: IETF <ietf@ietf.org>
Asunto: Re: IPv4 outage at next IETF in Chicago

    
    
    ________________________________________
    
    From: "Matthew Pounsett" <matt@conundrum.com>
    To: "Franck Martin" <franck@peachymango.org>
    Cc: "IETF" <ietf@ietf.org>
    Sent: Tuesday, January 24, 2017 3:23:34 PM
    Subject: Re: IPv4 outage at next IETF in Chicago
    
    
    
    
    
    
    On 24 January 2017 at 15:11, Franck Martin <franck@peachymango.org> wrote:
    
    
    So to be conservative but at the same time futurist and like it was done a few years back, why not create again an IPv4 outage of a few hours where the above 2 networks would be the only networks available? 
    
    
    Depending on results, this outage could be expanded to a full day at the following meeting, until the IPv4 network is totally removed from the WiFi?
    
    
    
    
    
    If you wish to test that your networks are reachable from a v6-only environment, there is already a v6-only network you can use to test that.  Many of us require access to the entire Internet to do our jobs, however.
    
    
    
    
    
    
    NAT64 allows you to reach the entire IPv4 network, so you should be able to continue to do your job. NAT64 is already deployed on many mobiles in the US.
    
    
    Why moving from dual stack IPv4/IPv6 to IPv6 with NAT64?
    
    It ensures that all the OS and client applications can work in an IPv6 only environment while still be able to reach legacy systems (aka IPv4).
    
    
    
    
    
    





**********************************************
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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.