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

[cja@daydream.com]

Michael,

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.  The IPv4 swamp of PI /24s was specifically not filtered for this
very reason.

---Cathy

On 4/20/06, Michael.Dillon at btradianz.com <Michael.Dillon at btradianz.com>
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
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060420/38870720/attachment.htm>