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