Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive

On 04/20/06 at 9:15am -0600, cja-5C70pOXIL7ZWk0Htik3J/[email protected] <[email protected]> wrote:

> The difference between the historic filters that ISPs imposed is that the
> longer blocks they filtered were also still advertised via shorter aggregate
> CIDR blocks.  This meant that multihomed sites were still reachable although
> not optimally.   If an ISP filters these PI blocks when their routers are
> starting to die, that ISPs customers will not be able to get to these sites
> at all.

*Unless* you replace the filtered PI blocks with a supernet aggregate.
For example, if an ISP in Asia decided they couldn't handle all the ARIN
PI netblocks, they could create a route for the ARIN PI supernet pointed
toward North America and filter all the PI subnets.

If we decide to assign PI space on a non-random basis, we set ourselves up
to be able to do the same thing on less than continental scales *if* it
becomes necessary at some point.  Hopefully that won't be necessary, but
IMO non-random PI assignment is a very cheap and easy emergency
preparedness measure.

-Scott

> The IPv4 swamp of PI /24s was specifically not filtered for this
> very reason.
>
> ---Cathy
>
> On 4/20/06, [email protected] <[email protected]>
> wrote:
> >
> > > I don't support PI space to end-sites.  We have to get rid of the
> > > notion that a random end-site has any business whatsoever in mucking
> > > with the global routing tables, either by making it much larger than
> > > need be or by polluting it with needless dynamicity.
> >
> > PI allocations do not allow prefixes into the global
> > routing table. That is something that ISPs do and it is
> > outside of ARIN's control. Historically, ISPs have filtered
> > prefixes that fell below some arbitrary threshold when it
> > was necessary to protect the viability of their networks.
> > Then, when new technology solved the problems, they eased
> > up on those filters. ARIN's IPv6 PI policy does not inhibit
> > the ability of ISPs to take similar action, if and when they
> > determine that there is a real imminent technical issue with
> > the global routing table. Current analysis shows that because
> > the IPv6 routing table is an order of magnitude smaller than
> > the IPv4 table, there is no current imminent issue. Therefore
> > many of us, me included, feel that it is prudent to release
> > PI IPv6 addresses to give the end users and ISPs the ability
> > to try this out on the real network.
> >
> > > If so, the policy should be such that it minimizes the bad effects of
> > > PI and encourages people to use other solutions if those are viable
> > > for them (unfortunately, the only way to achieve that appears to be
> > > $$$$), in particular (in the rough order of importance):
> > >
> > >   1. Each assignment must be accompanied by a recurring fee (at least
> > > 1000-2000 USD/EUR a year, preferably 5000+).
> >
> > This type of punitive fee is impossible for two reasons. One is
> > that ARIN policies may not specify fees. The other is that
> > punitive fees would be in violation of U.S. restraint of trade
> > legislation. In fact, it is possible that disallowing PI IPv6
> > allocations is, itself, a violation of restraint of trade laws.
> > It is not within ARIN's scope to be an architect of the Internet
> > marketplace. We can only put in place policies which allow
> > that market to develop in a manner that is fair and roughly
> > balances the interests of all parties.
> >
> > I don't believe that 2005-1 is a perfect policy, nevertheless
> > I do support moving forward with 2005-1 as it is currently.
> >
> > --Michael Dillon
> >
> > _______________________________________________
> > PPML mailing list
> > [email protected]
> > http://lists.arin.net/mailman/listinfo/ppml
> >
>

_______________________________________________
PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/ppml

_______________________________________________
global-v6 mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/global-v6