Re: [info@arin.net: [arin-announce] ARIN Board Advises Internet Community on Migration to IPv6]

[bill fumerola <billf@mu.org>]

[ i'm /not/ part of the angry mob :) ]

On Mon, May 21, 2007 at 12:35:56PM -0700, Fred Baker wrote:
> On May 21, 2007, at 11:40 AM, bill fumerola wrote:
> >that angry mob you see in the distance is the arin-ppml mailing  
> >list heading over to v6ops to discuss ULA-central.
> 
> Maybe you could fill me in on why it is an "angry" mob? v6ops has not  
> been asked to be involved in the discussion, and has not prevented it  
> from happening. v6ops didn't define the ULA - ipng did. To my  
> knowledge, the operational community has not even seen fit to post  
> their proposal where v6ops can see it, notwithstanding the fact that  
> I have invited them to do so and to use v6ops@ to discuss it. Why  
> would they be angry with us?

they're angry but not to my knowledge at v6ops.

some are angry at folks trying to run around IETF process by submitting
proposals direct to the RIRs.

some are angry at ipng for not giving more guidance on how ULA Central
should be managed.

some are angry that there's no form to fill out RIGHT NOW GIMME GIMME
so they can get their own chunk of ULA-C space.

> Speaking strictly for myself, I would ask a few questions. One is why  
> one wants to have central allocation of a local address. Not that I  
> am opposed to having it (RFC 4193 clearly sets aside part of the  
> address space for such), but I would like to understand the argument.  

well, i think by creating two seperate spaces in RFC4193:3.2 and leaving
it open for future interpretation, people are going to crave direction
if they actually have a use for the space or not. which is why we see
policy proposals in the RIRs on how to manage the space before the space
has really even been defined.

> Related is how a centrally-managed unique global address differs from  
> a centrally-managed unique local address; they both look centrally- 
> managed and unique to me. If the argument is that BGP will not  
> advertise and will not accept a peer's advertisement of a ULA, that  
> is true if and only if the appropriate filters are in place, so the  
> locality of the address seems pretty similar. One still needs to have  
> correct filters. 

companies merge and partner and connect networks together on vague 'site'
lines. maybe some folks worry about colliding (though they shouldn't).

i think that a lot of this has to do with people wanting a backdoor
around PI unicast space. if it's registered somewhere official i can
point to, i can convince someone to route it on my behalf. regardless
of what 4193 says about global routability. note: i'm not supporting
this sort of subversion, but i think it's one way of looking at it.

> The third is why this needs to be a managed space  
> per se. If the desire is for a space that can be used within an ISP  
> network and is guaranteed to not overlap that of any routing peer,  
> placing the 32 bit AS number into the upper bits of the "Global ID"  
> gives each provider a /40 to play with, with no effort on the IANA's  
> part. Why not just do so?

this seems like the most reasonable way of distributing ULA that i've
read. apologies if that idea has been around for a while and i'm only
now just hearing it.

if it weren't for the non-routability requirement of the ULA space, i
think this would solve a lot of people's PI v. sub-allocated concerns.

using the 32 bit AS as a key in the some other unicast allocation pool
instantly gives anyone with an AS an allocation. that seems like a nice
way to kickstart PI space. albiet it does get in the way of the RIRs
ability to charge for the unicast space IANA has already assigned them,
but i'm not sure how important that is.

apologies if any of my thoughts here are old hat, i'm new to v6ops.

-- bill