Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Tue, 12 April 2011 07:31 UTC

Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: v6ops@ietfc.amsl.com
Delivered-To: v6ops@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6CD29E0793 for <v6ops@ietfc.amsl.com>; Tue, 12 Apr 2011 00:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QppwnvolqvE4 for <v6ops@ietfc.amsl.com>; Tue, 12 Apr 2011 00:31:14 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfc.amsl.com (Postfix) with ESMTP id E954EE0784 for <v6ops@ietf.org>; Tue, 12 Apr 2011 00:31:13 -0700 (PDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Apr 2011 00:31:13 -0700
Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 12 Apr 2011 00:31:13 -0700
Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Tue, 12 Apr 2011 00:30:42 -0700
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Tore Anderson <tore.anderson@redpill-linpro.com>
Date: Tue, 12 Apr 2011 00:30:41 -0700
Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question
Thread-Index: Acv3QeLkpukoR3a5Tze0sMAg0cyLpwBoNJtw
Message-ID: <DD1A73D9E9C89144A927C5080F70285A015E3F1E01EC@NA-EXMSG-S702.segroup.winse.corp.microsoft.com>
References: <DD1A73D9E9C89144A927C5080F70285A015E3F1E017D@NA-EXMSG-S702.segroup.winse.corp.microsoft.com> <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no>
In-Reply-To: <1893570575.177029.1302414030186.JavaMail.root@claudius.linpro.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 12 Apr 2011 07:31:16 -0000

Hi Tore,

definitely 6to4 RAs sent by ICS is one of the brokenness sources. However it is not the only source, and my question was how many users are there, sitting with 6to4 default route and experiencing IPv6 brokenness, who would be fixed by changing relay A record. 

None of the sources you quoted seems to do such comparison - they are mostly focused on ICS RA issue, which is highly visible to network administrators, but it doesn't automatically mean that issues in other configurations don't exist or less important, even if they are less visible to administrators. 

One could estimate the number of users affected by 6to4 RAs (for example, on IPv4 only networks) and by 6to4 on hosts, based on market shares of OSes and browsers:

If X is a number of hosts worldwide with assigned public IPv4 addresses, an estimate for the number of affected users for Windows 6to4 hosts could be - X * 0.35 (Windows 7 + Vista share) * 0.005 (upper estimate of share of older browsers not following RFC 3484).  

An estimate for the number of affected users on IPv4 networks affected by 6to4 ICS RAs - X * 0.35 (W7 + Vista market share) * MobileICSShare * AvgMachinesPerLAN * (0.06 (upper estimate of share of older versions of some OSes, not following RFC 3484) + 0.35 (Windows 7 + Vista share) * 0.005 ) where MobileICSShare stands for relative share of Windows7+Vista with ICS enabled which are not always at one location, and AvgMachinesPerLAN is how many machines are in an average LAN.

In comparison the common factor X*0.35 can be excluded, and one needs to compare ~0.005 with MobileICSShare * AvgMachinesPerLAN * 0.06. To estimate MobileICSShare * AvgMachinesPerLAN, my guess for AvgMachinesPerLAN is 100-1000. With such numbers, for number of affected users in the two scenarios to be of the same order, MobileICSShare needs to be 10^-4 - 10^-3. 

I don't have good data sources to estimate actual MobileICSShare value, but worldwide 10^-4 - 10^-3 doesn't seem to be completely unreasonable, and number of the affected users in the two scenarios may be of the same order. So if there is any truth in such rough estimate, disabling 6to4 relay record may reduce IPv6 brokenness. How much exactly - I guess only a measurement could show.

Thank you,
Dmitry

-----Original Message-----
From: Tore Anderson [mailto:tore.anderson@redpill-linpro.com] 
Sent: Saturday, April 09, 2011 10:41 PM
To: Dmitry Anipko
Cc: Christopher Palmer; Martin Millnert; Brian E Carpenter; v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Hi Dimitry,

* Dmitry Anipko

> Are there data indicating that overwhelming majority of clients,
> which experience IPv6 brokenness and have 6to4 addresses, are broken
> because they received ICS rogue 6to4 RAs,

There's plenty of empirical evidence. After spending a few minutes
with Google:

https://ow.feide.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf
http://malc.org.uk/6doom
http://ripe61.ripe.net/presentations/162-ripe61.pdf
http://www.rfc-editor.org/rfc/rfc6104.txt
http://www.gossamer-threads.com/lists/nanog/users/139564#139564
http://www.getipv6.info/index.php/Customer_problems_that_could_occur#Internet_Connection_Sharing
http://www.uknof.org.uk/uknof10/Chown-IPv6-campus.pdf
http://www.gossamer-threads.com/lists/nsp/ipv6/28106#28106
http://www.ietf.org/mail-archive/web/72attendees/current/msg00478.html
http://www.ipv6.leeds.ac.uk/Docs/IPv6issues.pdf
http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf
https://ow.feide.no/_media/geantcampus:2011-gn3-na3t4-ipv6-skjesol.pdf
http://www.personal.psu.edu/dvm105/blogs/ipv6/2011/01/rogue-ra-while-shopping-for-sh.html
http://www.apan.net/meetings/Sydney2010/Session/Slides/IPv6/10%20John_Mann_20100210.pdf

I'll stop here, but you'll be able to find many more accounts of
6to4 rogue RAs from ICS causing major operational problems by
using your favourite search engine.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27