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

James Woodyatt <jhw@nestlabs.com> Fri, 03 April 2015 20:56 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 75ACC1A1B8E for <v6ops@ietfa.amsl.com>; Fri, 3 Apr 2015 13:56:40 -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 0qZeiOvYqBW9 for <v6ops@ietfa.amsl.com>; Fri, 3 Apr 2015 13:56:39 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 2B0ED1A1B65 for <v6ops@ietf.org>; Fri, 3 Apr 2015 13:56:39 -0700 (PDT)
Received: by obbec2 with SMTP id ec2so183467703obb.3 for <v6ops@ietf.org>; Fri, 03 Apr 2015 13:56:38 -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=UmWR7hkFMFYfXL+cQQH/Gn4M13iEsu7166CBtRguHZ0=; b=Xayl8YrQPffyH/icB8QO/D5L+U2aMWToCeSdRwk4L1i3gZwq62Qu4z+pe6a1v+pNf/ RBaR0p7+I3lbQYdbE8XsfKf41ZbwCPfueCfPbSahVEeeWMhhNLRlwYIGCj3mkEUm5D85 Q7LNmok0dJpS+3ti5EHlbUXvW+xzUbx2NK1Ww=
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=UmWR7hkFMFYfXL+cQQH/Gn4M13iEsu7166CBtRguHZ0=; b=d9bHPWFLUYLrW4gKWYhwB4tiu5+MiErDh5oao/NDUX/L1feM3IbWVFfJG/eHpNmj/y t6y4mh2cj7slNnm5hYFebp4H9ZpbXdw3OASqRmlTsiSfAkWEFSbehvnj0agmwtcTR4Wi ZyE0HX1lmu8UEiQ2R094V1ZXs5BpmAdNK/rhYP0qqs04qnTdPLVVk+I/5Dw0C0GGq78/ YKUPyz3p6MZfJScMKpMWOPKt9I9+OUq6j+5H6xmz2YvWwfmE09vT5hlmMcbPdURQ1r5V OPUOUNavn7t0jq84eeoITKMaWo4E+9aEsaP7iLBDTb6yEnXAtFQuXtJwO2l4TUp2fo0j dobA==
X-Gm-Message-State: ALoCoQmz0nCxpcSHEtoxv5QIsO44EjNT9eO9rZlKdOg5mmo5U8vv1VTizy2NmQAg+suVLMQ5uu6q
MIME-Version: 1.0
X-Received: by 10.60.116.102 with SMTP id jv6mr5035708oeb.50.1428094598675; Fri, 03 Apr 2015 13:56:38 -0700 (PDT)
Received: by 10.76.177.229 with HTTP; Fri, 3 Apr 2015 13:56:38 -0700 (PDT)
In-Reply-To: <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> <D1441574.4C168%wesley.george@twcable.com>
Date: Fri, 03 Apr 2015 15:56:38 -0500
Message-ID: <CADhXe51Pvm8=Re9RokaPW9=Ykc+BG0+1L2D5MGz0NtEr=-ehrQ@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="089e0115ef4042981e0512d82f42"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/yEluc0zpxrVsg0Z78KD1qaaD_TM>
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 20:56:40 -0000

On Fri, Apr 3, 2015 at 9:23 AM, George, Wes <wesley.george@twcable.com>
wrote:

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

That analogy *IS* interesting, isn't it? Can you imagine what the reaction
would be if carriers had responded to the introduction of handsets without
support for Flash by insisting that the HTML5 solution for replacing Flash
be available only to handsets that also support Flash programming
interfaces as a translation layer in the platform?

You're simply advocating for pushing this problem and therefore all efforts
> to motivate people to stop using IPv4 literals back onto the carriers [...]
>

I see myself advocating against permitting the carriers to escape
responsibility. As I view it, they snoozed while operating systems people
worked diligently to make dual-stack hosts ready for the transition. Now
they'd like an easy escape— asking for host operating systems and
applications to maintain the transitional state indefinitely, while they
make a clean break to green fields now.

If there is a good and fair reason to shift these burdens from the carriers
onto others, then I'm failing to recognize it. I'm not saying there isn't
one. Just that I don't know what it could be.


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