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

Lorenzo Colitti <lorenzo@google.com> Tue, 24 March 2015 15:26 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 97BC71A88E2 for <v6ops@ietfa.amsl.com>; Tue, 24 Mar 2015 08:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.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, 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 skO-ZsD6C6C3 for <v6ops@ietfa.amsl.com>; Tue, 24 Mar 2015 08:26:46 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 C1CBA1A88CE for <v6ops@ietf.org>; Tue, 24 Mar 2015 08:26:27 -0700 (PDT)
Received: by igbud6 with SMTP id ud6so75048305igb.1 for <v6ops@ietf.org>; Tue, 24 Mar 2015 08:26:27 -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=nJMftVOdVU1FPL0qGSFxq4snJPeiYotfux/VPZFoY+U=; b=X3s83Db/ZkWrr6aP5HrB2+pgNipntv/qpneNdZG3acJbWIh4gjoVBuebnnFSldJsMo NbtaUYwggQqx3i8ExrrleF/sUxAarclrntnBn2ywgkxzov9WMJjJeMWsOsYucRvgAodr NnP5Hn3Ce2xJNsxtvWl957HLL1k9il0l5b261ESg/b09ByiSdczlsWEoM/1A/dKkfpL8 FIgCYAwToP/rrQbgEzbIfQKzRN7FmbNDgPS51om4ZHnsGnhtKuZhMa2rpGndC+ZFg7VO JaDXFfzrCtL8ugN6RJyYcuAWAqH+PSFkIOtpH2eIYEvj2rjUIADSQqiEGupNdFZmM92G 0bdA==
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=nJMftVOdVU1FPL0qGSFxq4snJPeiYotfux/VPZFoY+U=; b=fT1o4cGP38Z3TgyU5dznXDYDYdsPhCma0b88Go/e/xHNh7xpED10RmhTXT4d7+mJoP 7Q6gDsoKCGRCaR4s0UfHlffhGIjdBdukutRILrjyUa5M5h6Up0dgmWVNcdkOioyy2Mvz 1MqIOsV1DLY+tXTb6pMNjrnYLR0GGc/qGRLhRlvNxBu3u2oMa0JKcpBjeF4Kl0cC7wBN iYW7KBb72mae+arXK0qxhpGhz8qOwm+K0o73rkhX3K5ceL28bSwq8PF3adYhQ8c+ZlTH hd0N+g2tN4Xrt26vivLElq9j8sOk6Bdj7azk9PZxKVTKh8nMkqli0G7/RToPAA9G+LJs j83Q==
X-Gm-Message-State: ALoCoQmG8gcm+NBj6zEEVhRabyp8zRLN8SXLJsBFDxB6gpXbDunCk38rEMpKUzQUe4FHFOCdfQok
X-Received: by 10.107.166.11 with SMTP id p11mr7284191ioe.30.1427210787162; Tue, 24 Mar 2015 08:26:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.195.75 with HTTP; Tue, 24 Mar 2015 08:26:07 -0700 (PDT)
In-Reply-To: <CADhXe51MUB-czeCtpc63E0cHPpb_39Vv0o2Y57EVU2w_makP5Q@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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 24 Mar 2015 10:26:07 -0500
Message-ID: <CAKD1Yr2vvYe+=s2CFsVHMer96UNO_deOc2Na2F9CrXr1jbAj6A@mail.gmail.com>
To: James Woodyatt <jhw@nestlabs.com>
Content-Type: multipart/alternative; boundary=001a1141f104fd2cbc05120a6733
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/qrJQgWF1YwSh7poT4hVpkFN39kE>
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: Tue, 24 Mar 2015 15:26:47 -0000

On Tue, Mar 24, 2015 at 10:06 AM, James Woodyatt <jhw@nestlabs.com> wrote:

> as an endpoint software developer, if every host I want to deploy on has a
> CLAT provided by the system, then I'd observe that my incentives to stop
> writing IPv4-only software logic would evaporate for all practical purposes.
>

I'm not sure that's true. We have four scenarios, in order of decreasing
incentives (from 100% to 0%) to write IPv4-only code:

   1. IPv4-only device
   2. Dual-stack device (native IPv6 and NAT44 or NAT444)
   3. IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat).
   4. IPv6-only device

Based on personal experience, I know that #3 provides less incentives to
write IPv4-only code than #2. I've heard developers say multiple times,
"Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and
high latency too. What do I need to do to fix my code to support IPv6?" In
contrast, #2 is seen as, "well, we still have IPv4 right? So we can just
continue to use it. You say IPv6 has no NAT? But we deal with NAT today,
and it works fine..."

I think the real discussion here is whether going from #2 to #4 without
passing through #3 is possible at all. If you believe that it's possible,
then #2 makes sense. If you believe it's not possible, then the only thing
that makes sense is to do #3 ASAP.

I don't believe that going from #2 to #4 is possible for the industry. It
may be possible for a tightly-controlled, substantial subset of the
industry (e.g., Apple) to do it, but if we did not have a substantial part
of the industry doing #3 already, we'd likely get stuck.

#3 does provide strong advantages over #2 to operators; in some networks,
#2 doesn't actually fix anything because the problem is private IPv4
address exhaustion. For those networks, the only options are #1 or #3 -
which is why those networks are doing 464xlat.