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

Mark Andrews <marka@isc.org> Thu, 12 November 2015 22:53 UTC

Return-Path: <marka@isc.org>
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 9534D1B39E3 for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 14:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N00dTKSbCyuI for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 14:53:14 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BB91B39E2 for <v6ops@ietf.org>; Thu, 12 Nov 2015 14:53:14 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 61BF61FCAB3; Thu, 12 Nov 2015 22:53:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7F097160067; Thu, 12 Nov 2015 22:53:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6E38D160084; Thu, 12 Nov 2015 22:53:42 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MnJLOzOunDTM; Thu, 12 Nov 2015 22:53:42 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id F2E85160067; Thu, 12 Nov 2015 22:53:41 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BBA8A3C99209; Fri, 13 Nov 2015 09:53:06 +1100 (EST)
To: Owen DeLong <owen@delong.com>
From: Mark Andrews <marka@isc.org>
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> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>
In-reply-to: Your message of "Thu, 12 Nov 2015 13:42:45 -0800." <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>
Date: Fri, 13 Nov 2015 09:53:06 +1100
Message-Id: <20151112225306.BBA8A3C99209@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/uk1rUGqTW4JNewNJSyuKRiixD1k>
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 22:53:16 -0000

In message <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>, Owen DeLong write
s:
>
> > 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 RIRs
> >> 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 its
> an IPv6 prefix.
>
> Please explain what benefit (b) offers over (d) in such a case. Youre
> going to end up renumbering when you attach to the internet either way.

Renumbering in IPv6 is not the same as renumbering in IPv4.  In
this case you are just adding a prefix.  You don't stop using the
ULA addresses in (b).  For (d) you need to remove the addresses
because you don't know what you are colliding with.

Additionally we have deployed technology for nodes to update their
addresses in the DNS which deals with most of the renumber problem.

A 1 page BCP which says to do what Apple and various router vendors
have been doing for years updating the DNS should be enough to get
the rest to do this.

> > 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.
>
> Im 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 isnt globally unique, its just probably unique for various
> relatively high values of probably depending on how you go about choosing
> your ULA prefix. Were ULA globally unique, youd have the double edge sword
> of:
>
> 	1.	Its good because its free PI address space.
> 	2.	Its bad because its a free end-run around the RIR policy
> processes.

And that matters how?  If you happen to learn a remote ULA address
and actually use it the border router should block the packet and
send back a ICMP administrively prohibited unreachable.  If there
is a ULA prefix collision you still have to match the rest of the
address which is highly unlikely.  Subnet collisions in this case
are likely but not the full address.

> > 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.

Which in practice does not exist.  I've run networks with ULA + PA
locally and *never* seen a issue due to address selection.  Longest
match takes care of that for the older machines (0010 vs 1111).
Newer machines know about ULA so have different address match rules
which deal with ULA address leaks.  Properly configuring the border
routers to return ICMPv6 administrively prohibited for attempts to
send a packet outside the site using a address from the ULA prefix
deals with the rest.

> Owen
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org