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

Tore Anderson <tore@fud.no> Thu, 26 March 2015 18:11 UTC

Return-Path: <tore@fud.no>
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 93BD51A907F for <v6ops@ietfa.amsl.com>; Thu, 26 Mar 2015 11:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J1OS9_FGT96Q for <v6ops@ietfa.amsl.com>; Thu, 26 Mar 2015 11:11:10 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BA81A9074 for <v6ops@ietf.org>; Thu, 26 Mar 2015 11:11:10 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=49370 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1YbCFG-0004Fo-O7; Thu, 26 Mar 2015 19:11:06 +0100
Date: Thu, 26 Mar 2015 19:11:06 +0100
From: Tore Anderson <tore@fud.no>
To: Lorenzo Colitti <lorenzo@google.com>
Message-ID: <20150326191106.42c1a9ac@envy.fud.no>
In-Reply-To: <CAKD1Yr2=zc57+pOA9TFs+0azw0ZR1g67+08T=9eZPHjGXBvgFQ@mail.gmail.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.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>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/7d4L5jtR-U55LQF8_tONIbfnK5s>
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: Thu, 26 Mar 2015 18:11:11 -0000

* Lorenzo Colitti

> On Thu, Mar 26, 2015 at 11:29 AM, James Woodyatt <jhw@nestlabs.com> wrote:
> 
> > Yes, I recognize that entirely shifting the burden of supporting
> > IPv4 onto the operating system developers, into the unforeseeable
> > future, while the network operators get a clean transition to
> > IPv6-only, can seem like a "solution" from certain bell-shaped
> > perspectives, but there is still a world outside that perspective
> > where some of us are trying to make a living.
> 
> As someone who does maintain a 464xlat implementation for the
> purposes of supporting IPv4, I don't think it's an unreasonable
> burden.

Agreed.

There's also the fact that the number of network operators in the world
is many orders of magnitude higher than the number of operating system
vendors, so even if the burden of maintaining a 464XLAT implementation
in an operating system is higher than it is to maintain IPv4 access
service in a network, so when you put it in in a bigger perspective,
the total total burden gets *much* lower if the operating system
vendors help out and allow the network operators to transition to
IPv6-only.

But maybe it doesn't have to be an additional burden for the OS vendors
at all? If they follow our recommendation and kill 6to4 in their
products, then maybe they could perhaps simply reallocate the resources
that previously was spent on supporting 6to4 into supporting 464XLAT...

Tore