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

James Woodyatt <jhw@nestlabs.com> Tue, 24 March 2015 22:22 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 F174A1A1B5C for <v6ops@ietfa.amsl.com>; Tue, 24 Mar 2015 15:22:21 -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 T3s3esKVhvAh for <v6ops@ietfa.amsl.com>; Tue, 24 Mar 2015 15:22:20 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 8F9931A1B57 for <v6ops@ietf.org>; Tue, 24 Mar 2015 15:22:20 -0700 (PDT)
Received: by oigv203 with SMTP id v203so6489040oig.3 for <v6ops@ietf.org>; Tue, 24 Mar 2015 15:22:20 -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 :cc:content-type; bh=AHDE6MYWvNxoETni1XZDYTdYWkK5iI6ufnuOSB3pPT8=; b=Ok6wz0zmav6qE0f5ms+cvsLrzyls3EVsGKlocraAR3EClNWMUUGfn3G6xKsb/hZbYE sZrX8lTJq1BFgdFh2wNV5xsWB8+xHBF1IrYdkQ2CzTnxmB7vvLA07XkD8oBKjjbsgUdg l+xMLQx3jme0Qfq5DWajc36H9Rf1ARKqJojC0=
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:cc:content-type; bh=AHDE6MYWvNxoETni1XZDYTdYWkK5iI6ufnuOSB3pPT8=; b=FXNpi4CRSgOI/h3YAVwymas3gwiY9ZzWU5aEpFgV/UtN6YtYpTT1h6PEJC88AbTz/L APwbS4TRBSADAvSlDNcoZ0DXE38P1HxeZaeeZgZEx2vbDT/h2uiXjyITvDas5Ubw7B9X yz2Ofz8gufkTcaRTPy45QOE3xBIIS2xsHIp2aR5LltNnZS6Rrsb+cgZGVuwpibCoBMIu mOeWxZEp+c0T6S5yzSjCML0C8hIloq9g0K+/q9EMd9e7D+VKhpsj1YJKXG5JTvTCxjg/ 8RuOhKQizWqJYpAp5aSMxYy1ui6IxyBXJoWir5jS8qFDTxJrcf2Gz9k3oWspgxg9+88c OxoA==
X-Gm-Message-State: ALoCoQnUkgRi+eGc0gRIpaWvu6D965hE+XWSARPeteCjhfffYePEZcL+cEEf52VGvLPad10rAzYD
MIME-Version: 1.0
X-Received: by 10.182.215.133 with SMTP id oi5mr5018386obc.55.1427235740092; Tue, 24 Mar 2015 15:22:20 -0700 (PDT)
Received: by 10.76.150.2 with HTTP; Tue, 24 Mar 2015 15:22:19 -0700 (PDT)
In-Reply-To: <CAD6AjGTcKgK8W+VB1H5EQpHaYiKVYXqOz_2RS-w_CiTf9kL2CQ@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>
Date: Tue, 24 Mar 2015 17:22:19 -0500
Message-ID: <CADhXe530+OVZrFZVaYh1-zoRDvJhUd0rf4sx6a2nO8SvKmm6zg@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c254344ca3f10512103792
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/PE8TK3AC-O5gODq3KYVq9fnPl4A>
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 22:22:22 -0000

Cameron, Lorenzo—

Lorenzo writes, "I think the real discussion here is whether going from #2
[IPv6 + IPv4/NAT] to #4 [IPv6-ONLY] without passing through #3 [IPv6 +
464XLAT] 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."

My reply: "I don't agree with that characterization of the discussion. A
very large faction of the Internet community remains convinced to this day
that IPv6-ONLY is neither necessary nor even desirable. I'm partially
sympathetic— I see it as desirable in the long term, absolutely, but I
recognize that I don't yet have convincing arguments that it's strictly
necessary, much less necessary to get there this decade. If IPv6-ONLY is
desirable but not actually necessary, as many people still believe, then
the discussion is about whether IPv6-ONLY is more or less desirable than
IPv6 + IPv4/NAT. Can we honestly say we know which of those outcomes is
better? I can't."

Cameron writes, "IPv4 dependence is hurting the internet and allows for
middle-box proliferation."

My reply: "I agree that IPv4 dependency is hurting the Internet, but I also
view 464XLAT as a scheme to prolong the viability of IPv4-only software. I
also don't agree that IPv4 dependence is any more permissive of middlebox
proliferation than IPv6 is permissive of it. From my view, it looks like
IPv6 is at least as permissive as IPv4 and probably more permissive because
the prevalence of NAT in IPv4 makes some middlebox functions more difficult
to deploy. Shorter james. This middlebox comment smells all kinds of wrong
to me."

Cameron also writes, "So, perhaps a BCP from the IETF would make it clear
what is best and what is not-best."

My reply: "It might make 'somewhat less unclear' what IETF thinks is best
vs. non best. I believe it would make very clear that IETF thinks
developing software that depends on IPv4-ONLY programming interfaces is a
best CURRENT practice, which would make it much more difficult— at a
critical juncture in the transition to IPv6— to communicate to developers
that adopting IPv6-aware programming interfaces is important, and I would
feel compelled to object to that."


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