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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 26 May 2014 22:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 3E5A41A02BC for <v6ops@ietfa.amsl.com>; Mon, 26 May 2014 15:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 5V5YU8GhS77Y for <v6ops@ietfa.amsl.com>; Mon, 26 May 2014 15:40:19 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02F51A02B7 for <v6ops@ietf.org>; Mon, 26 May 2014 15:40:19 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id ld10so8099274pab.31 for <v6ops@ietf.org>; Mon, 26 May 2014 15:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/1qnOEViLv2IIVcjJdAlc7sRY4WqAVnWISO7eyLKm40=; b=FCCw6KID6a9PMmSrYhQS9rbocj45XEi7jzuqOxPzFPU5/8MwVZmbwE6DTBhSBTHiIz k7CrWafC55izgCdw2I3rrWVItb0gBl2v332iJ5f/g3SzPvUjq84Dc8RuUlJUpxTCEmVN VuXyn862LNSGJWkKX1qF2SCjJsdCXOz+dSBh7bR1ZYiUwSwa+e1mnI/LBiLovjjXGe66 2zI2BYMe/TizRhNBlRnVEMRXzwT2+5f099Iv0lO6wErlGrc1aoE2vaIS1MfoK4h+Vptk Wv64Z7WqmW2nX0tTVuWyIdevDLlYGHZzBhi7yGzyIVJsOcDFd6stidp2k13Zm4OzSqTf Ke4Q==
X-Received: by 10.68.202.230 with SMTP id kl6mr31612822pbc.55.1401144016838; Mon, 26 May 2014 15:40:16 -0700 (PDT)
Received: from [192.168.178.23] (155.199.69.111.dynamic.snap.net.nz. [111.69.199.155]) by mx.google.com with ESMTPSA id cz3sm19968307pbc.9.2014.05.26.15.40.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 15:40:16 -0700 (PDT)
Message-ID: <5383C2CF.6040205@gmail.com>
Date: Tue, 27 May 2014 10:40:15 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com>
In-Reply-To: <1401141423.52956.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/swDCe-cNK_ONH2-BXlrMceFErPE
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
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: Mon, 26 May 2014 22:40:21 -0000

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.

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