Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Ca By <cb.list6@gmail.com> Wed, 22 April 2015 14:37 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C731B366E for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 07:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.348
X-Spam-Level:
X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no
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 FsYzDyKhvX6Y for <v6ops@ietfa.amsl.com>; Wed, 22 Apr 2015 07:37:42 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9B11B3673 for <v6ops@ietf.org>; Wed, 22 Apr 2015 07:35:51 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so88204787wic.1 for <v6ops@ietf.org>; Wed, 22 Apr 2015 07:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ytaPAXwsG6dvybHfLVsZHS02CBjFHlXPc+9y2AWQBYA=; b=tNUnuNWiG0bU3h5iz/lZdcdRY3N+lE/KrgQWKfWaDSWpwOYBeAQNN4iSrCU2l18syf fbFS8tWL08jDkQJK2v0GEm0ZFLzpTcM/O7OOMHJ1DVM4aN6L1IUx64Ce/F0zpIj2Ej+4 tx6lz/6NPrnk9zfGqb6P8zkyh7jtyhYL7n3TqZYIhJiTVqcpUGRmkHfHuMaez9jqzxq5 SdCBNpFPU6SG/BflctHvxUBrecdKwNlQvkJCWbU4b5mFiP31bv6lCnL/2uS2w8ZLjh4l 1RyW+tGoYJruesbZzPuFaflb27U/ZiAs7Hfocbn05bfABmAz09jP9Tb1wa9v48M5ATkh Pyzg==
MIME-Version: 1.0
X-Received: by 10.180.95.10 with SMTP id dg10mr6546906wib.41.1429713349945; Wed, 22 Apr 2015 07:35:49 -0700 (PDT)
Received: by 10.194.40.231 with HTTP; Wed, 22 Apr 2015 07:35:49 -0700 (PDT)
In-Reply-To: <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com> <CAD6AjGTcKgK8W+VB1H5EQpHaYiKVYXqOz_2RS-w_CiTf9kL2CQ@mail.gmail.com> <CADhXe530+OVZrFZVaYh1-zoRDvJhUd0rf4sx6a2nO8SvKmm6zg@mail.gmail.com> <CAPi140PQ+TF0rED_bQPeS=Fj415qt0-zE2RdGnEL34PAzHyx6Q@mail.gmail.com> <CAD6AjGTjXAeMF6pw5MO2Jrf9B8LJ48D3m1YTVkdBe=_OHjtroQ@mail.gmail.com> <CADhXe51TCqU2eMP4LS3DooZxQDAPD95OVJDXbiU7qvuvKCMq+w@mail.gmail.com> <CAKD1Yr2=zc57+pOA9TFs+0azw0ZR1g67+08T=9eZPHjGXBvgFQ@mail.gmail.com> <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com> <D1441574.4C168%wesley.george@twcable.com> <CAD6AjGQrzoBJrqQfKO0N8Ji=oJ-ZP6Sn88sXf=opJ6bYVmTDZg@mail.gmail.com> <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> <CADhXe51BDuPhc8wdKGmRiBfSnrz7PMtqYXaoDO+5cwLx_xW2tw@mail.gmail.com> <55290E26.8080500@cernet.edu.cn> <CADhXe50zz9EtNtifMh+tN9XT-jKCTJB=vsQ6uG515iddOo7f2Q@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E8C63A@UK30S005EXS06.EEAD.EEINT.CO.UK> <67A2A6E4-0603-4E84-8534-EA6C706C6D5D@lists.zabbadoz.net> <6536E263028723489CCD5B6821D4B21303E8CBAB@UK30S005EXS06.EEAD.EEINT.CO.UK> <0C3D10F1-B8AF-4097-91C6-D92CDDD5978D@nominum.com>
Date: Wed, 22 Apr 2015 07:35:49 -0700
Message-ID: <CAD6AjGR65jtZN4NV62p1XnUgoQRC+h=ELmsLcQaFTdrToMtwRA@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary="f46d04447f835aadb2051451140a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/O-Sg_e4yrkUCKvVstI8fIdS42g4>
Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Apr 2015 14:37:44 -0000

On Wed, Apr 22, 2015 at 6:59 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> On Apr 22, 2015, at 8:02 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:
> > If everyone complaining here, would work towards getting rid of them
> rather than discussing who’s problem it is to put a workaround in place,
> we’d probably be half-way done.  We have people crawling the web, people
> having users and test networks, people who seem to be able to write enough
> emails on the topic that they could even direct it to the right people.
>
> The problem is that the people who are using IPv4 literals are not
> _here_.   If fixing this were up to the people who are _here_, it would
> already have been fixed.   Nobody _here_ thinks that using IPv4 literals is
> okay (I suppose I will be corrected if I am wrong).
>
> So while what you are saying would definitely be right if those people
> were here, since they are not, it isn't practical.
>
>

The key is that:

1) We can only "fix" what is in our control -- as a network operator
464XLAT is in my  toolbox -- thank you IETF / Android / Microsoft.

2) Any solution that involves creating a negative customer experience (xyz
website or abc app does not work), is a non-starter.  Please stop
suggesting pain on paying customers, no network operator will do it. No
appstore will do it (with teeth, in the near term)

3) As Ted noted, the "ipv4-only deployers" are here and they are not
moving.  They include Google (hangouts), Apple (facetime), Spotify,
Netflix, so on and so forth. They understand the issue, and they are not
running to fix it.  So what is an ipv4-poor network to do?  Well, let's
check the tool box:

1) CGN -- tried true, but really just kicks the can down the road -- oh,
and RFC1918 ran out soo....  i hear there is some IPv4 space that is not
announce on the internet i can use .... So, this is a pretty anti-social
option, but it works.

2)  464XLAT / MAP / DS-lite -- Yay!  i can give users unique IPv6 public
addresses, grow the real IPv6 internet, and let ipv4 die on the vine (x
decade process, but real meaningful ipv6 progress now)

3.  Buy IPv4 (does not scale well, also anti-social)

Keep in mind, the tool box only includes these 3 things.  Wishing some
vigilante titan network is going to rain fire down on IPv4-only apps is not
realistic at all.  Same is true for  "mega-mobile-phone eco-system", they
will also not bar IPv4-only apps in a timescale that is helpful.  And, they
too have customers that want to go to http://192.0.1.1 on the public
internet ... and no, they are not going enroll networks to switch to
IPv6-only without IPv4-socket support to reach 99% of internet while other
networks are delivering 100% of the internet.

Regards,

CB




> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>