Mailing List Archive: nsp: ipv6

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

Index | Next | Previous | View Threaded

patrick at ianai

Jul 16, 2012, 10:18 PM

Post #1 of 3 (306 views)
Permalink

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

Everyone:

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.

--
TTFN,
patrick

berni at birkenwald

Jul 16, 2012, 11:10 PM

Post #2 of 3 (281 views)
Permalink

Re: Akamai's 2a02:26f0::/32 [In reply to]

Am 17.07.2012 07:18, schrieb Patrick W. Gilmore:

Hello Patrick,

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

Thank you!

Bernhard

jeroen at unfix

Jul 17, 2012, 1:48 AM

Post #3 of 3 (281 views)
Permalink

Re: Akamai's 2a02:26f0::/32 [In reply to]

On 2012-07-17 07:18, Patrick W. Gilmore wrote:
> Everyone:
>
> First, thanx to Bernhard for bringing this to our attention. The
> 2a02:26f0::/32 "anchor" (as we call it) is supposed to be announced.
[..]
> 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.

Thank you for be open and accepting of other networks policies and
wishes! Rock on!

Greets,
Jeroen

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads