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

Mark Smith <markzzzsmith@gmail.com> Sat, 14 November 2015 02:40 UTC

Return-Path: <markzzzsmith@gmail.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 E2EFB1B3784 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 18:40:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no
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 dhsb4c1K-EEt for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 18:40:20 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B651B377A for <v6ops@ietf.org>; Fri, 13 Nov 2015 18:40:20 -0800 (PST)
Received: by vkgy188 with SMTP id y188so2704352vkg.1 for <v6ops@ietf.org>; Fri, 13 Nov 2015 18:40:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+dGFOq3gGzlE8PS6AdvPTexQlRjP8CzP6vIF5KZUcSs=; b=CY32kB0d6pKMutyKOQhoM7datpsCSD31MlvjOF5AyohBodjLPhD9HgIgnGH+LEekbS gyS4p4NFqk4ukqQuFsLC3zR+n73+efbV1EbCOiFCRM5vab5v2CW7e8X3VOLLX6CbouHo SeU0j6Mf3BDJKbo2z1T51NmC/AerztsxcXYg2ZBi0ouYyptyGc1yYljrZPA0Bb+qLmu+ oG+vj+Q6hbkclDx//PhxAUrlLS2RK1di9/LLP/lg5Q4NbZIdIMH6oXzSPsI0AgmBpMqx 0kDfDikA/uVOFjkVf0j5YZmpWarv704EqKPSF95sf6PyFcWwCI5EBsmz/cphi5GZvD6D NT6Q==
X-Received: by 10.31.0.197 with SMTP id 188mr1055057vka.102.1447468819211; Fri, 13 Nov 2015 18:40:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.45.198 with HTTP; Fri, 13 Nov 2015 18:39:49 -0800 (PST)
In-Reply-To: <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> <0FF35D7A-5315-4DBF-BC1B-A41EDA007A71@delong.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 14 Nov 2015 13:39:49 +1100
Message-ID: <CAO42Z2xyWnbWhYRNpfFM2eq3aap8jG_yG1NhvB-_xB3X7mybJA@mail.gmail.com>
To: Owen DeLong <owen@delong.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/xdXwE4QupbJy-ajyMrmZpTEK6n8>
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: Sat, 14 Nov 2015 02:40:22 -0000

On 13 Nov 2015 8:43 AM, "Owen DeLong" <owen@delong.com> wrote:
>
>
> > 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.
> >>

<snip>

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

That's stealing space and will most certainly happen if there is no
proper local and free address space to use instead. (I'd have done
that if there weren't site-locals when I first wanted to run up IPv6
at home just to get some experience with it.)

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

Zero cost is what is needed.

You can only charge money for magic numbers because of the magic, not
the numbers. The numbers themselves are free, because anybody can make
them up.

The magic you're buying or renting when you get RIR space is:

- actively managed global uniqueness (although not absolutely
guaranteed, because of the human error factor)

- implicit acceptance of routes for that space by networks that carry
the DFZ route table


The first property is really a requirement and necessity demanded by
the second one.

If people don't need the magic of implicit acceptance in the DFZ, why
should they have to pay for it? That is the unnecessary tax or cost on
enabling IPv6 that you're creating by saying people should be required
to use RIR space, even if they have no intention of having the
corresponding local address space routes in the DFZ.

If people later need the magic of implicit acceptance in the DFZ, they
can get PA or PI, and most importantly add it to their existing ULA
addressed network.

Renumbering is not required to add PA/PI, and that is where IPv6
provides a much better alternative than IPv4 - IPv4 demanded an
exclusive or between PA/PI address space and RFC1918s, and RFC1918s
were perceived to be cheaper and easier for a variety of reasons,
including because a 'magic translation box' could be used between
RFC1918s and PA/PI needed to reach the Internet.

In other words, in IPv4 we're forced into serial address spaces, where
as in IPv6 we have the opportunity for multiple parallel ones.

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

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

It isn't "free PI address space", because it doesn't have the magic
that real PI address space has - implicit acceptance by all carriers
of the DFZ route table.

The only similar properties between PI and ULAs are the
(statistical/managed) global uniqueness.

>         2.      It’s bad because it’s a free end-run around the RIR policy processes.
>

Not if you can't successfully get it globally routed.

Here's the challenge for you. Show us how easy it is for you to get a
ULA of your choosing permanently accepted in all ASes who accept the
DFZ route table, at a cost and effort that is lower than using RIR PI
space instead.

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

I've been running ULAs here at home more than 4 years, both with 6to4
IPv6 connectivity, and for the last 4 years native connectivity. I
haven't seen any issues, or if there have been any, they've been
overcome transparently via such things as Happy Eyeballs. (with the
caveat that all my hosts are fundamentally Linux, although various
distros - Fedora, Android, Chromecast and Chrome OS.)

More recently, anybody who has been running IPv6 on OpenWRT since
BarrierBreaker 14.07, released on 30th of September 2014, has had an
ULA prefix automatically generated and announced to hosts on the LAN
interfaces. Via a few Internet searches, I can't find any reports of
issues relating to OpenWRT and automatic ULAs in the last 2 years.

Regards,
Mark.