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

[Marshall Eubanks]

On Apr 20, 2006, at 11:15 AM, cja at daydream.com wrote:

> 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

I can attest that this was not always the case. I know for a fact  
that some places were at
some times black-holed. (Any time that RPF checks are on this is a  
likelihood if multi-homed sites
are aggregated.)

Regards
Marshall

> 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
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml