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

[Jeroen Massar]

On 2012-08-20 19:45, Nick Hilliard wrote:
> On 20/08/2012 17:42, Jeroen Massar wrote:
>> Most of those are out of PA space that is announced inside the ISP that
>> that prefix is living in and thus which do not need to be seen in the
>> rest of the DFZ as they come out of a PA block.
> 
> 2.16.0.0/13:	53 announcements
> 23.0.0.0/12:	110 announcements
> 23.32.0.0/11:	170 announcements
> 23.64.0.0/14:	54 announcements
> 
> etc, etc, etc.  I got bored at this stage and stopped totting up their
> larger allocations (there are lots more), but that's already nearly half
> the space they announce.  It's PA space, but all allocated to Akamai and
> announced as smaller prefixes.

And likely if you traceroute the space it is located in the same network
as the covering prefix... thus why is the route there?

It is indeed nice and correct to have a separate inetnum there, but the
route is not needed.

> I.e. it's not PA space in the traditional
> sense of all being announced as a single aggregate from a single ASN.  So
> why should Akamai's v6 allocation / assignment policies be different?

Hey, I fully agree, they and others should not have to do that.

PA address space though is not where that is intended for.
PI address space is expected to be chunked up though.

But maybe it is better to have a third one which basically means that
content-providers/CDN/etc that have a large address space can have a big
chunk of address space and then announce more specifics.

The policy, designation and name of the addresses used are the problem here.

>> See above about paying folks to get passed those filters.
> 
> I thought about this for a while and figure that there are two likely
> scenarios for this sort of thing:

Yes, using moniez for this won't scale and especially not due to
scenarios you mentioned where one or the other is going to bite the dust.

[..]
>> And they could of course just use address space which is not meant for
>> de-aggregation...
> 
> You mean, get 800 separate separate PI assignments from the RIRs?  What
> problem is that going to solve other than annoying the LIRs?  Would you be
> happier if Akamai announced 800 /32s instead?

PI's normally come in /48s and even an Akamai would likely be good with
a /48 per location. Those 800 /48's (or heck /40s) could all come out of
the same block, but from a larger block that is meant for it.

Greets,
 Jeroen