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

"George, Wes" <wesley.george@twcable.com> Fri, 03 April 2015 14:23 UTC

Return-Path: <wesley.george@twcable.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 A7DE31AC3A1 for <v6ops@ietfa.amsl.com>; Fri, 3 Apr 2015 07:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.926
X-Spam-Level: **
X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DkgsS6ZMl6Lj for <v6ops@ietfa.amsl.com>; Fri, 3 Apr 2015 07:23:37 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 21AA41AC3AF for <v6ops@ietf.org>; Fri, 3 Apr 2015 07:23:36 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,518,1422939600"; d="scan'208,217";a="670030616"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2015 10:09:07 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 3 Apr 2015 10:23:36 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: James Woodyatt <jhw@nestlabs.com>, IPv6 Ops WG <v6ops@ietf.org>
Date: Fri, 03 Apr 2015 10:23:35 -0400
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AdBuGcVjAu23NHBPQDajF0wuBStrkA==
Message-ID: <D1441574.4C168%wesley.george@twcable.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com> <alpine.DEB.2.02.1503200639340.20507@uplift.swm.pp.se> <20150320134204.32af9c67@echo.ms.redpill-linpro.com> <A0BB7AD89EA705449C486BDB5FDCBC7B28518DD8@OPE10MB06.tp.gk.corp.tepenet> <550F1F1F.3060703@cernet.edu.cn> <CAD6AjGSxk-Hrf_NBOjpV-jvraG+xSA4p1j-AO+FQFcVGzuf1Lg@mail.gmail.com> <CAKD1Yr3ywVy_00GYuw4Eq6cW_ZeL16bxpquaWWDMgSz44LagAg@mail.gmail.com> <CAD6AjGS-QMi+3oVGWDxnSMhEJH=VymwcF=PwKLdwFRxwHpp_-Q@mail.gmail.com> <CAKD1Yr3Fhnx3XaXouK57gupGOzodKGb0quhQxaf76NjWxSp3WA@mail.gmail.com> <CADhXe51MUB-czeCtpc63E0cHPpb_39Vv0o2Y57EVU2w_makP5Q@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>
In-Reply-To: <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D14415744C168wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/qU3DdFCDa6eEulDvttJSD2JS2uA>
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: Fri, 03 Apr 2015 14:23:39 -0000

From: James Woodyatt <jhw@nestlabs.com<mailto:jhw@nestlabs.com>>
Date: Thursday, March 26, 2015 at 6:23 PM
To: IPv6 Ops WG <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

There is only one thing applying any pressure of any kind to developers currently using IPv4 literals in their application protocols: that their applications FAIL on Apple operating systems when those devices connect to IPv6-only+NAT64 networks.

If Apple caves on this, as every other major vendor of mobile device operating systems has already caved, then developers will continue to rely on the viability of IPv4 literals as a protocol element for the foreseeable future. Those applications that do so will continue shipping with a reliance on 464XLAT for years to come, and they will continue to be used in critical processes for years after that when they are no longer under maintenance. There are people today scrubbing web pages and application protocols of their IPv4 literals, and they are mainly motivated to continue doing this by the need to deal with the fact that 464XLAT isn't universally deployed on all the major mobile platforms yet. Apple is the last noteworthy holdout.

Publishing a BCP that entails telling developers that IPv4 literals are legitimate for use as application protocol elements is unnecessary and counter-productive to the interests of the IETF in promoting adoption of IPv6. Instead it would communicate to developers that IETF is capitulating on IPv6, that it doesn't really believe in it anymore, and application developers should feel safe ignoring it for the foreseeable future.

WG] interestingly, most of the above statement still works if you do %s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that particular bandwagon too.

You're simply advocating for pushing this problem and therefore all efforts to motivate people to stop using IPv4 literals back onto the carriers, because you know full well that unlike Apple/Android did with flash, the carriers aren't going to intentionally break their user's experience to prove a point until the risk is vanishingly small, so they simply won't deploy IPv6-only+NAT64, because doing so will make the phone ring.

Perhaps if Apple believes that the developers need more motivation, there should be explicit guidance in the App store guidelines that apps using IPv4 literals, even on the server side, are unacceptable? (yes, I realize you no longer work there James). Lorenzo, does Android have such guidance? Even with 464xlat support, if that's there, then we're continuing the pressure on fixing it while acknowledging the operational reality of making a decent user experience until it's fixed properly.

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.