IPv6 foot-dragging

Matthew Petach mpetach at netflight.com
Fri May 13 11:42:08 CDT 2011


On Fri, May 13, 2011 at 12:56 AM, Iljitsch van Beijnum
<iljitsch at 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.)




More information about the NANOG mailing list