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

Ted Lemon <ted.lemon@nominum.com> Tue, 27 May 2014 12:52 UTC

Return-Path: <Ted.Lemon@nominum.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 586C71A011D for <v6ops@ietfa.amsl.com>; Tue, 27 May 2014 05:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 NlgrK4spMtcS for <v6ops@ietfa.amsl.com>; Tue, 27 May 2014 05:52:06 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD34A1A011A for <v6ops@ietf.org>; Tue, 27 May 2014 05:52:06 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C4EC21B8038 for <v6ops@ietf.org>; Tue, 27 May 2014 05:52:03 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BAA4A19005C; Tue, 27 May 2014 05:52:03 -0700 (PDT)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 05:52:03 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <m1WpDcc-0000BMC@stereo.hq.phicoh.net>
Date: Tue, 27 May 2014 08:52:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B9A@nkgeml506-mbx.china.huawei.com> <m261ks7xww.wl%randy@psg.com> <53840070.90801@gmail.com> <m2y4xn7wep.wl%randy@psg.com> <53840723.8010606@gmail.com> <CAKD1Yr1O_poMR200sjU=ttRvGaeQRkC1ZfXC0Ok4uQxdq3K=NQ@mail.gmail.com> <m2mwe37tbn.wl%randy@psg.com> <CAKD1Yr2t3-vxuG=iDi4biBNFpJwuzuHgfpB74i_uydWWRV7qZg@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6E02@nkgeml506-mbx.china.huawei.com> <m2fvjv7q4h.wl%randy@psg.com> <m1WpDcc-0000BMC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>
X-Mailer: Apple Mail (2.1878.2)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xYZ9_-O_qH-CHfmpiA_6ArWOYvc
Cc: v6ops WG <v6ops@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: Tue, 27 May 2014 12:52:08 -0000

On May 27, 2014, at 5:24 AM, Philip Homburg <pch-v6ops-3a@u-1.phicoh.com> wrote:
> I don't see why we would need to discuss the foreverness of ULA, when GUAs are not
> at all forever. 

You'd like to think that, and in some circumstances it makes sense.   If my homenet has a ULA, it has it so that local communications can proceed when I don't have an internet connection.   A renumbering event that switches to a new ULA shouldn't be a big deal.

The operational situation that's problematic is the large enterprise scenario, where you have two large enterprises with their own ULAs that merge.   If those ULAs happen to clash, you have to renumber at least one of them.   If they don't clash, you still have to deal with routing them (although I think the split-horizon complexity objection Mikael raised ought to be thought through carefully before being asserted as factual, because I think it can be addressed through routing and not naming).

I wish people wouldn't say "that is evil and must be burned" because it's clearly useful in some real scenarios where there is no better alternative, and hence I think documenting those scenarios and explaining how to do them right (IOW, not wind up with NAT) is a valuable service we can do for the community, which will use them regardless.