BGP Question - how do work around pigheaded ISPs

A really quick inspection shows:
91.16.23.0/24 AS11770, although is is a history entry only at the moment:
route-views.oregon-ix.net>sh ip bgp 91.16.23.0
BGP routing table entry for 91.16.23.0/24, version 6427742
Paths: (23 available, no best path)
  Not advertised to any peer
  8517 9000 2548 1239 11770 (history entry)
...

103.22.7.0/24 AS9768
route-views.oregon-ix.net>sh ip bgp 103.22.7.0
BGP routing table entry for 103.22.7.0/24, version 6099648
Paths: (25 available, best #10)
  Not advertised to any peer
  2551 1239 3608 3608 3608 9768
    163.179.232.37 from 163.179.232.37 (163.179.232.37)
      Origin incomplete, localpref 100, valid, external
...

Stolen is a lot harder to find.

In the referenced message, Daniel L. Golding said:

And then you have junk like:

BGP routing table entry for 64.0.0.0/8, version 6739580
Paths: (27 available, best #27)
  Not advertised to any peer
  8297 6453 1239 5696 15331
    195.219.96.239 from 195.219.96.239 (195.219.96.239)
      Origin incomplete, localpref 100, valid, external

which has been around for a long time. And which is obviously not
being filtered by a lot of backbones.

This could be a tricky way for someone to just use whatever otherwise
unannounced space in 64/8, or it could just be a lame router configuration
somewhere that the parties involved don't care to fix.

But either way, it isn't very pretty going through the list of all
the backbones that are not filtering this sort of stuff out and
seeing just how long it is... it is truly amazing that there aren't more
widespread and frequent screwups caused by bogus announcements.

[...]

This could be a tricky way for someone to just use whatever
otherwise unannounced space in 64/8, or it could just be a lame
router configuration somewhere that the parties involved don't care
to fix.

Certainly the latter (never attribute to malice what can be explained
with stupidity). It's just too easy to forget "no auto-summary", and
too difficult to notice its effects - you'll attract traffic from
unused addresses under the classful prefix (64.0.0.0/8 in this case),
but there shouldn't be that much of it. Of course once in a while
when a network using a more-specific prefix goes offline for a while,
you may receive quite a bit of unexpected traffic. But I bet that
most ISPs don't have good tools to detect this either. So we have to
wait until a nice person signals the problem to the offender.

For 64.0.0.0/8 this seems to have happened in the meantime... but now
there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8), sigh.

i dont know why you even allow 64/8 and/or 62/8 into your network. Filter
them...

Christian

Amen to that. While we have and can go on for days about filtering on
the 'low end' of sizes in the modern allocation ranges, I sincerely hope
no one in their right mind would attempt to argue that there's any
purpose to accepting 24.0.0.0/8, 61.0.0.0/8 - 66.0.0.0/8.

I'm certain folks will kvetch about being able to filter large aggregates
in these spaces, but there is simply a lot of clueless classful configuration
that goes on Out There. Unsuprisingly, the recent-allocation spaces get
more hits on the filters than, say, net-24. Regardless on your stance of
allocation-boundary filtering, this is just sane defense of your network
against bogons.

Cheers,

Joe

Aren't many Earthlink dialups in 64/8?

Filtering that would mean his employees couldn't get Sprint DSL, and
prevent millions of potential customers from reaching his web servers.

That's not smart business. It's called "cutting off your nose to spite
your face."

There are plenty of folks who have space in 64/8. However, no one should be
classfully advertising 64.0.0.0/8, as it has not been assigned to any single
entity. Therefore, anyone who is advertising this block is doing so in
error, and it's permissible to filter the EXACT 64.0.0.0/8 route
announcement. (as opposed to filtering "64.0.0.0/8 or longer", which would
blackhole many folks)

- Daniel Golding

Ever have one of those days where you bang your head against recalcitrant
users who don't understand why a Fortune 100 corporation would need
security policies all day, then come home and say something stupid on
a (inter)national mailing list where hundreds of people you might find the
desire to work for some day will read it?

:-/