Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

Owen DeLong <owen@delong.com> Tue, 18 February 2014 03:42 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 6F5771A02FD for <v6ops@ietfa.amsl.com>; Mon, 17 Feb 2014 19:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.539
X-Spam-Level:
X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 TlCX8cIzutDf for <v6ops@ietfa.amsl.com>; Mon, 17 Feb 2014 19:42:30 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC31A02CC for <v6ops@ietf.org>; Mon, 17 Feb 2014 19:42:29 -0800 (PST)
Received: from [10.5.16.25] (adsl-69-228-83-127.dsl.pltn13.pacbell.net [69.228.83.127]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1I3d2Gj031150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 19:39:05 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1I3d2Gj031150
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392694748; bh=PnWfb/RhWJ6MQzXdrTgimScSivI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nepH5w8Phnclg7NLZ3I5ug1o8ibpj8ViuroN8xAJ5ZcplJe3+X+LEOCEMF2z5yyE1 jjdC95S7P6bjpM5286j+VnSSrH5pQjwVQ9rxFXowyAtsvUN9RudhUmyTqUlYTbrSoD 4xeZN198LcywkID9axvDMhHhkx5xYveM1pg0ri/k=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <530242C3.4070108@bogus.com>
Date: Mon, 17 Feb 2014 19:39:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E91E49CA-7BA6-4DA3-B4F3-46BB0F25F8F1@delong.com>
References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <m21tz6javn.wl%randy@psg.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <BD473E46-E382-44E6-B474-A56D074318FA@delong.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com>
To: joel jaeggli <joelja@bogus.com>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 17 Feb 2014 19:39:08 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MT9Q8wg59f30rGplctPvN015fag
Cc: V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt
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: Tue, 18 Feb 2014 03:42:32 -0000

On Feb 17, 2014, at 9:11 AM, joel jaeggli <joelja@bogus.com> wrote:

> On 2/17/14, 8:38 AM, Ted Lemon wrote:
>> On Feb 17, 2014, at 9:35 AM, Owen DeLong <owen@delong.com> wrote:
>>> Cases that propose NPT, NAT, or other translation mechanisms are
>>> examples where it is detrimental.
>> 
>> This is clearly true, but we can't do much about it other than to
>> encourage people to avoid this, and help them to avoid it by giving
>> them alternatives.
>> 
>>> Cases where it ends up getting routed amongst "cooperating" parties
>>> are likely to eventually lead to detrimental usage because the
>>> natural trend is for them to become increasingly routed across more
>>> and more ASNs and eventually to become a form of de facto
>>> registered address space not administered by any structured or
>>> reliable registry and without any form of community based policy
>>> process (such as the current RIRs).
>> 
>> This is a fun doomsday scenario, but we don't have this with RFC 1918
>> addresses today; why would we have it with ULAs tomorrow?
> 
> we route rfc 1918 between cooperating parties today. as noted it
> requires coordination and is painful.
> 
>>  In fact,
>> ULAs fix one of the really big problems with RFC 1918 addresses:
>> there are so few of the latter that when two corporations that use
>> RFC 1918 numbering internally merge, you have a really bad
>> renumbering problem, and wind up doing more NATs than you otherwise
>> would have.
> 
> what consenting adults do within the privacy of their own asns is really
> none of my business.
> 
> If widely deployed in an uncoordinated fashion it becomes toxic for
> globally coordinated use, which precludes owen's scenario. the fact that
> we have 41 bits instead of 23.5 doesn't really obviate that.
> 

I would argue that the current situation with RFC-1918 proves that with
additional bits (it’s 105, not 41), it is, in fact possible for people to do
really bad things which later merge after it is too late.

>> So I think this use case is one where ULAs actually do really well.
>> 
>> Do you have some reason for thinking that your doomsday scenario is
>> likely, or is it sufficient to you that it's possible, and therefore
>> you want to avoid it?

Yes.

Case in point, the observed leakage of RFC-1918 into various parts of the internet,
the deliberate routing of boron space among several cooperating entities that I have
observed over my career (I can’t name names due to NDA, but a very large Telco
is using 100.0.0.0/8 for the VOIP interactions and demanding that their suppliers
route that network with them, for example).

Given the history of what happens with uncoordinated space in IPv4, legitimately or
otherwise, I have no reason to believe that ULA isn’t simply a larger, less inconvenient
opportunity to create a much larger problem of the same form without any of the
inherent drawbacks and limitations which prevented RFC-1918 from getting truly
out of hand.

Owen