Dear Akamai, you got a /32 there not a bunch of /48s - how to break Facebook and annoy lots of users

Brandon Butterworth brandon at
Tue Aug 21 09:39:59 CEST 2012

> > Because we felt getting a /32 from each RIR and splitting as we 
> > please was quicker, easier, and cleaner.  Plus it is completely 
> > within the rules.
> > 
> > Why isn't that a second best option?
> Well, obviously some people aren't too happy about it...

I don't like the lack of classfulness in allocation, but other
RIPE members wanted it this way so I have to accept everything
may be a /48

> As far as *I'm* concerned, you haven't. I'm happy to accept your /48s,
> regardless of which range they come out of. But - it seems to me that by
> using a PI range instead you can placate the more conservative folks
> too, without any real downside.

It doesn't matter, Akamai may change theirs but unless everyone
else does the same we still have to accept /48's in any range
and everyone else may decide they need the same flexibility and
all ask for PI range space.

> Very true! And that is perhaps the single best argument for doing strict
> filtering. Under current RIPE policies, any back-yard LIR can get an
> IPv6 /29

But a larger one can't get a second /32 to separate hosting and enterprise
networks. RIPE say you can deagg so there's no need. So there is little
choice but to make things unfilterable.

> That's 524288 /48s. Next consider the possibility that someone
> will fat finger and leak every single one of those into the DFZ. It will
> be very difficult to automatically distinguish between such a leak and
> your current use of /48s.

If it's OK for one to deagg it's hard to say another shouldn't and
it doesn't matter anyway as unless you put a special filter in to punish
them they will have done it already. 

I'd like to be able to filter defined ranges in a defined way as 
then others may do the same. Thus my space is safer too.


More information about the ipv6-ops mailing list