Re: /24s run amuck

[haesu () towardex com]

> The only way I can see to do anything about this is for upstreams to educate 
> their customers and others to pressure their peers.

Educating customers... educating peers... I think enough had been tried and that is
just too much work for the most people with little effect.

The problem is the _upstreams_ are the general source of deaggs. If upstreams have policies
in place with well organized autonomous filtering system and routing policy, theirs customers
will most likely end up being having to justify deaggregation or else get filtered.

-J

> Two primary reasons are given, one is for traffic engineering purposes to either 
> control the ingress of traffic or to allow a network to function with critical 
> links down and the other is to allow blocks to be dropped to mitigate the 
> effects of a DDoS, I dont believe either justify the deaggregation of large 
> aggregates into Nx/24s and that a large driver is to make your network look 
> larger than it is...
>
> Steve
>
> On Sat, 10 Jan 2004, Richard A Steenbergen wrote:
>
> > Ok, I realized I haven't done one of these since 2001, so it's time for an
> > updated list of /24 polluters. With /24s accounting for over 50% (more
> > than 71k) of the announcements on the Internet, it seems reasonable to try
> > and take a look at why there are so many.
> >
> > One of the patterns which quickly becomes evident is the announcing of 
> > "almost all" of a larger block, but with enough gaps that traditional 
> > scripts which look for CIDR aggregation can miss it. For example, someone 
> > who owns a /16 and announces it as 250 /24s might not show up in other 
> > CIDR aggregation scripts because of the missing 5 /24s, or if 1 of the 
> > /24s has a different AS Path.
> >
> > So, solely for the purpose of looking for this pattern, I have written a
> > script which counts the number of /24s announced within a /16 (an
> > admittedly arbitrary range, but one which happens to work) with a
> > consistant AS Path, and sorts by the highest count. This of course doesn't
> > mean for certain that the netblock listed doesn't have a good reason for
> > their deaggregation, but odds are they don't or could otherwise take steps
> > to limit announcement to the general internet (for example a cable modem
> > provider with 250 individual routes /24s but only a single upstream
> > provider, who could announce a /16 globally and use no-export on the more
> > specifics).
> >
> > This is done from the point of view of a Global Crossing (AS3549) transit 
> > feed, so things may look slightly different fromy our corner of the 
> > Internet. You have been warned.
> >
> > A summary of the top 250 netblocks by count:
> >
> > http://www.e-gerbil.net/ras/projects/ipaddr/24summary
> >
> > Detailed list of the netblocks and AS Path by count:
> >
> > http://www.e-gerbil.net/ras/projects/ipaddr/24dump
> >
> > A sorted list of the origin ASs contributing the /24s in the above lists:
> >
> > http://www.e-gerbil.net/ras/projects/ipaddr/24asn
> >
> > If you are on the list or know someone who is, please encourage them to 
> > take steps to clean up their act. You may now return to your regularly 
> > scheduled complaining about Verisign.

-- 
James Jun (formerly Haesu)
TowardEX Technologies, Inc.
1740 Massachusetts Ave.
Boxborough, MA 01719
Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation
http://www.towardex.com  | james () towardex com
Cell: (978)394-2867      | Office: (978)263-3399 Ext. 170
Fax: (978)263-0033       | AIM: GigabitEthernet0
NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE