Re: lowering maximum assignment window
From owner-lir-wg@ripe.net Thu Feb 11 14:38:31 1999 From: "Bernard Steiner" <bs@eunet.ch>
Just for reference, I ran over 12-14h worth of trafic data (cisco NetFlow), starting at jan27 midnight, looking for source IP numbers which have a RIPE record of status "ALLOCATED" but not one of "ASSIGNED".
*na: EU-EUNET-950315 193.73.103.80
Note: AFAIK, this is actually EUnet's PA address space. Unfortunately, the customer ran away with it and refused to give it back. I don't see why EUnet should be held responsible for keeping the database up-to-date in this case. I also wonder how many cases like this one there are out there (people running off with PA address space).
Just my \(= 0.02 worth.
This is not EUnet's fault then (if what you state above is correct), however it IS the access provider's fault who allows them to connect to the Internet with UNREGISTERED addresses! UUNet-GW>sho ip bg 193.73.103.80 BGP routing table entry for 193.73.103.0 255.255.255.0, version 8341409 Paths: (1 available, best #1, advertised over EBGP) 701 1833 3303 8408 157.130.33.17 from 157.130.33.17 (137.39.2.154) Origin IGP, valid, external, best aut-num: AS8408 descr: AS for MediaConnect SA descr: Joint network Company descr: Agence Telegraphique Suisse (SDA-ATS) and Groupe Publicitas descr: Avenue des Mousquines 4 - CH-1005 Lausanne descr: AS created by union of access by ISPs of both mother companies descr: (UBN for Publicitas - Eunet for SDA-ATS as-in: from AS3303 100 accept ANY as-in: from AS286 100 accept ANY as-out: to AS3303 announce AS8408 as-out: to AS286 announce AS8408 default: AS3303 100 admin-c: YD31-RIPE admin-c: DD227-RIPE tech-c: YD31-RIPE tech-c: DD227-RIPE mnt-by: AS8408-MNT changed: ddurand@mediaconnect.ch 970804 source: RIPE Ooops... Who said it was unregistered? inetnum: 193.73.72.0 - 193.73.103.0 netname: PUBLICITAS-BLOCK-32 descr: Publicitas-Holding AG descr: Lausanne country: CH admin-c: DD17-RIPE tech-c: DD17-RIPE changed: huber@switch.ch 950713 source: RIPE I suspect this is a registration error or more probably a legacy problem of the database... It seems to me that quite some time ago the above assignment was what we now mean by 193.73.72.0 - 193.73.103.255 ^^^ Therefore, It may be useful to slightly modify Poul's program to cope with this anomaly (since I suspect quite some LEGAL addresses fall in such INCORRECTLY REGISTERED assignments)... Janos
Ooops... Who said it was unregistered?
inetnum: 193.73.72.0 - 193.73.103.0
I suspect this is a registration error or more probably a legacy problem of the database... It seems to me that quite some time ago the above assignment was what we now mean by 193.73.72.0 - 193.73.103.255
Therefore, It may be useful to slightly modify Poul's program to cope with this anomaly (since I suspect quite some LEGAL addresses fall in such INCORRECTLY REGISTERED assignments)...
Well, I'd rather not change it to DWIM broken database entries, clearly the above database entry should be fixed. But if the script flags entries which should not be complained about for valid reasons, let me know and I'll deal with it. Anyway, I have made a HTML version of the report available at: http://stat.cybercity.dk/ripe It will be put in the daily run so it will be updated every night. (Paula: Feel free to add a link from the RIPE pages) I have added the maintainer to the output as well, I guess that is a better search key for many of you. I will write a README file and wrap up the sources when I have a bit more time. Poul-Henning PS: If there is interest in more work of this kind I'll happily take a contract for it: I'm free-lance wizard and I have to make a living... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
participants (2)
-
Janos Zsako -
Poul-Henning Kamp