Re: IPv6 foot-dragging

[Matthew Petach <mpetach () netflight com>]

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.)