On Fri, May 13, 2011 at 12:56 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 13 mei 2011, at 2:39, Jimmy Hess wrote:
if the user starts obtaining multiple non-aggregable /48s from different sources, or obtains an additional PI allocation later, but keeps using the original /48.
Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place.
The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.
Well, that one particular "someone" should at most be announcing 16 /48s (their deaggregated /44). If they announce a million /48s, they're actively hijacking space from 64,000 other people, and should be dealt with in an appropriate manner as a hijacker. :/ People are conflating two different issues here. RIR policy is not, and never has been, structured to prevent or punish active, realtime hijacking of IP space. The *only* thing that will prevent that, in real-time are techniques like PGBGP or so-BGP. Not RIR policies. Now, RIR policies may provide guidelines on what policies you may use to configure your BGBGP or soBGP rules; but the enforcement and protection side is up to you as an ISP, not up to the RIR. I have always been, and will continue to be, adamantly opposed to the idea of the RIRs taking on the role of the "routing table" and "forwarding table" police. :( Matt (as a side note--in order to have your "million /48s" table explosion happen through *legitimate* holders of space deaggregating, it would require 64K individual choices to deaggregate in order to have that happen; we don't even have that many ASNs out there yet. I'm not losing sleep over that at this point.)