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

Philip Homburg <pch-v6ops-3a@u-1.phicoh.com> Wed, 28 May 2014 08:09 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.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 1064C1A03D7 for <v6ops@ietfa.amsl.com>; Wed, 28 May 2014 01:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 gIZio_RoHFmk for <v6ops@ietfa.amsl.com>; Wed, 28 May 2014 01:09:46 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB071A0873 for <v6ops@ietf.org>; Wed, 28 May 2014 01:09:46 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1WpYve-0000BIC; Wed, 28 May 2014 10:09:42 +0200
Message-Id: <m1WpYve-0000BIC@stereo.hq.phicoh.net>
To: v6ops WG <v6ops@ietf.org>
From: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.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> <43BB867C-7BCA-45F6-8ADC-A49B34D6C0DC@nominum.com> <m1WpHrp-0000BQC@stereo.hq.phicoh.net> <9DB71B37-999E-4F7F-A7DA-6B243574E818@nominum.com> <9255C827-9F28-4E4E-9A2E-A678ADFACDAF@steffann.nl> <53854E87.9020500@gmail.com> <m2d2ey4mx4.wl%randy@psg.com> <5385651B.7090604@gmail.com>
In-reply-to: Your message of "Wed, 28 May 2014 16:24:59 +1200 ." <5385651B.7090604@gmail.com>
Date: Wed, 28 May 2014 10:09:42 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I0QMxBC7ojgTcsQRY-MMmQP4Zn0
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: Wed, 28 May 2014 08:09:48 -0000

In your letter dated Wed, 28 May 2014 16:24:59 +1200 you wrote:
>I understand the problem. Users are idiots, including us when we
>act as users. I am not arguing that ULAs will prevent all operational
>problems caused by private addressing. I am only arguing that there will
>be private addressing and that ULAs will cause fewer problems than
>RFC1918-for-IPv6 would.

Maybe we can keep a bit of context around what scenario we are talking about.

Say:
1) Small organisation, doesn't get PI space, has to renumber when moving to a different
   ISP. The IPv4 solution is to use NAT. Maybe we can do better for IPv6. Probably
   collisions of ULA space during a merger are not a big deal.
2) Bigger organisation, does have PI space and has a more or less homogenous network.
   No real need for ULA.
3) Big organisation, wants to have a secret network that only communicates through
   application layer gateways. Should be able to pick a proper ULA if they need one.
   Otherwise, though luck. No real need for ULA. It may make source address selection
   a bit easier, but that is only a small part of the puzzle.

I think the only interesting case is 1). Whether or not we make renumbering easy enough
that they don't do NAT is an open question. A large part of that is in software
configuration: is it possible to store the current prefix in such a way that software
can easily pick it up.