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

[joel jaeggli <[e-mail]>]

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.

> 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?
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>