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

Owen DeLong <> Tue, 18 February 2014 03:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6F5771A02FD for <>; Mon, 17 Feb 2014 19:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.539
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TlCX8cIzutDf for <>; Mon, 17 Feb 2014 19:42:30 -0800 (PST)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id A0AC31A02CC for <>; Mon, 17 Feb 2014 19:42:29 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (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 s1I3d2Gj031150
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; 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 <>
In-Reply-To: <>
Date: Mon, 17 Feb 2014 19:39:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <20140217110013.GA31822@mushkin> <> <> <>
To: joel jaeggli <>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( []); Mon, 17 Feb 2014 19:39:08 -0800 (PST)
Cc: V6 Ops List <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Feb 2014 03:42:32 -0000

On Feb 17, 2014, at 9:11 AM, joel jaeggli <> wrote:

> On 2/17/14, 8:38 AM, Ted Lemon wrote:
>> On Feb 17, 2014, at 9:35 AM, Owen DeLong <> 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?


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