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

[joel jaeggli <[e-mail]>]

On 2/17/14, 11:24 AM, Brian E Carpenter wrote:
> On 18/02/2014 06:11, joel jaeggli 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.
> 
> Yes, but it's painful because of ambiguity. With ULAs all you have to
> coordinate is which prefixes are announced between the cooperating
> parties. No coordination is needed for prefix assignment, which
> is the real hassle with RFC 1918.

you're assuming that humans allocate prefixes via the procedures
described in the rfc and that utlization of a sparse address space is
sufficently difuse the you don't have to worry about collisions or that
more specfic routes will win out when someone has the bad taste to use
fc00::/7 or 8 in a routing policy contribution to aggregate and so on.

I kinda have my doubts. operational considerations around internal
aggregation and the human need to group things together in sets as well
as semantic uses (which I continue to assert are a bad idea) are going
to cause these things to be used inside organizations on boundries other
than /48.

My basic assertion is that if ula is widely and obiquitously  employed,
owen's scenario is unlikely to come to pass because the results are
messy and risky. If it isn't widely employed then who cares?

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