Subject: Re: ULA (was Re: ARIN Board Advises Internet Community on Migration to IPv6)

From: Fred Baker <[email-masked]>
Date: Tue, 22 May 2007 15:20:34 -0700

On May 22, 2007, at 2:56 PM, Jason Schiller wrote:
> 3. RIRs are only giving out one aggregate per org as aggregation is  
> important.
>
> I was co-auther of the ARIN micro-allocation policy to allow a  
> second aggregate for an org, under very strict conditions, one of  
> which was that the justification to get it was that it would not be  
> routed.
>
>>> 3. Get the RIR to give out more than one allocation per org.
>>
>> A centrally-managed ULA differs from a centrally managed prefix of  
>> any other type in a pretty small way - it matches a certain  
>> filter. In any other sense, it is a second allocation to the  
>> administration in question, nothing more and nothing less.

So this is where I get stuck, at least a bit. A ULA *is* routed -  
within the network that uses it. So is a global prefix. If we choose  
to not advertise a global prefix outside of our domain, it is not  
routed. Ditto a ULA. Both depend on getting the filters right.

So, OK, I can see taking the "centrally managed" branch of ULAs as  
described in 4193 and saying that it is a filter that everyone has  
agreed to, and would have to be explicitly overridden in cases when  
one wants a ULA to cross administrative boundaries. It still requires  
the filter to be right. It just seems that you and your peer might  
possibly be more likely to back each other up with "don't advertise"  
and "don't accept" filters to handle the error cases.

Looking forward to the I-D, especially if someone wants this on the  
July agenda. Call me a Nazi, I want an I-D for anything on the agenda.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 May 2007 10:17:18 +0200

On 2007-05-23 00:20, Fred Baker wrote:
>> I was co-auther of the ARIN micro-allocation policy to allow a second 
>> aggregate for an org, under very strict conditions, one of which was 
>> that the justification to get it was that it would not be routed.
>>
>>> any other type in a pretty small way - it matches a certain filter. 
>>> In any other sense, it is a second allocation to the administration 
>>> in question, nothing more and nothing less.
> 
> So this is where I get stuck, at least a bit. A ULA *is* routed - within 
> the network that uses it. So is a global prefix. If we choose to not 
> advertise a global prefix outside of our domain, it is not routed. Ditto 
> a ULA. Both depend on getting the filters right.

With the difference that ULAs should be filtered by default
in shipping products, IMHO. So in a sense they are operationally
fail-safe, whereas regular prefixes are fail-dangerous.

Certainly, ULAs have no magic properties; they are simply unique,
unlike the old site-locals, and hence can survive network merges
and the like.

     Brian

> agreed to, and would have to be explicitly overridden in cases when one 
> wants a ULA to cross administrative boundaries. It still requires the 
> filter to be right. It just seems that you and your peer might possibly 
> be more likely to back each other up with "don't advertise" and "don't 
> accept" filters to handle the error cases.
> 
> Looking forward to the I-D, especially if someone wants this on the July 
> agenda. Call me a Nazi, I want an I-D for anything on the agenda.
> 
> 

-- 
NEW: Preferred email for non-IBM matters: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 24 May 2007 16:38:23 -0700

On May 23, 2007, at 1:17 AM, Brian E Carpenter wrote:
> With the difference that ULAs should be filtered by default in  
> shipping products, IMHO.

there is a fundamental problem with that. Shipping products don't  
generally *change* their customer's configurations. Since BGP  
filtering is something that is set up a little differently every time  
a BGP peering relationship is established, I would be very hesitant  
to presume to add something that changed an existing filter designed  
by that administration.

As far as Cisco products go, Cisco route maps, like its ACLs, refuse  
what they don't explicitly allow. "permit" means to include something  
in what one will send or believe on receipt, and deny is the  
opposite. So a typical configuration says something like

      route-map <map name> permit
	match <this set of prefixes>
	match <that set of prefixes>
	...
[default] deny <everything else>

That would preclude the ULA because it is not listed in the contract  
between two companies and is therefore not listed as something that  
would be permitted - not because it is a ULA, but because it is not  
in the [addendum to the] contract. This breaks down between two  
larger networks, where such a list becomes impractical. In such  
cases, it becomes a multistep procedure - multiple route maps with  
the same name are supplied successively to a prefix until one of them  
matches it, at which point we know whether to use it or not, or we  
run out, in which case we don't.

      route-map <map name> permit 1
	match <this specific thing>
	match <that specific thing>
	...
      route-map <map name> deny 2
	match <this more general thing>
	match <that more general thing>
	...
      route-map <map name> permit 3
         match <everything else>
[default] deny <everything else>

One never actually gets to the default case because it is explicitly  
overridden. Clearly, in such a case one wants to permit zero or more  
mutually agreed ULAs, and then deny ULAs as a class. One of the  
things the "deny" route map wants to do is deny ULAs as a class,  
along with various bogon prefixes, prefixes longer than a certain  
length, and so on.

In SoBGP there is a cute side-effect that could be brought into play.  
If SoBGP is used to preclude advertisements that aren't authorized by  
the relevant registry, and ULAs aren't listed as authorized, ULAs  
will be precluded. So will global prefixes assigned by the RIR but  
tagged as "unroutable" if the registry chooses to list such in a  
separate list that SoBGP doesn't look at.

At any rate, I don't think the products should be doing classful  
things on prefixes. IPv6 operates under CIDR rules, not classful  
rules. The fact that it is a ULA is guidance to the guy setting up  
the filters, not something the product should slip in sideways when  
he's not looking and screw up the filter he wrote.