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

James Woodyatt <jhw@nestlabs.com> Thu, 26 March 2015 22:23 UTC

Return-Path: <jhw@nestlabs.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 DFC591A0282 for <v6ops@ietfa.amsl.com>; Thu, 26 Mar 2015 15:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 sBMFWI5SWmKV for <v6ops@ietfa.amsl.com>; Thu, 26 Mar 2015 15:23:27 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 A2F561A0302 for <v6ops@ietf.org>; Thu, 26 Mar 2015 15:23:26 -0700 (PDT)
Received: by oigz129 with SMTP id z129so17141426oig.1 for <v6ops@ietf.org>; Thu, 26 Mar 2015 15:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=G0R4HSEge5DNsfbK2lyDNVdZtwJzmqSu06zeVq672fw=; b=BTbyjN8PV5pykgAu3Ds52U2dCnUCEgyevsQJSal4QBMJ9aJKcG12xhzm/VDlKqbIGo 4XQAQhbf2nkklfrLfL7ovb26w8AQYoAnEaqTjIqBcuozIxUD0PvgdjCSoSGs3jP8Ro04 Zh17tTSS50wP7rjuirWiNelN9V/xrzKCmeRCo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=G0R4HSEge5DNsfbK2lyDNVdZtwJzmqSu06zeVq672fw=; b=hJQ6FZTa883Bo3LBPE0htirEMaeVR/wB1amU8aSSvaWsar1ZC12Wg7+atkUa+SOKMx rmGuTvLyMW2xvgcqt8ThhtWkSDViQbHOyw5XZRclGFZq1gT5KNwxzIT2ZjAkJuJCkr// X4AIS2x/kk3r1LdQFYdjUSoUwSudTLgWreDN1Ywdo3WeuKx4FbLoaDiHUQPnY+crHZBC 1LKJzHQEqUDYzuGLL7P7H+cUY70nTjbv6EBJyz4bCRjmhiwz78QqlI2uZE7x8sThLlLB oyZBbfu8oMTJw++yTJ4oMJdfyCdUgnENExFUrlKHRmBCt9nk6TbrA8tYRpH9NC0HE/2f LeLA==
X-Gm-Message-State: ALoCoQmrf/9l3IUeseEunzVEa1EvulSuIQAmriJx9KC6ErLiiF5Pu7iO4FiTClLSxMIp0qLUpuvq
MIME-Version: 1.0
X-Received: by 10.182.88.136 with SMTP id bg8mr14007727obb.86.1427408606124; Thu, 26 Mar 2015 15:23:26 -0700 (PDT)
Received: by 10.76.150.2 with HTTP; Thu, 26 Mar 2015 15:23:25 -0700 (PDT)
In-Reply-To: <CAKD1Yr2=zc57+pOA9TFs+0azw0ZR1g67+08T=9eZPHjGXBvgFQ@mail.gmail.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>
Date: Thu, 26 Mar 2015 17:23:25 -0500
Message-ID: <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="089e0111bd76eaf40e05123876f2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/xVjwkuEQuWt7tLTLZGLlnpr9WGc>
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:23:29 -0000

On Thu, Mar 26, 2015 at 11:56 AM, Lorenzo Colitti <lorenzo@google.com>
wrote:

> On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt <jhw@nestlabs.com> wrote:
>
>
Yes, I recognize that entirely shifting the burden of supporting IPv4 onto
>> the operating system developers, into the unforeseeable future, while the
>> network operators get a clean transition to IPv6-only, can seem like a
>> "solution" from certain bell-shaped perspectives, but there is still a
>> world outside that perspective where some of us are trying to make a living.
>>
>
> As someone who does maintain a 464xlat implementation for the purposes of
> supporting IPv4, I don't think it's an unreasonable burden.
>
> It's true that if we have compatibility solutions in place, we might never
> completely get rid of IPv4 until all IPv4-only apps are obsolete. But if
> the cost of maintaining such solutions is low, what's the harm?
>

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.


-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering