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

Owen DeLong <owen@delong.com> Fri, 13 November 2015 01:10 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 E49C21B3BFE for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 17:10:41 -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 5uZBs7vLcnkQ for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 17:10:40 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id CDB651B3B9D for <v6ops@ietf.org>; Thu, 12 Nov 2015 17:10:39 -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 tAD18bYv014088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Nov 2015 17:08:37 -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: <20151113005106.6B9023C9A578@rock.dv.isc.org>
Date: Thu, 12 Nov 2015 17:08:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E70736D-3FB2-44DA-BC45-9CFF327CBE4E@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> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com> <20151112225306.BBA8A3C99209@rock.dv.isc.org> <EAE6F2BA-2F1F-4DD2-B2A3-4E6F7852AB95@delong.com> <20151113005106.6B9023C9A578@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ui9cbu58ll3PwXScLW7Ue-z7hVM>
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: Fri, 13 Nov 2015 01:10:42 -0000

>> This is actually a lower likelihood of collision than I get with ULA.
>> 
>> True, if I chose something within 2000::/3, I know I’m likely to collide
>> with some
>> unknown thing that expects their addresses to be globally unique.
>> 
>> Also true that at some future date, my f3fe:: address may come to collide
>> with
>> some future IETF decision at which point I _MAY_ have to remove the
>> prefix.
> 
> So you just want a random free for all.  Guess what it costs to clean
> up the mess that produces.  We are going through the process of dealing
> with the mess of people thinking that the DNS root was a free for all
> despite it not being one.

No, not advocating doing this, just pointing out that it has little difference
from ULA.

>>> Additionally we have deployed technology for nodes to update their
>>> addresses in the DNS which deals with most of the renumber problem.
>> 
>> Not sure how this is relevant, but whatever.
> 
> Then you are not @#$!# paying attention.

Sure I am. The fact that I don’t agree with you and don’t share your perspective
doesn’t mean I’m not paying attention.

>>> 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.
>> 
>> Again, not sure how this is relevant to the utility (or lack thereof) for
>> ULA.
>> 
>>>>> 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.
>> 
>> Why? There are circumstances where the border router may actually intend
>> to exchange packets with some other person using that same ULA prefix.
> 
> And border routers can actually talk to two or more sites using the
> same ULA prefix today.  This isn't rocket science.  The api's to
> do this exist and are in use.  It just takes a little care.  The
> concept of the site boundary being through the middle of a box and
> the same prefixes being in use on multiple sites has been part of
> IPv6 from just about the very begining.  If your border router can't
> handle this file a bug report because it is broken.
> 
> Now if you want to route between ULA's using the same prefix then
> you have problems but it is easy to generate new ULA prefixes that
> don't collide and to then stop using the ones that collided.

I didn’t say anything about this… My point was that your claim that a border
router should never forward a ULA packet was patently false and you just
proved my point.

> 
>> ULA is just like RFC-1918 except it provides a greater illusion of
>> utility. It still
>> offers all the same problems, just in a less constrained and
>> (potentially) harder
>> to identify way. It does offer a greater timeline and potential for the
>> creation
>> of time-bomb configurations that work at the time of installation and
>> then break
>> spectacularly at some future date due to the collision of earlier
>> decisions on two
>> networks that later find themselves connected in places far removed from
>> where
>> those decisions were made.
> 
> There is no time bomb.  Only the illusion of a time bomb.

Only if you have fully coordinated ULA which there is no supporting RFC to
provide. Sure there are an assortment of ULA registries out there (which do
happen to in several cases already collide with each other), but short of the
two sites that later collide using the same registry, yes, there is an actual
time bomb.

Owen