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

Ca By <cb.list6@gmail.com> Thu, 19 March 2015 21:27 UTC

Return-Path: <cb.list6@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 16EFA1A88A5 for <v6ops@ietfa.amsl.com>; Thu, 19 Mar 2015 14:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.951
X-Spam-Level:
X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 tqvsWJTCUfTr for <v6ops@ietfa.amsl.com>; Thu, 19 Mar 2015 14:27:11 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 EEF851A1B92 for <v6ops@ietf.org>; Thu, 19 Mar 2015 14:27:10 -0700 (PDT)
Received: by wibdy8 with SMTP id dy8so1714418wib.0 for <v6ops@ietf.org>; Thu, 19 Mar 2015 14:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Zab9twaF4B2zLkcyq80GRkJqtL1nC/60xcdxUQyT1no=; b=bgH6qP9LRx1Z7fyIdsrP76mYb4WVqdL4dfJDOyDQWZRY3A+Ob0LcPSPChO4XG4k4oL ZiZiJiQygTHQgKXUOtpCENjnIrurCTGsnJz5f8rA313lpA8gW1P/k+QGcYIG8ed2diuf y5xBhn7/ogjcW9gDFbO9HXlqcmAiXVvq1gMIjGpU+cT1uDpPnvGSGFzdQ5Cjs6++T1La myqdZOYEXdGkT+dGZg6fZBYdeqnIvNgJTzexq2gYKXpmWsrj6i2ozp0wUqTsJvfYrH6P RAlrFCMLd7LU+9HGE69pCuFhP2IvS9PvsCeJjp5flhw9W0U7s+UXBKVLpeIM4oSooc5N PBuw==
MIME-Version: 1.0
X-Received: by 10.194.89.195 with SMTP id bq3mr132700579wjb.123.1426800429746; Thu, 19 Mar 2015 14:27:09 -0700 (PDT)
Received: by 10.194.164.2 with HTTP; Thu, 19 Mar 2015 14:27:09 -0700 (PDT)
Date: Thu, 19 Mar 2015 14:27:09 -0700
Message-ID: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: IPv6 Ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="089e010d833cc7d1b50511aadc91"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/HXELOiwWbwshcdWAf4jDkFwyXq0>
Subject: [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, 19 Mar 2015 21:27:16 -0000

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