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

Ross Chandler <ross@eircom.net> Thu, 26 March 2015 22:58 UTC

Return-Path: <ross@eircom.net>
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 682031A1A60 for <v6ops@ietfa.amsl.com>; Thu, 26 Mar 2015 15:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 vcOVCzMUyzUN for <v6ops@ietfa.amsl.com>; Thu, 26 Mar 2015 15:58:23 -0700 (PDT)
Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by ietfa.amsl.com (Postfix) with SMTP id B3E331A1A7D for <v6ops@ietf.org>; Thu, 26 Mar 2015 15:58:22 -0700 (PDT)
Received: (qmail 3389 messnum 13078391 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 26 Mar 2015 22:58:21 -0000
Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail02.svc.cra.dublin.eircom.net (qp 3389) with SMTP; 26 Mar 2015 22:58:21 -0000
Received: from [192.168.1.1] ([86.43.35.194]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 8NyH1q00R4BK5ly01NyMAX; Thu, 26 Mar 2015 22:58:21 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C637D70-7B69-4D4D-B320-9487ED4F03BD"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ross Chandler <ross@eircom.net>
In-Reply-To: <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com>
Date: Thu, 26 Mar 2015 22:59:15 +0000
Message-Id: <8FBFF2D9-FE90-4B69-BFF7-0E3292C6F741@eircom.net>
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>
To: James Woodyatt <jhw@nestlabs.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/8M2Y3CxGRgT2q1C_11BlTSpSzfE>
Cc: 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: Thu, 26 Mar 2015 22:58:25 -0000

> On 26 Mar 2015, at 22:23, James Woodyatt <jhw@nestlabs.com> wrote:
> 
> 
> I sympathize with your position, Lorenzo, I really do. Nevertheless, I also hope that Apple continues to resist the pressure it must be experiencing today to bring 464XLAT to iOS and OS X. Let me explain why.
> 
> 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.

IPv6-only+NAT64 networks are not deployed by ISPs. Without the CLAT the only option is IPv4+IPv6. There’s roughly the same low incentive to fix IPv4 literals with IPv4+IPv6 as with 464xlat.

That doesn’t makes sense as Apple’s motivation for not yet supporting 464xlat. It  just harms IPv6 deployment. 


Ross