Re: [v6ops] ULA draft revision #2 Regarding isolated networks

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Tue, 27 May 2014 22:37 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB81A0503 for <v6ops@ietfa.amsl.com>; Tue, 27 May 2014 15:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqq2TZYHP4Kl for <v6ops@ietfa.amsl.com>; Tue, 27 May 2014 15:37:48 -0700 (PDT)
Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C771A078B for <v6ops@ietf.org>; Tue, 27 May 2014 15:37:47 -0700 (PDT)
Received: from [98.139.215.143] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2014 22:37:43 -0000
Received: from [98.139.212.216] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2014 22:37:43 -0000
Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 27 May 2014 22:37:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 900508.70283.bm@omp1025.mail.bf1.yahoo.com
Received: (qmail 5371 invoked by uid 60001); 27 May 2014 22:37:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1401230263; bh=IpL9/raHRJiEdrLQRKJqP2Phg8uizWk0xVDBx3rxhI4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YSNnQYu9zw/oogq3860xFygQxXyfrvGBCU9n9NCrfoUTFslMerY0orlHlMxmCKlYZVI23QauF93lo3RXO7Pv2XNcTOty9DWhvzHpHoBaVyoRy5oAbRzlf49884NmW2yUFv3TSlG0fxhSicUMNU/bhLDOeTL1dGkMUNtArTIy86g=
X-YMail-OSG: FOTUDKsVM1mNQ9mbKmjBhaag8TucygRvCTKfytvgbuIWygy LHmUaZWlTTsZUow4aywIL1X8OsENIGjC.EHbRbcjNCrya3b8guQmvXVDPf_h G7cVJwCTFcuv_Hdcrc_Gwc1b.TyeXZeKxdBfaaNzY0VFlQdiHRrS81Kwk.ae uVVlY7_rTe3JKIkc5qjnCST.R7AKORipnanXdA7BJ595N_dS5kn5RthrCPfa zaTuGRlRAats2OD9jSB5AHInKTq9DMZKeyydkX1aNbGXChGGyknWk9h9KVfA aPTQKZZxn26PbKiSGpAnOcZt1Ifmoy47_X7WUk0wAKgvm.rxxYqVMXdVYWNh UgWaldXPkZXwzJWlI7fMYH_JcXNhI7a6ve.W06BPseoHU4HJaB6.7nMfHR7C Lmwfy6lrDtDy1ezAEBP5uAUZJrynnWioK_g4MqT6vn5oOExdhYL6pUwKQhWc ESrgwNgn8cZK3tQqzULzn8eivPUk2eKVNolvdortbdm3gnF81x.c3inpEeqX ltY5WvUj2uibh2ikG4Nh9bK2P24D8JHeaGAjLAHa4qhw9h5KsxnxHIw--
Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Tue, 27 May 2014 15:37:43 PDT
X-Rocket-MIMEInfo: 002.001, SGkgQnJpYW4sCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgdjZvcHMgV0cgPHY2b3BzQGlldGYub3JnPjsgInY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgPHY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4KPiBTZW50OiBUdWUBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.188.663
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com> <5383C2CF.6040205@gmail.com>
Message-ID: <1401230263.69077.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Date: Tue, 27 May 2014 15:37:43 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <5383C2CF.6040205@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_uDpcdpYG5EgG_gojE2fr53UEZI
Cc: v6ops WG <v6ops@ietf.org>, "v6ops-chairs@tools.ietf.org" <v6ops-chairs@tools.ietf.org>
Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 27 May 2014 22:37:48 -0000

Hi Brian,


----- Original Message -----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
> Cc: Liubing (Leo) <leo.liubing@huawei.com>; v6ops WG <v6ops@ietf.org>; "v6ops-chairs@tools.ietf.org" <v6ops-chairs@tools.ietf.org>
> Sent: Tuesday, 27 May 2014 8:40 AM
> Subject: Re: [v6ops] ULA draft revision #2 Regarding isolated networks
> 
> Mark,
> 
> 
> On 27/05/2014 09:57, Mark ZZZ Smith wrote:
> ...
>>>  - "Temporarily isolated" or "Forever isolated". In 
> general, 
>>>  ULAs fit both cases. Whatever it is temporarily or forever, when 
> administrators 
>>>  need some prefixes to be on-demand and free to use, ULAs are good 
> choice. 
>>>  However, for the temporarily isolated cases, the administrator needs to 
> consider 
>>>  once it gets to connected, the hosts might need to be renumbered; or 
> NAT might 
>>>  be involved if renumbering is not acceptable. If renumbering or NAT for 
> some 
>>>  reason is considered as heavy burden, then the administrators need to 
> carefully 
>>>  consider the adoption of ULAs.
>>>   
>> 
>>  This paragraph seems to show a fundamental misunderstanding of IPv6's 
> multi-addressing capabilities. IPv6 supports multiple concurrent addresses (from 
> different prefixes), and can learn new ones or deprecate old ones over time. 
> Attachment to a new network doesn't require renumbering, it requires 
> propagating new prefixes for the hosts to use in addition to their existing 
> ones. Primarily RFC6724 address selection will help the hosts choose the right 
> addresses to use as source and destinations when they have multiple addresses.
> 
> I didn't read it that way. Of course an IPv6 network runs well with
> multiple prefixes, which is why overlapped renumbering is possible.
> 

I think there are a number of reasons I read it that way.

Firstly, to me, the word 'renumber' reads as 'replace the numbers', so renumbering a network involves just that - removing the old numbers and adding new ones. The suggestion of using NAT has been in IPv4 the alternative to 'replacing the numbers', so suggesting that for IPv6 seemed to further support the misunderstanding of IPv6's ability to support multiple concurrent addresses/prefixes/spaces.

The other reason is that I've actually seen a residential CPE try to swap between global addresses and ULAs. I deal with a number of residential IPv6 CPE vendors in around 2009, and one of them had attempted to support ULAs, but had not done a good job of it. When the global prefix went away because the WAN link failed, the CPE would try to both flush the global prefix by setting a 0 valid liftime (or similar, I can't quite recall) and replace it with a ULA in the RAs on the LAN side. When the WAN link came back, it tried to do the opposite. When I provided feedback to this vendor on this issue and others related to their IPv6 implementation, they just ignored it, unlike the other CPE vendors I was dealing with.


Regards,
Mark.





> As Fred Baker once pointed out, the real problem is therefore
> *numbering* a network (i.e. adding a new prefix, regardless of
> whether there are zero or more existing prefixes). The text needs
> to be clear about that, for sure.
> 
>     Brian
>