Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Tue, 05 November 2013 19:33 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8D721F9E54 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 11:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_51=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvupePpU+Kbz for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 11:33:06 -0800 (PST)
Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with ESMTP id E8DE311E8196 for <v6ops@ietf.org>; Tue, 5 Nov 2013 11:33:02 -0800 (PST)
Received: from [98.139.212.151] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 19:32:59 -0000
Received: from [98.139.212.211] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 19:32:59 -0000
Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 05 Nov 2013 19:32:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 270212.96721.bm@omp1020.mail.bf1.yahoo.com
Received: (qmail 91479 invoked by uid 60001); 5 Nov 2013 19:32:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383679978; bh=dVW5FyeN+5h008dRdV/hRhGEnJbG1z9aV2OElYDcsl4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nTkJFOHs0sJZ3g+/Vxm+BeyXgqK18IY37idyOTOATNG4dnfdiZSJpBMC5dicFrevCnWi7fywUct/AUkeS2O/s20MiJRsJ52ZF623Vxv+AxFaMnEALVbPeQvbaGOdV4Mxc+pHrR5UXWZQPRf6q3jE39P4ml81sz8McFUUZcCVu5g=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sGkQ1+TxJkLAGutiHs7kg4POiO2xX2q7SxMglkHsVTRfxDJFkqGlPeVkYz9lCDxAMomEU1AOB5G/oQwX2wy2jMk1tAtvI/7eEUgnV0Bkc3K5qVkaZ8z3znYc05Go4FoS2i7y61vDHHs8VNyPOkmh+FR4yuCQot7LhTyKky8ArPk=;
X-YMail-OSG: A595SRcVM1mIvlbx_XBZqnOVm90B5OmVcm3rxf.pgZy.r.h pg_eBlNLK.IsHKKgKIbgvrMpHL4aj0bUqYmdlAgvMAWjAZ2WqkB_oaocG1sX 2Sw8c8lzsVR9g9piCKs6jMtWWE6j6fcWh9mdzcNtwXSJcjKJdzKbbls8Bwih K3eGetilLhY9oBdVm0tFDrs5umcL.RolCY20RrjSPuU4332r8eHBYTi1KuEl Eyc4KO4JLCm0wVs.pLPHDsFfr8y0rhGfdRhaLTVc13bGPlRcVpbGgy9cmi5x F32k.tvpKFftmidj8tiDPUJGkqME3xgQdoWklTe0hNSUcoctGPF5dAaaDc2F iPoDGGJGC.1YReSuiJI1g84Ixt873xspsArZ8QH_nr.PQWv55o6xbWzmsNnB rHWORNVw_iTbpiY9I.lrGPWF_O7V0B5Jj_6pPqAxfsuOspG9rsIIFlNnrkiC kmU1Q4L1vpeHVymYPHZuKD5zidh0.50rX.tjoKrmcvb0kmwZrtesTxfcKXvj z07EENBi2qeW0bkSEc.jlZ8HoKwYwk.NlfK.gI6MhaXYGzLrzHcv9zVfQgBM IwW5snkKReoBBF.7zgcY2i1JR8tskJhKF7VY4chLTixSgoWI-
Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 05 Nov 2013 11:32:58 PST
X-Rocket-MIMEInfo: 002.001, Cgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBDaHJpc3RvcGhlciBQYWxtZXIgPENocmlzdG9waGVyLlBhbG1lckBtaWNyb3NvZnQuY29tPgo.VG86IFRpbSBDaG93biA8dGpjQGVjcy5zb3Rvbi5hYy51az47ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFR1ZXNkYXksIDUgTm92ZW1iZXIgMjAxMyAyOjEwIFBNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBVTEEgYW5kIElQdjQgLSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzCj4gCj4KPgoBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.161.596
References: <a2dc12c28a1d4eb28e7da36c959e2e9b@BN1PR03MB171.namprd03.prod.outlook.com> <F5022E7E-5969-4961-8C1F-03A8FD6C8069@ecs.soton.ac.uk> <EMEW3|c7700e679335ec63fa8cc5ca34b52656pA42wx03tjc|ecs.soton.ac.uk|F5022E7E-5969-4961-8C1F-03A8FD6C8069@ecs.soton.ac.uk> <fbfd317f606e47fb8666f45cfe8ce7df@BN1PR03MB171.namprd03.prod.outlook.com>
Message-ID: <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com>
Date: Tue, 5 Nov 2013 11:32:58 -0800 (PST)
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Christopher Palmer <Christopher.Palmer@microsoft.com>, Tim Chown <tjc@ecs.soton.ac.uk>, "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <fbfd317f606e47fb8666f45cfe8ce7df@BN1PR03MB171.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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, 05 Nov 2013 19:33:11 -0000


