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
- [rrg] Updating hosts RJ Atkinson
- [rrg] ILNP: existing applications & other critiqu… Robin Whittle
- Re: [rrg] ILNP: existing applications & other cri… Shane Amante
- Re: [rrg] ILNP: existing applications & other cri… Robin Whittle
- Re: [rrg] ILNP: existing applications & other cri… Shane Amante
- Re: [rrg] ILNP: existing applications & other cri… Mikael Abrahamsson
- [rrg] Happy Eyeballs RFC6555: app changes so dual… Robin Whittle
- Re: [rrg] Happy Eyeballs RFC6555: app changes so … Shane Amante
- Re: [rrg] Happy Eyeballs RFC6555: app changes so … Robin Whittle
- Re: [rrg] Happy Eyeballs RFC6555: app changes so … Dan Wing