Dear Akamai, you got a /32 there not a bunch of /48s - how to break Facebook and annoy lots of users
gert at space.net
Tue Aug 21 13:10:29 CEST 2012
On Tue, Aug 21, 2012 at 11:46:29AM +0200, Tore Anderson wrote:
> > Oh, that's quite easy. Look at the route6: objects. Accidential leaks
> > won't have any...
> Sure, but do you *really* filter every single route you receive from
> your upstreams based on route objects? If so, hats off to you sir - I
> only do it for my peers, and even that is enough of a maintenance burden.
I don't (and while it could be done today, it would indeed be cumbersome).
What I think is a clear MUST here is "filter your downstreams by published
routing policy". Filtering peers is less clear (some really announce a
lot of prefixes), and filtering upstreams is not really practical with
OTOH, the IRRDB data sources could be used with the mechanisms built
into the router OSes for RPKI validation ("gather data on separate host,
compile list of prefix/origin AS, ship in compact representation to
router for verification use") to actually *do* upstream prefix
verification. Or use RPKI :-)
> Unless I happened to peer directly with the leaking network, my routers
> will not be able to distinguish between the leaked routes and more
> legitimate /48 PA breakouts like Akamai's.
True. My hope is on the upstream networks involved...
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120821/25828c88/attachment.bin
More information about the ipv6-ops