Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

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

 

 

First page Previous page 1 2 3 Next page Last page  View All nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


mchlist at xs4all

Aug 21, 2012, 4:00 AM

Post #51 of 53 (247 views)
Permalink
Re: Dear Akamai, you got a /32 there not a bunch of /48s - how to break Facebook and annoy lots of users [In reply to]

> In RIPE land, if you get a block of addresses out of another LIR's PA
> allocation for your node, it's by definition an assignment. The status
> field in the RIPE db will be saying «ASSIGNED PA» - unless the LIR opted
> not to register the assignment in the db at all, which is allowed for
> assignment up to and including /48. It's still an assignment, though.

I have to correct you there, that is no longer the case. Current policy text says:

"When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database."

There is no provision for not registering assignments of size X. The only thing you can do is group them. You can have one object that represents a (large) number of assignments.

Marco
(In his role as author of this policy change)


gert at space

Aug 21, 2012, 4:10 AM

Post #52 of 53 (249 views)
Permalink
Re: Dear Akamai, you got a /32 there not a bunch of /48s - how to break Facebook and annoy lots of users [In reply to]

Hi,

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[6] 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
today's technology...

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

Gert Doering
-- NetMaster
--
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


patrick at ianai

Aug 24, 2012, 11:11 AM

Post #53 of 53 (239 views)
Permalink
Re: Dear Akamai, you got a /32 there not a bunch of /48s - how to break Facebook and annoy lots of users [In reply to]

[Yeah, I'm a little slow responding.]

On Aug 21, 2012, at 02:50 , Tore Anderson <tore.anderson [at] redpill-linpro> wrote:

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

Trust me, no matter what we do, or do not do, we will upset someone.

Call it one of the mysteries of life.


>>> Seriously though, you *can* go to the RIPE NCC and say in one
>>> single request «I've got 1000+ sites, please give me a /48 for each
>>> of them». I can't see any reason why such a request would be
>>> rejected. You'd probably get a nice contiguous /38 (shorter if you
>>> document a growth expectation) from the PI range, from which
>>> people that filter strictly allow /48s. Win-win.
>>
>> Perhaps we should consider it.
>>
>> I still don't think we've done anything wrong (other than mess up a
>> few route6 objects).
>
> 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.

Despite implications to the contrary on this very list, Akamai -does- care about $50K. (We may be profitable, but we got there by being f*@#ing cheap!) So that is one downside.

Also, we discussed this with multiple RIPE employees before making the request and came to the group decision as to the best / most proper way to get the addresses we needed. After caucusing with my group internally, we have decided to stand by our decision.


>> Never underestimate the power of human stupidity.
>
> 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. 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.

I'm having trouble thinking that someone spewing half a million v6 prefixes will do more than get his own connectivity shut by every peer & upstream.

The Internet is a wild, dangerous place. You don't like it, get your pr0n at the corner magazine rack like your parents did. :)

--
TTFN,
patrick

First page Previous page 1 2 3 Next page Last page  View All nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.