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

[Owen DeLong <[e-mail]>]

On Feb 17, 2014, at 9:11 AM, joel jaeggli <[e-mail]> wrote:

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