Operational Issues with 69.0.0.0/8...

Todd,

If this helps. Do something like the following...

        telnet route-views.oregon-ix.net > /tmp/file
         term len 0
         sh ip bgp 69.0.0.0 255.0.0.0 l
         quit

        cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more

...your commands will vary.

You will see plenty of routes within 69/8.

A closer look with show that around 121 routes are seen in the 69/8 range via most of the feeds into Oregon. There is one big exception...

        69.4.64.0/20

... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route within 69/8 that shows up via AS-2548. This is valuable information.

It does not mean there is filtering within AS-2548, but I would recommend you contact them to further this investigation.

BTW: This is exactly what Oregon is great for! It shows up issues like this with ease. Thanks!

Martin

This topic came up on cisco-nsp, but was really more appropriate
here. Been meaning to post summaries when I got enough round tuits.

A suggestion was made there that the RIRs give a bgp feed of 'unused'
routes to interested parties such that they can be blackholed, etc.
Sounded like a lot of overhead and things which could go wrong to
me. Skipping over the arguments about who would/wouldn't modify
processes and would take such a feed, I wouldn't want to have to pay
for that infrastructure, its support and maintenance out of my
regsitry fees. I do think it makes LOADS of sense to have the
(un)allocations clearly visible in the IRR. Some of the RIRs do it
today for their 'greater aggregates' [eg, whois -h whois.ripe.net
82.0.0.0/8].

Sure, you'd still have providers ignoring the IRR, but it gets a
lot harder for them to whine about the time it takes to update
filters or the lack of automation if the data is in a standard
format in globally distributed DBs for which there are umpty public
tools. There's always the gripe about authentication. Perhaps
the IANA should set up a routing registry which merely publishes in
RPSL format the allocated/unallocated list
(http://www.iana.org/assignments/ipv4-address-space) and the truly
paranoid can just consult *only* that registry for their
configuration magic? That would be a one-time hit for IANA [or
volunteers] to make the flat-file-to-RPSL code, and being a single-
source could be cyptographically signed/confirmed if needed.

Cheers,

Joe