RE: IPv6 traffic stats

"Hallam-Baker, Phillip" <pbaker@verisign.com> Wed, 12 November 2008 16:25 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF20A3A67B6; Wed, 12 Nov 2008 08:25:24 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10B43A67D2 for <ietf@core3.amsl.com>; Wed, 12 Nov 2008 08:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXwxPrt8BFjz for <ietf@core3.amsl.com>; Wed, 12 Nov 2008 08:25:14 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 8F30D3A67B6 for <ietf@ietf.org>; Wed, 12 Nov 2008 08:25:13 -0800 (PST)
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mACG595f020605; Wed, 12 Nov 2008 08:05:09 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2008 08:25:09 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: IPv6 traffic stats
Date: Wed, 12 Nov 2008 08:25:08 -0800
Message-ID: <2788466ED3E31C418E9ACC5C316615572FFB37@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IPv6 traffic stats
Thread-Index: AclErm7Ms+mvW04ESiWkE4uucfQd9AAMfQoZ
References: <08111108201165.2a71d.487911088@oregon.uoregon.edu> <20081111185711.GG1588@nsn.com> <4919ED2F.2020101@alvestrand.no> <f1110c510811111249ud4ee387m2169fb84378ec3f4@mail.gmail.com> <4919FA68.4030803@alvestrand.no> <alpine.LRH.2.00.0811120747470.11163@netcore.fi> <491AAAAB.6000209@alvestrand.no>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Harald Alvestrand <harald@alvestrand.no>, Pekka Savola <pekkas@netcore.fi>
X-OriginalArrivalTime: 12 Nov 2008 16:25:09.0048 (UTC) FILETIME=[3ABCB380:01C944E3]
Cc: tytso@mit.edu, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1603168366=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

It looks to me as if these are developer and interoperability issues that are not going to be addressed of their own accord through regular IETF meetings.
 
I think that the only way we could expect progress here would be to have a series of interop events that involve representatives from all the interested parties - ISPs, O/S, network infrastructure providers, core DNS.
 
And they are going to find a large number of such missing pieces that need to be fed into the standards process. 
 
In this type of situation I think that we have got to expect the standards process to be descriptive rather than normative. Rather than having a group of folk get together to propose what should work we have to have the interop folk tell us what did work.
 
Some parts of this can take part in the regular IETF process but it really is not the type of project that I think is going to be effectively completed unless there is some fairly radical change in the approach. 
 
 
Transition from IPv4 to IPv6 has to be effortless for the end user. We can adopt a HDTV type approach where users are expected to deploy some sort of $50 'converter' box. What we cannot do is to propose an architecture that requires end-users to think about the change.
 
My home network is IPv4. I have many devices that are not IPv6 aware and have zero intention of changing them. The network is behind a NAT because I don't see a business case to pay $10 per network device per month for unique IP addresses. That would be $120 a month for me - if Comcast actually supported it as an option which they do not, they allow up to 4 IPv4 addresses per residential connection.
 
 
The core problem here is that the current Internet 'architecture' requires applications to know rather too much about the internal workings of the network that they are connected to. Everyone now accepts that IPv4 address space is going to be quickly exhausted. What fewer people currently understand is that 16 bit port numbers are no longer a scalable means of protocol description. And 16 bit DNS RRs are no better in that respect either.
 

________________________________

From: ietf-bounces@ietf.org on behalf of Harald Alvestrand
Sent: Wed 11/12/2008 5:06 AM
To: Pekka Savola
Cc: tytso@mit.edu; ietf@ietf.org
Subject: Re: IPv6 traffic stats



Pekka Savola wrote:
> On Tue, 11 Nov 2008, Harald Alvestrand wrote:
>> The correct number from the presentation is 0.238% - only Russia,
>> Ukraine and France have more than 0.5% IPv6.
>>
>> Presentation available from
>> http://rosie.ripe.net/presentations-detail/Thursday/Plenary%2014:00/index.html.
>>
>
> Depends on what you're looking for, but if you are interested in the
> amount of users that have any kind of IPv6 connectivity, this
> undercounts severely because address selection rules on recent OSs
> typically select IPv4 if their connectivity is 6to4 or Teredo.
Pekka,

can you identify the OSes that prefer IPv4 when on 6to4, and pointers to
docs?

Steinar (the guy who did the Google experiment) has tried to dig through
the documentation on both Vista and Linux, and has drawn a blank (Vista
with Teredo doesn't even look up the AAAA record if it has IPv4
connectivity, according to the documentation, so it seems that it will
not use IPv6 to IPv6-only hosts; it will never find the address.)

                Harald

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf