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 mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
