Akamai's 2a02:26f0::/32

Patrick W. Gilmore patrick at ianai.net
Tue Jul 17 07:18:07 CEST 2012


First, thanx to Bernhard for bringing this to our attention.  The 2a02:26f0::/32 "anchor" (as we call it) is supposed to be announced.  My lead NetEng guy tells me it was and our upstream must have stopped accepting it.  Of course, we should have been notified by automatic monitoring, and that is being corrected.  We are sorry for any disconnectivity this caused, although the Akamai Mapping System should have noticed any black holes and discontinued use of those nodes.

We are taking this opportunity to move the block physically into RIPE territory (it was being announced from the US), even though that should not matter.  In fact, it is being announced now and has been for several hours, just waiting for IRR updates so upstreams can accept and propagate the prefix.

Let me be clear, and lay to rest any conspiracy theories: This was not intentional.  We have three /32s, it is trivial to verify the other two are being announced.  The fact this one is missing from the global table was simply an error - one that has already been corrected on our side.  Although we would like networks to not filter on PI boundaries, we also believe you should be allowed to run your network as you please.  As such, we announce the aggregate from an Akamai-owned location with paid full transit to attract any wayward packets and get them turned back onto the correct path.

If you have any question about Akamai's v6 policy, feel free to reach out and I'll do my best to answer.


More information about the ipv6-ops mailing list