Re: [rrg] ILNP: existing applications & other critiques

Robin Whittle <rw@firstpr.com.au> Tue, 13 November 2012 04:23 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D4821F8870 for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 20:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.111
X-Spam-Level:
X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrVEflOcR0xu for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 20:23:29 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by ietfa.amsl.com (Postfix) with ESMTP id 0117521F83EF for <rrg@irtf.org>; Mon, 12 Nov 2012 20:23:28 -0800 (PST)
Received: from [127.0.0.1] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 4BBFB1759F7; Tue, 13 Nov 2012 15:23:27 +1100 (EST)
Message-ID: <50A1CB11.4050809@firstpr.com.au>
Date: Tue, 13 Nov 2012 15:22:41 +1100
From: Robin Whittle <rw@firstpr.com.au>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <A5F253CD-71F6-49BD-95CC-897F803860F1@gmail.com> <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net>
In-Reply-To: <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: RJ Atkinson <rja.lists@gmail.com>
Subject: Re: [rrg] ILNP: existing applications & other critiques
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2012 04:23:30 -0000

Hi Shane,

Thanks for these links.  The Verizon Wireless slide 14 had no
information on how the IPv6 traffic volume compared with that of IPv4.
Maybe such information was implied in slide 13 but I couldn't clearly
understand it.

Comcast stated that "approximately 6% of the 2012 Olympics served over
YouTube to Comcast customers was over IPv6."  This is a substantial
share of real ordinary user traffic.  I wonder what the impetus for this
was - why didn't the hosts use IPv4?

There will always be IPv4 space available for servers - unless the world
needs a billion or more servers with unique IP addresses, which is not
the case with many websites sharing a single IP address.  That being the
case, as long as mobile devices can be made to work acceptably well
behind IPv4 NAT (maybe this is not the case, but for the foreseeable
future, a unicast IPv6 address is no substitute for a unicast or NATed
IPv4 address), it is hard for me to imagine a commercially compelling
reason for anyone making services available on IPv6.  If there had been
such reasons, there wouldn't be a need for campaigns to improve IPv6
network availability and end-user adoption.

A still more remote development would be anyone making services
available only on IPv6, or in some way better on IPv6 than on IPv4.
That, or the impossibility of mobile and home/office customers being
happy with NATed service, seems to be a pre-requisite for widespread
adoption of IPv6 by end-users who don't run servers - except for one
scenario:  The development of some popular applications which require
true host-to-host communications, especially for mobile devices, which
can't be done with one or the other host behind NAT.  Then, this would
be an impetus for giving such customers (too many customers to
accommodate on their own IPv4 addresses) native IPv6, so each device, or
each of the user's multiple devices, has its own public unicast IP
address.  Such applications are most likely to be intensive real-time
end-user-host to end-user-host communications such as voice, video or
gaming.

With most new developments happening in physically mobile devices, such
applications would need to work smoothly with one or both devices
suddenly getting a whole new /64 and therefore a new IP address.  This
could happen when the device transitions from one base-station to
another (if the base-stations and their controllers have different IP
gateways) - which can happen without the device physically moving at
all.  It could also happen as the device comes into range of one or more
3G/4G/WiFi services come into range - and the ranges can fluctuate
without the device moving.

As far as I know, only TTR mobility can provide this - and it doesn't
require any changes to host stacks or applications (other than the
addition of a TTR tunnelling module alongside or as part of the stack).
 LISP or ILNP would not be able to maintain connectivity in a
sufficiently responsive manner to support any real-time application.
Unless each application handled these mobility problems on its own, I
can't imagine this scenario developing with the current addressing and
routing arrangements, with or without ILNP or LISP.

That's the limit of my current imagination and understanding.

  - Robin