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

Ray Hunter <mr.r.a.hunter@gmail.com> Fri, 20 March 2015 12:22 UTC

Return-Path: <mr.r.a.hunter@gmail.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 DDE2F1B2CE4 for <v6ops@ietfa.amsl.com>; Fri, 20 Mar 2015 05:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] 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 XCA-52Ar_X70 for <v6ops@ietfa.amsl.com>; Fri, 20 Mar 2015 05:22:00 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 43E141A897B for <v6ops@ietf.org>; Fri, 20 Mar 2015 05:22:00 -0700 (PDT)
Received: by wibg7 with SMTP id g7so143074369wib.1 for <v6ops@ietf.org>; Fri, 20 Mar 2015 05:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vh+sYschJYpmwVADTrE0FYGB2vqFR9quHJcpoDnK8Bw=; b=HhSuolHZjcbfc3c2h2bM1v0e7an1Ao5Sp6qO+n/pBh1oebsT2Ig3htrMZ86oOJinMB YXPa1rQ27b/RvvDgHd3AS3MllkdaJzLHoxWQSjYtTxjC/fTdGnByREZc80xr0tOOGYq4 z++hYQfoKLrbw/rIBl+A2k4/Qr0p5EN2oyr7VE5q4iuR/loQffhOLUUcaoiMe2IM3Kue DzqO6WcQKG3AaZyhfRTIyr/m/4AP1gkQjLxSpEYtFti+cUn3XyNHXQoxNj3nzNzkqByT HraZcLaoax7uPiPpMA8Ue6RjylFpX92DaCHNwAWjhU/DAZCdDBZ340dsCtwgOMsYeqZG vDNA==
X-Received: by 10.180.76.4 with SMTP id g4mr24478466wiw.43.1426854118989; Fri, 20 Mar 2015 05:21:58 -0700 (PDT)
Received: from [192.168.1.12] (d75067.upc-d.chello.nl. [213.46.75.67]) by mx.google.com with ESMTPSA id y14sm6133176wjr.39.2015.03.20.05.21.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 05:21:58 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-C974AEDA-4439-48AD-B318-90D12A51B1C4"
Mime-Version: 1.0 (1.0)
From: Ray Hunter <mr.r.a.hunter@gmail.com>
X-Mailer: iPad Mail (12D508)
In-Reply-To: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com>
Date: Fri, 20 Mar 2015 13:21:57 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <5E888BC9-03AF-456E-9E12-838B1021F7AA@gmail.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com>
To: Ca By <cb.list6@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/jonuFvAKHBVJc4iHPdDxsufU9W8>
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: Fri, 20 Mar 2015 12:22:03 -0000


> On 19 Mar 2015, at 22:27, Ca By <cb.list6@gmail.com> wrote:
> 
> Hi Folks,
> 
> The point of this message is to discuss the use of IPv4 literals and how this use requires transition solutions such as MAP, DS-Lite, and 464XLAT -- all of which provide local IPv4 socket support to the host.  If the primary operating environment of the host is the "internet", and the "web" is a highly valuable part of the that operating environment, then local IPv4 socket support is still required.
> 
> Specifically, this note builds the case that NAT64/DNS64 alone is still (at this time) not a sufficient solution for consumer Internet access by creating an IPv6-only network as described in https://tools.ietf.org/html/rfc6144#section-2.1
> 
> Empirically, it is commonly know that IPv4 addresses are used on the Internet, despite the guidance in RFC1958 (https://tools.ietf.org/html/rfc1958#section-4).  One common example is enterprise VPN services.
> 
> Quantitatively, it is easy to generate information about how frequently IPv4 address literals are used on the web.
> 
> Several years ago, draft-wing-behave-http-ip-address-literals-02 shared a simple method to gathering the data and reported that 2.38% of the top 1 million web pages have IPv4 literals in their homepage.  I re-ran a similar test this week that yielded 1.39% of the top 1 million web pages having IPv4 literals.   My test, like Dan's, only looks at the HTML on the home page and thus under-counts literals in deeper links or loaded via CSS, XML, or Javascript. 
> 
> Through other manual testing  i have seen catastrophic failure in Amazon's video streaming service with them passing literals in XML.  Facebook passes IPv4 literals in Javascript, but is not impacting the page load.
> 
> I posted IPv4 literals found in the HTML homepage of these 2,220 of the top 100,000 Alexa domains here https://sites.google.com/site/tmoipv6/ipv4literals
> 
> My conclusion is that it is not feasible for a network operator to deploy a purely IPv6-only socket solution.  As has been previously explored, about 20% of the apps in the Google and Apple "app store" cannot function on IPv6-only + NAT64/DNS64.  Even if these "app stores" were policed to force all applications to be Address Family agnostic, it is not possible to police the world wide web or enterprise VPN or SIP Phones.  Any network operator that attempt to do this would have to accept at least 1.39% failure to the total web and perhaps accept failure to some major services (like Amazon streaming).
> 
> I believe we are beyond the point of blaming the world for using IPv4 literals / referrals.  We just need to be realistic that internet service requires IPv4 sockets, and thus RFC6144 #2.1 is not today a consumer grade service.  A wild guess is that it this situation will not meaningfully improve (risk reduced to ~0) for 10+ years.  
> 
> Thoughts?
> 
> CB
> 
If all the smart solutions have failed, what about a dumb one?

Pipe all IPv4 literal requests using IPv6 transport to a big web proxy at the edge of the ISP's IPv6 only cloud. If it's one percent of traffic why isn't that feasible? Assuming the host can detect it has no native IPv4 connectivity and it can perform automatic proxy discovery over IPv6. It works for most enterprises and most enterprise apps....