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

Erik Kline <ek@google.com> Tue, 14 April 2015 05:31 UTC

Return-Path: <ek@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 645721B33B4 for <v6ops@ietfa.amsl.com>; Mon, 13 Apr 2015 22:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 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, 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 PW4oOlXPM_NN for <v6ops@ietfa.amsl.com>; Mon, 13 Apr 2015 22:31:42 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 0E4601B33B3 for <v6ops@ietf.org>; Mon, 13 Apr 2015 22:31:41 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so218101090qkg.1 for <v6ops@ietf.org>; Mon, 13 Apr 2015 22:31:41 -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=bRky30UkvW1BOtf0e4GaVp30QQH5hJvaZwT/FdH1vuo=; b=BG1ER0cY8Q4FwaZ4WQAiPc9zkFqDAVMIl7VZMf/L+pFddmEqtCZ6Exd8iZ1sC/E00W RMnRsmiPzA3zEn5t7FPcBb3RffN/qSR/PNdry/XaS3mFkwxqM1ea/Q/9nozJobLH6sLz lNB9byYGlS5t7d1JZFlRtMe3FzQOx2xbMrSVAAG0qs0c43zU/VVzyQhDmbkX96y+Eo+p JN+RFUv0HyE3f1MZqXzrewyNWO15khaVYF6n0patQkek69Cak3maz6zXxbtMnLk2uJHM 80OhVKpQZ9+ItA7Ag8ZF8/2+cf6f9oW7buZovM+3BXJktJi4ygdtxmsI8vIR4ihaqQyD YyfA==
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=bRky30UkvW1BOtf0e4GaVp30QQH5hJvaZwT/FdH1vuo=; b=JI8yB3PCibFcpT7BUA1GncIhEiEq7ibjLUKF1meKwGd1jLWZyYKlEKh7nzPE5fLwlZ eoOb8/MeMYOnewRa4fdWTF+O68qpJ9bXAdt1ofKQ2yE4AZL7hNXm6sUieyYrNidXQIwL JNw8hDy5VH0Nbr87yQGZmld26mc/g2XVQ+Us+mlXy26YhKSA2HwPGCpiwPJXaeYrGu6d OiGeh42IYy32E/pJNS13HOJb6DCelbpqTLDSU4diPnBAkkpTo0awgN79f0NaCT2nhJuT QtbAnmWel0idNgg5bOD9XlpLF+htksqEcV8S0qZ+aoWU5HDzyYs795VRtO6rVDMr1AmL Y1Bg==
X-Gm-Message-State: ALoCoQkuNsx7fCSs4lGam7OgnA6vYVL6b2xb+sjjmXSsMYfxaYmzKxsJvu7at17I4TlF56UVLNNW
X-Received: by 10.55.24.215 with SMTP id 84mr37070914qky.8.1428989496880; Mon, 13 Apr 2015 22:31:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Mon, 13 Apr 2015 22:31:16 -0700 (PDT)
In-Reply-To: <CADhXe50zz9EtNtifMh+tN9XT-jKCTJB=vsQ6uG515iddOo7f2Q@mail.gmail.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@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> <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> <CADhXe51BDuPhc8wdKGmRiBfSnrz7PMtqYXaoDO+5cwLx_xW2tw@mail.gmail.com> <55290E26.8080500@cernet.edu.cn> <CADhXe50zz9EtNtifMh+tN9XT-jKCTJB=vsQ6uG515iddOo7f2Q@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Tue, 14 Apr 2015 14:31:16 +0900
Message-ID: <CAAedzxqueoJMooeVWe-4+0Qb0_=dtiCM4kFZKPB-YWNO3O=5_A@mail.gmail.com>
To: James Woodyatt <jhw@nestlabs.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/uC-TZuJnNKxacHgglC3Pg3wmTJ8>
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, 14 Apr 2015 05:31:44 -0000

> From my perspective, deploying a CLAT ubiquitously in host operating systems
> will have two deleterious effects: 1) it will prolong the viability of IPv4
> literals in publicly reachable application services, requiring the
> maintenance of the PLAT service, and the public IPv4 routing that entails,
> over a longer period of transition, possibly indefinitely; and, 2) it will
> slow the transition of applications in your local network to using IPv6
> instead of IPv4, because the IPv4-only legacy interfaces will still be a
> viable, if somewhat impaired, despite your having removed IPv4 routing from
> local subnets.

Regarding "1": sure, fine, IPv4 literals and protocols with embedded
IPv4 addresses will be a thing for a while.  But let's be clear: it
*will* dwindle down to "rotary tone dialing" levels eventually.  So as
long as there's a mechanism that can support them I don't think our
future should be held hostage by them, as it were.

Regarding "2": I think this is not a function of any single network,
but rather the percentage of networks that have native IPv6 with
Carrier Pigeon IPv4.

One reason this whole thing, transition and discussion, is hard, I
would posit, is because we have to move through two or more integrals
to get to the desired end effect.  Allow me to be mathematically
dubious, just to make my point:

    [0a] Assumption: We're talking about IPv6-only networks being
preferred by operators over dualstack networks due to
[perceived|accrued] operational simplicity/cost/$METRIC.

    [0b] Assumption: A "general use" IPv6-only network requires some
form of IPv4 access, e.g. Carrier Pigeon IPv4, until a business
decision can be supported removing it.

These assumptions should be challenged of course, tempered by input
from operators with deployment experience.  My understanding is
something like this is the document actually under discussion (but not
yet drafted)?

    [1] How deployable an IPv6-only network may be is a kind of
integral, with respect to time, of the availability of Carrier Pigeon
IPv4 technologies, with respect to all the OSes on the devices that
might want to be attached to that network.

    [2] The number of deployed IPv6-only networks is a kind of
integral, with respect to time, of the deployable IPv6-only networks
in [1].

    [3] Awareness of native IPv6 versus Carrier Pigeon IPv4
performance problems and other issues is some function of the number
of deployed IPv6-only networks in [2], possibly as simple as a direct
proportionality but maybe also an integral with respect to time.

    [4] The prevalence of fixed/working IPv6-only applications,
websites, et cetera is a kind of integral, with respect to time, of
the awareness in [3].

So in this discussion, I think we're way back around #1 trying to
affect the kind of change in #4, but we have to move through 2 or 3
integrals to get there.

All this is not to say that it's hopeless.  Rather, I think there is
indeed a path here.