Operational Issues with 69.0.0.0/8...

Fri Dec 6 22:49:45 UTC 2002

On Fri, Dec 06, 2002 at 12:14:51PM -0500, James Smith wrote:
> One would think that operators not updating filters to permit 
> properly allocated space IS an operational issue.

To quote a friend "public shaming will only go so far". At some 
point, you have to communicate to your customers and to the 
customers of the broken networks that the vendor shouldn't be used.  
This is one case where no attempt at finger-pointing could even 
remotely be made; when a customer/whoever protests, offer to 
conference in with $broken_network's technical people and have them 
admit they're broken. 

It's the same approach needed for fixing wildly random deaggregation. 
Actually *talking* to people works.

I think I already pointed to the one hole that might be ARIN's 
problem to fix, but to be blunt about it... I wouldn't expect NO
entry for properly activated/allocated space.  Regardless if you 
choose the RIPE approach, the APNIC approach, or come up with a 
new one, the values returned for queries should at least 
differentiate from "space over which I have authority" and 
"space over which I do not have authority":

prompt>  whois -h rr.arin.net 69.0.0.0/8

% ARIN Internet Routing Registry Whois Interface

% No entries found in ANS, ARCSTAR, ARIN, BCONNEX,
% BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database.

prompt>  whois -h rr.arin.net 70.0.0.0/8 

% ARIN Internet Routing Registry Whois Interface

% No entries found in ANS, ARCSTAR, ARIN, BCONNEX,
% BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database.

prompt> 

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE