Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
Marshall Eubanks <tme-di0mQ0Vl1aRHVuz0we5IsgC/[email protected]> Thu, 20 Apr 2006 11:27:10 -0400
| Newsgroups | gmane.org.apnic.global-v6 |
|---|---|
| Message-ID | <[email protected]> |
On Apr 20, 2006, at 11:15 AM, cja-5C70pOXIL7ZWk0Htik3J/[email protected] 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, [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