Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Owen DeLong <owen@delong.com> Thu, 12 November 2015 21:44 UTC

Return-Path: <owen@delong.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 EBCFE1B374E for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 13:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.111
X-Spam-Level:
X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 bQRa4FvATCqC for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 13:44:49 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3689C1B374A for <v6ops@ietf.org>; Thu, 12 Nov 2015 13:44:48 -0800 (PST)
Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tACLgjoG019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 13:42:46 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAO42Z2y9AnpJC8mWtOaTwg+V4gsskAgbtHrEWmBwHQuvbJ1DSw@mail.gmail.com>
Date: Thu, 12 Nov 2015 13:42:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>
References: <Pine.LNX.4.64.1511050424410.1055@moonbase.nullrouteit.net> <20151106.063106.74659839.sthaug@nethelp.no> <CAO42Z2x3O8A1XKqN3PTcvM=xpF8W_WNSL1rVhHQ4ZY5HbVG=OQ@mail.gmail.com> <20151106.081425.74651560.sthaug@nethelp.no> <6ED54502-C5D1-4D09-877C-FE283E3EF142@delong.com> <CAO42Z2y9AnpJC8mWtOaTwg+V4gsskAgbtHrEWmBwHQuvbJ1DSw@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/56o9eArrTKU9BbbFtS_Ix2VmEK4>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 12 Nov 2015 21:44:51 -0000

> On Nov 12, 2015, at 12:08 , Mark Smith <markzzzsmith@gmail.com> wrote:
> 
> On 13 November 2015 at 05:32, Owen DeLong <owen@delong.com> wrote:
>> 
>>> On Nov 5, 2015, at 23:14 , sthaug@nethelp.no wrote:
>>> 
> <snip.
>> 
>> Please explain exactly what circumstances make it too difficult for any company
>> to acquire a /48 PI as I would consider this a brokenness in the relevant RIR’s
>> policy and would happily work to resolve the issue.
>> 
> 
> This was was in part what I was getting getting at when I said that
> abandoning ULAs would discourage adoption of IPv6.
> 
> If you're building a small network that either currently isn't and may
> never be attached to the Internet, you have 3 choices:
> 
> (a) apply for RIR membership and incur annual RIR costs to get a PI
> /48 and after some time delay, be able to build your IPv6 network
> 
> (b) use $free ULA space, and be able to build your IPv6 network right now
> 
> (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now
> 
> 
> Option (a) has financial costs and time delays that option (b)
> doesn't, and if option (b) doesn't exist, then option (c) is the most
> convenient and timely choice, unless it is essential that IPv6 is
> used. Option (c) being the most convenient, cost effective and timely
> option for if (b) isn't available will actually discourage support for
> IPv6.

(d) use whatever string of {32,48,64} bits you want and pretend it’s
an IPv6 prefix.

Please explain what benefit (b) offers over (d) in such a case. You’re going
to end up renumbering when you attach to the internet either way.

> I think that if (a) was the only choice, it is in effect creating an
> annual tax or license fee on the use of IPv6 technology, because (in
> theory) you wouldn't be able to use IPv6 unless you paid an RIR and
> waited for them to give you your space. Of course, the other choice
> would be that some people would steal space to use instead to build an
> IPv6 network, like the documentation prefix. Absence of a local use
> address space encourages stealing of other address spaces if you don't
> have time to get a proper one or don't have the financial means or
> financial incentive to get some.

I’m all for providing a lower cost alternative to having a legitimate registry
for addresses for smaller users.

> Humans don't incur costs on themselves unless they see or perceive
> some equivalent benefit. Making something available for "free", in
> this case a local yet globally unique network address space,
> significantly lowers the barrier to IPv6 adoption. If you've bought
> the equipment to build your network, and it comes IPv6 enabled for
> "free", you can then immediately build an IPv6 network using ULA
> space.

Except that ULA isn’t globally unique, it’s just “probably unique” for various
relatively high values of “probably” depending on how you go about choosing
your ULA prefix. Were ULA globally unique, you’d have the double edge sword
of:

	1.	It’s good because it’s free PI address space.
	2.	It’s bad because it’s a free end-run around the RIR policy processes.

> If at a later date a ULA addressed network connects to the Internet
> they would add PA or PI space to be able to access external
> destinations, because IPv6 is designed to fully support parallel
> address spaces (i.e., so having ULAs on your network doesn't
> automatically imply using NAT66).

Except for all the problems previously noted in such installations with various
issues around source address selection, etc.

Owen