Re: IPv4 outage at next IETF in Chicago

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 25 January 2017 01:50 UTC

Return-Path: <prvs=11986b3303=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 BAEE81295F8 for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 17:50:57 -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 b_SWoWBkuoaS for <ietf@ietfa.amsl.com>; Tue, 24 Jan 2017 17:50: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 0C1C81295CD for <ietf@ietf.org>; Tue, 24 Jan 2017 17:50:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1485309051; x=1485913851; 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=HM9jS8pN+2KliE5hK0WS0hxXm PsQUIvNwFVr7C7kf4w=; b=lml0dJCuMzC3pkuZN42diXxPs+wNiHZDy1S06+Inm TLUOMYo0Arg1d3HpBjipd7ZwT+DwjSSaY7j+lcitdIo/4Cnt2QxqkRRoodWmWAXf 9PrMbEH4Id2gSyXBF/FGGcWP9JvLBV4hYNEH8RhHxH42GraNOh5GTKc+hVGf8juB YM=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=YIum3toGhUs0L1Bh7wSXJMu7k8OS7B4O0i8IXex6wZAnGOithnVc1rWoW8AZ k6LvUT9q7AgP583luTcVNX6mVHzAbx/0GAaaaFR0HtnJ96uAPHfCCrTuX R9gmh58CMGbqgqt6HxCQV0oTdcx2lrYMAGWHLx5shOeKo09BxRIc1k=;
X-MDAV-Processed: mail.consulintel.es, Wed, 25 Jan 2017 02:50:51 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 25 Jan 2017 02:50:46 +0100
Received: from [172.20.62.10] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005351165.msg for <ietf@ietf.org>; Wed, 25 Jan 2017 02:50:45 +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:170125:md50005351165::Yi56+0OfNH8DW2a1:00000LCe
X-MDRemoteIP: 181.193.111.123
X-Return-Path: prvs=11986b3303=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 19:50:37 -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: <4BCF0958-96DC-4647-B1D0-9B7D50F95B91@consulintel.es>
Thread-Topic: IPv4 outage at next IETF in Chicago
References: <844840869.114000858.1485299485194.JavaMail.zimbra@peachymango.org> <8112f1a6-f63a-e771-f354-206fbb9d684f@gmail.com> <WM!9d8566ee4a667cbd16edab2df707ef7a0c8c696ee92bca1ab194c80d7f9f38afca46538cbe422dcfd43306b1345f3435!@mailstronghold-1.zmailcloud.com> <212835829.114144965.1485306337275.JavaMail.zimbra@peachymango.org> <2f5e2404-7d71-afcc-9b50-4d791ef74299@gmail.com>
In-Reply-To: <2f5e2404-7d71-afcc-9b50-4d791ef74299@gmail.com>
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/r7ywM8Di-Kxpc9u3rER2uMk1iok>
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: Wed, 25 Jan 2017 01:50:58 -0000

Sometimes, is not IETF people fault, I will say most of the time.

We all are mandated, by corporate policy to use apps (that we don’t develop), which may still use IPv4 literals, older APIs, etc. Those will fail. The same that will fail if we live in a world with IPv6 only access networks for our offices or homes and don’t have dual-stack in our LAN with something to sort out the problems of those apps.

You want an example, just try skype with NAT64 … (unless they sorted it out already).

Some more (I found a table some time ago googling, but not sure where is it): Google Talk, Google+, Last.fm, Netflix, ooVoo, Pirates of the Caribean, Spofity, Tango, Texas Poker, …



Regards,
Jordi


-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org> en nombre de Brian E Carpenter <brian.e.carpenter@gmail.com>
Organización: University of Auckland
Responder a: <brian.e.carpenter@gmail.com>
Fecha: martes, 24 de enero de 2017, 19:21
Para: Franck Martin <franck@peachymango.org>
CC: IETF <ietf@ietf.org>
Asunto: Re: IPv4 outage at next IETF in Chicago

    Franck, I try not to be religious about NAT, and I use NAT44 every day
    like most people. Also like most people, I experience occasional
    unexplained failures of web-based transactions. Whether they are due
    to a NAT garbage-collect or a load-balancer failure, I don't know,
    of course. But actually I am not deeply concerned about NAT64, although
    any failures that it generates would be very hard to identify. I am
    more concerned about IETF participants whose devices are not set up
    as dual stack nodes at all. They would be completely blocked. Yes,
    I know, such people should not exist, should be deeply ashamed, etc.
    But I don't see why we would cut them off to prove a point.
    
    Regards
       Brian
    
    On 25/01/2017 14:05, Franck Martin wrote:
    > 
    > ----- Original Message -----
    >> From: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
    >> To: "Franck Martin" <franck@peachymango.org>, "IETF" <ietf@ietf.org>
    >> Sent: Tuesday, January 24, 2017 4:33:22 PM
    >> Subject: Re: IPv4 outage at next IETF in Chicago
    > 
    >> On 25/01/2017 12:11, Franck Martin wrote:
    >>> I think it is time to move to the next level of IPv6 deployment.
    >>>
    >>> Ideally the IETF WiFi network should now only provide the following 2 networks:
    >>> 1)IPv6-only
    >>> 2)IPv6-only with NAT64
    >>>
    >>> The later should be the default network.
    >>>
    >>> However you would say, well some stuff will break, some non technical people
    >>> will use the IETF network and may have a bad experience, etc...
    >>>
    >>> 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?
    >>
    >> That would be a good way of damaging IETF productivity for a few hours.
    > 
    > Do you have evidence of applications not running in a NAT64 environment? I'm interested to know them.
    > 
    >>
    >> And for what? Moving away from the mainstream coexistence mechanism (dual
    >> stack),
    >> to a mechanism known to be intrinsically defective (NAT). I don't see the point.
    >>
    > 
    > I fail to see how NAT is intrinsically defective, since it is used successfully by everyone...
    > 
    > Nevertheless, the goal here is to get the Internet designers (IETF) to have operational experience on what needs to be fixed.
    > 
    > When the IPv4 outage happened a few years back, it gave a serious impetus in getting IPv6 totally mainstream on many platforms.
    > 
    > IAB encourages IPv6: https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
    > 
    > However going IPv6-only can only be done in walled gardens. There still will be many environments with IPv4 only. A solution here is to move networks to NAT64, so you only need to support IPv4 at the edges...
    > 
    > Yes creating an outage for the sake of an outage is pointless, experience on what works and not work needs to be recorded.
    > 
    > May be the first step instead of doing an outage is to have as default a NAT64 network at IETF meetings and a dual stack network for the people that experience issues.
    > 
    >  
    > 
    
    
    



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