[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 2007-05-23 00:20, Fred Baker wrote:

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.

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


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.




--
NEW: Preferred email for non-IBM matters: brian.e.carpenter@gmail.com