>________________________________
> From: Christopher Palmer <Christopher.Palmer@microsoft.com>
>To: Tim Chown <tjc@ecs.soton.ac.uk>uk>; "v6ops@ietf.org" <v6ops@ietf.org> 
>Sent: Tuesday, 5 November 2013 2:10 PM
>Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
> 
>
>
>The majority of in-the-wild hosts are running 3484, so as an operational document I think it’s reasonable to discuss the issue as it exists with those machines. 
> 
>Even with 6724 – hosts configured as described in 3.3 may still attempt a ULA -> Native IPv6 connection. That connection will just not be preferred over IPv4 -> IPv4. 
> 
>I’d argue that’s still non-ideal. If the enterprise hosts in question do not have access to the IPv6 Internet, they should not be configured with a default route – thus they would *never* attempt connectivity.
> 

Even if the hosts do have a default route, the network shouldn't (or at some point shouldn't). At that point, the router should generate an ICMPv6 Destination Unreachable, which will cause the host to switch to IPv4.

I tested this a few years ago and the switch over was both sub-second and not noticeable (under Linux with Firefox and/or Chrome).

I think where people might be thinking this is a bigger issue an it is is because there was one particular IPv6 CPE that didn't generate ICMP Destination Unreachables when it didn't have IPv6 Internet connectivity. This showed up around the time of RFC6204 being finalised, and I think people didn't completely realise it was an implementation issue, rather than a flaw in IPv6 operation.


One thing that could influence this switch over performance is ICMPv6 Destination Unreachable rate limiting on the originating router. Assuming for the moment that ICMPv6 behaviour is the same as ICMPv4s in this regard, it might be worth either advising to raise the rate specifically for ICMPv6 Destination Unreachables, and perhaps revising the ICMPv6 RFCs to have a higher rate specifically for ICMPv6 Destination Unreachables.

ICMPv6 Destination Unreachables are fundamentally unreliable though, which is why I think the happy-eyeballs approach is much better, and should be used in more applications. I really agree with Fred Baker's draft:


Happier Eyeballs
http://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html



Regards,
Mark.


>Overprovisioning effective IPv6 connectivity is a painful topic.
>From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tim Chown
>Sent: Monday, November 4, 2013 6:59 PM
>To: v6ops@ietf.org
>Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
> 
>The 3484’s in that chunk of text should be 6724’s.
> 
>Tim
> 
>On 5 Nov 2013, at 02:50, Christopher Palmer <Christopher.Palmer@microsoft.com> wrote:
>
>
>
>Section 3.3 of the draft:
>> 
>>“  As described in section 2.2.2 of [RFC5220], when an enterprise has
>>   IPv4 Internet connectivity but does not yet have IPv6 Internet
>>   connectivity, then the enterprise chose ULA for site-local IPv6
>>   connectivity. Each employee host will have both an IPv4 global or
>>   private address and a ULA. Here, when this host tries to connect to
>>   an outside node that has registered both A and AAAA records in the
>> 
>>   DNS, the host will choose AAAA as the destination address and the ULA
>>   for the source address according to the IPv6 preference of the
>>   default address selection policy [RFC3484]. This will clearly result
>>   in a connection failure.”
>> 
>>This is only true if the ULA is configured on a host that also has a default route The enterprise can avoid any issues by simply configuring a scoped route on hosts (say, only for the ULA prefix). If a network does not provide connectivity to the IPv6 Internet, it should not advertise ::/0.
>> 
>>I think it’s useful to discuss that configuration route, which is possible today with a vast majority of hosts and just works. 
>> 
>>Modifying the prefix policy table is not suitable at scale. And the DNS preference logic alluded to in section 3.3 is highly ambiguous. 
>>_______________________________________________
>>v6ops mailing list
>>v6ops@ietf.org
>>https://www.ietf.org/mailman/listinfo/v6ops
> 
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>