Subject: Re: [v6ops] ULA Usage Guide draft requesting for review

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Mar 2013 09:02:51 +0000

On 01/03/2013 03:27, Owen DeLong wrote:
>>> Admittedly, ULA doesn't have that problem, but, neither would a /48 or
>>> /32 or
>>> whatever set aside from GUA for that purpose.
>>>
>>>> ULAs can play a similar role in this case given the devices have no
>>>> global
>>>> connectivity requirement and fit into existing rules which are put on
>>>> the
>>>> perimeter anyway.
>>> They don't fit into existing rules, they need new rules. ULA does not
>>> match
>>> 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional
>>> rule for fc00::/7.
>> I think (opinion alert) most operators will put in rules for ULAs on the
>> perimeter similar to RFC1918.  So if those rules are in place anyway, then
>> it works quite well.  I suspect I have no need to accept ULA routes or
>> traffic from outside the AS, so those rules will be in.  Exceptions (if
>> any) can be managed as exceptions.
> 
> I think that will be true until customer A and customer B want to talk to
> each other's ULAs over provider C and then those rules will get an
> exception added. And then E and F will come along. Pretty soon, the
> ULA rules end up looking like swiss cheese.

There are no miracles. This is exactly the situation with multi-site
enterprise networks today, and this is (I assume) why ISPs will tell
you that their real routing table is considerably larger than the
publicly visible DFZ. Whether the Swiss cheese is composed of fragmented
GUA prefixes or individual ULA prefixes doesn't really matter (that's
why a ULA prefix is technically scoped "global").

   Brian