IETF Logo Mail Archive

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

Lorenzo Colitti <lorenzo@google.com> Sat, 04 April 2015 02:29 UTC

Return-Path: <lorenzo@google.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 E25BE1A88C2 for <v6ops@ietfa.amsl.com>; Fri, 3 Apr 2015 19:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level:
X-Spam-Status: No, score=-3.388 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 0QCkTUEbDSOW for <v6ops@ietfa.amsl.com>; Fri, 3 Apr 2015 19:29:37 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 95F9F1A88BF for <v6ops@ietf.org>; Fri, 3 Apr 2015 19:29:37 -0700 (PDT)
Received: by igblo3 with SMTP id lo3so18446974igb.0 for <v6ops@ietf.org>; Fri, 03 Apr 2015 19:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q5NMopBYl/QRhORWGCJql5Hx8EuCi/gwpTUX5q7bOx4=; b=ltq9rf5SuRKqNU9ts4KXffMqZuTySXkaZT7gyrYuldqnuJowE01YuV+zJ1P7CoHBPl FGH5wkgYs/bLpEmiv+jD/D1AlQjn9UhZI7DghFVw7HlbLx8JZ9xznzuPZ3WxSasrc+49 UU/k9EbnYPbIEu6Z3U02InY/gO4LbrjUzLf1XQJTk4B6+z69dQXOuVyRQw0sL/PnjdL+ KIRNhamM+gOFBc/CnkhoLqszay46n93+WKsl4ZBYYSyv9pHAhlQdkznXIMY3NXS9Yomi POTG4KgMCg46T4y3Olu4fChXCl+s5YlJ7WtRLlAwQRzq4Zl3x4FBzb9gt8HggHXZ9sd3 talA==
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:from:date :message-id:subject:to:cc:content-type; bh=q5NMopBYl/QRhORWGCJql5Hx8EuCi/gwpTUX5q7bOx4=; b=e0C289g9YIgQuHL47K5vkE67wsMokQvMA7iESvsGIEA2AxJzvMN7Gyq6yRGAot3Q/I 0alP/fMn8MtDLee5PUsIOyL6BmnWDZsdhQtvQzHse5AmMukbtRCrpQ5SvZ8Iyl2OkP4w xpnRkqhu3FbfaCncg7ptnXvyCmWGm7Db0l7zZP1JxUBsGNqDNU1LRhkoBM+Jcm/FMynb crRREwpznIf8kNCCQjKKeisawW0M1DMCQpi2VtkXOKtqwRxE5K6sNe1I45u2WmpjdoTR 1nkPDMgdT/6GhC9EtpMHmwwHchtm3SRW1suEjMP1vBsnzuS6w0xxmmtdkIrXW9wN8VFY ImuA==
X-Gm-Message-State: ALoCoQkCIQWn7Os8q2TUNNvKfmIWlzcYu+APjQeXwp+nfy5/eN3ysLxc00ZF0l5hYpeROhC4QEJz
X-Received: by 10.107.46.155 with SMTP id u27mr7573699iou.87.1428114576937; Fri, 03 Apr 2015 19:29:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.195.75 with HTTP; Fri, 3 Apr 2015 19:29:16 -0700 (PDT)
In-Reply-To: <CADhXe50W0e5-k2Xa2GoLx2LBn77aXdzJ7GnEvA=M1RACaj+z6w@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> <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com> <D1441574.4C168%wesley.george@twcable.com> <CAD6AjGQrzoBJrqQfKO0N8Ji=oJ-ZP6Sn88sXf=opJ6bYVmTDZg@mail.gmail.com> <CADhXe51MjVbsW512dSJqFpQUH44ZLazh=gkwD0mWwjw3=wqtUw@mail.gmail.com> <CAKD1Yr01qXwi=dN3Wdv1YPPDqCWG2nHyM=_Dhmh7BD+h6HsEwg@mail.gmail.com> <CADhXe50W0e5-k2Xa2GoLx2LBn77aXdzJ7GnEvA=M1RACaj+z6w@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sat, 04 Apr 2015 11:29:16 +0900
Message-ID: <CAKD1Yr11UwjqGaVue39wGGH6e4FWNhiDTn83oESbwM44YdWjug@mail.gmail.com>
To: James Woodyatt <jhw@nestlabs.com>
Content-Type: multipart/alternative; boundary="001a113ac5b60ec2810512dcd683"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/gAtjclrIuoSg-gn7DfelH-ffDX4>
Cc: "v6ops@ietf.org 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: Sat, 04 Apr 2015 02:29:39 -0000

On Sat, Apr 4, 2015 at 6:15 AM, James Woodyatt <jhw@nestlabs.com> wrote:

> On Fri, Apr 3, 2015 at 3:57 PM, Lorenzo Colitti <lorenzo@google.com>
> wrote:
>
>> what do you purpose as a better alternative?
>>
> I propose that IETF decline the invitation to publish a BCP to the effect
> that host OS implementations should include a CLAT function.
>

Ok, so let me see if we can determine the extent of the disagreement.

Suppose that instead of a BCP that says host OS implementations should
include a CLAT function, we instead had a BCP that says general-purpose
host implementations should *either* include a CLAT function, *or* ensure
that all applications are capable of running on an IPv6-only network. Would
you oppose that?

If so - then how do you see us getting to IPv6-only? Do you see application
developers moving to support IPv6 by themselves, including on legacy apps
that haven't been updated for years, or that can't be updated because they
were sold on CDs? Or do you see network operators removing IPv4 regardless
of whether that breaks their users' applications?

v2.23.0 | Report a Bug | By Email