[ppml] draft-ietf-ipv6-ula-central-02.txt use cases

Scott Leibrand sleibrand at internap.com
Wed Jun 27 18:32:19 EDT 2007


Stephen Sprunk wrote:
> Thus spake "Scott Leibrand" <sleibrand at internap.com>
>>
>> I'm not sure this is a digression.  What you're describing is
>> exactly what I think ULA-C should be: a well-known block (that
>> DFZ operators would filter announcements from) from which PI
>> assignments can be made without the restrictions required on
>> public PI space to avoid routing table bloat.
>
> If this is what we mean by "private PI", then I'm against that too. 
> Dressing up ULA-C with a different prefix and name but retaining all 
> of the operational stupidity doesn't solve any problems.    A turd by 
> any other name smells just as foul.
>
> If we want to issue address space to folks for "private" use, it needs 
> to be out of the same block(s) that the RIRs use to allocate space for 
> "public" use, because sooner or later those "private" networks are 
> going to end up being publicly routed.

Then why aren't we routing 10/8 yet?  And what about ULA-L?  Does that 
need to be abolished as well?  If private space is indistinguishable (by 
routers) from public space, then such space will indeed end up being 
routed.  But if I can simply add "deny FC00::/7" to my bogon filter, 
then I need never see such routes.
>
> If we are concerned that giving "real" PI space to every org that asks 
> for it will result in the immediate death of the DFZ, then there needs 
> to be some sort of tag attached to blocks that says whether or not the 
> registrant has met whatever the current rules are for deserving a 
> routing slot.  If routing certificates ever take off, they could 
> contain a flag that gives the current public routability status, or 
> the RIR could just not issue a certificate at all if someone hasn't 
> met the bar.  That's an entirely separate matter from whether or not 
> they get addresses.

I agree with you that such a model would be a good one for a future 
Internet where routing certificates or something similar have been 
widely adopted.

In today's world, the tools available to operators on currently-deployed 
routers allow filtering out well-known bogon prefixes (like FC00::/7) 
and prefix-length filters on non-bogon space.

If we want to allow innovation at the edge of the network, where it 
happens fastest, without waiting for innovation at the core, where it's 
slowest, we need to give as much flexibility as possible to end sites 
without disrupting anything at the core.  At some future date when an 
identifier/locator split protocol has taken hold and the number of 
routes no longer matters, we'll be free to relax the rules on PI space, 
or start accepting routes from FD00::/8.  And in the mean time, small 
network operators will have the freedom to innovate without imposing 
their route announcements on anyone else.

-Scott




More information about the ARIN-PPML mailing list