Re: Interesting object in the RIPE database
On Wed, 7 Jul 1999, "RLE" == Robert_Martin-Leg=E8ne wrote:
RLE> Doesn't mean that it makes sense in the IP Registry world. Let's be RLE> practical. And besides, classful addressing is a Thing of the Past (ahem). The BSD way of doing it is clever, but complicated and it has no place in the DB, IMO. I always understood that the DB software would pad missing octets at the end of an IP address, no ambiguity there. What I'm surprised about is that the DB apparently allows someone to register address space that's most likely not even theirs... Of course, once it gets allocated and entered into the DB, a conflict will be detected and flagged (right!?), but until then, the error will go undetected. Is this a feature? Cheers, Steven
Hi, On Fri, 9 Jul 1999, Steven Bakker wrote:
On Wed, 7 Jul 1999, "RLE" == Robert_Martin-Leg=E8ne wrote: And besides, classful addressing is a Thing of the Past (ahem). The BSD way of doing it is clever, but complicated and it has no place in the DB, IMO. I always understood that the DB software would pad missing octets at the end of an IP address, no ambiguity there.
Yes.
What I'm surprised about is that the DB apparently allows someone to register address space that's most likely not even theirs...
The DB is just a program, not a person. The concept of reasonable is alien to it.
Of course, once it gets allocated and entered into the DB, a conflict will be detected and flagged (right!?), but until then, the error will go undetected. Is this a feature?
From a non-technical point of view, this also touches the old common admited practice that the DB was there for people to register whatever
When someone submits an update for an IP range greater than a /19, the object is accepted but the acknowledgment mail has a WARNING message asking the user whether this is actually what they intended. A /19 is the (current) maximum assignement window anyone can get from the NCC but there are other parts of the address space (eg. "old" class Bs and A) that people want to register at the RIPE DB because they are in Europe and other registries have different policies. We could add code for specific rules for different parts of the IP space, like: don't allow things bigger than /19 for space that was given to the NCC by the IANA, but do so for the rest of the space. And then change the code when the policies change. Right now this would be rather messy because it would interact with the hierarchical authorization (a part that definitely needs a full rework in the next DB). Also, I feel this kind of thing usually ends up being a bit "ugly" (from a technical point of view). they wanted, whether reasonable or not (something I've never quite agreed with). As you said, when someone introduces a mistake like this it affects other people but it is also flagged pretty fast. Opinions about what people feel is reasonable are most welcome. Greetings, Joao
Cheers, Steven
Joao, As of this morning my code (see http://stat.cybercity.dk/ripe) found four bogus objects, all of which suffer from typos in the inetnum. I think it would be perfectly valid to make the database reject objects larger than /19 and ask for them to be handled manually. Poul-Henning inetnum: 62.185.243.0 - 62.186.243.63 netname: GB-HARLEY-NET3 descr: Network of Harley Davidson Europe country: GB admin-c: AB1067-RIPE tech-c: AB1067-RIPE status: ASSIGNED PA remarks: MPN customer remarks: Please send SPAM reports to postmaster@ibm.net remarks: Please send ABUSE reports to abuse@ibm.net mnt-by: EU-IBM-NIC-MNT changed: minas@nl.ibm.com 19990707 source: RIPE inetnum: 62.185.243.64 - 62.186.243.127 netname: GB-HARLEY-NET3 descr: Network of Harley Davidson Europe country: GB admin-c: AB1067-RIPE tech-c: AB1067-RIPE status: ASSIGNED PA remarks: MPN customer remarks: Please send SPAM reports to postmaster@ibm.net remarks: Please send ABUSE reports to abuse@ibm.net mnt-by: EU-IBM-NIC-MNT changed: minas@nl.ibm.com 19990707 source: RIPE inetnum: 62.185.243.64 - 62.186.243.127 netname: GB-HARLEY-NET3 descr: Network of Harley Davidson Europe country: GB admin-c: AB1067-RIPE tech-c: AB1067-RIPE status: ASSIGNED PA remarks: MPN customer remarks: Please send SPAM reports to postmaster@ibm.net remarks: Please send ABUSE reports to abuse@ibm.net mnt-by: EU-IBM-NIC-MNT changed: minas@nl.ibm.com 19990707 source: RIPE inetnum: 194.126.77.192 - 195.126.77.199 netname: GLOB-PINCNXN3 descr: Pinnacle Int Services Ltd country: GB admin-c: PB4713-RIPE tech-c: HM201-RIPE rev-srv: bilbo.globalnet.co.uk rev-srv: gandalf.globalnet.co.uk status: ASSIGNED PA notify: notify@global.net.uk mnt-by: GLOBAL-MNT changed: shan.liu@global.net.uk 19990705 source: RIPE -- 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!
On Fri, Jul 09, 1999 at 10:48:01AM +0200, Poul-Henning Kamp wrote:
Joao,
As of this morning my code (see http://stat.cybercity.dk/ripe) found four bogus objects, all of which suffer from typos in the inetnum.
I think it would be perfectly valid to make the database reject objects larger than /19 and ask for them to be handled manually.
It would be sufficient if it rejects overlaps that do not form a tree. I.e. you can add an object inside the bounds of a less specific object but you cannot add an object that is partially inside and partially outside. Michael van Elst
Poul-Henning
inetnum: 62.185.243.0 - 62.186.243.63 netname: GB-HARLEY-NET3 descr: Network of Harley Davidson Europe country: GB admin-c: AB1067-RIPE tech-c: AB1067-RIPE status: ASSIGNED PA remarks: MPN customer remarks: Please send SPAM reports to postmaster@ibm.net remarks: Please send ABUSE reports to abuse@ibm.net mnt-by: EU-IBM-NIC-MNT changed: minas@nl.ibm.com 19990707 source: RIPE
inetnum: 62.185.243.64 - 62.186.243.127 netname: GB-HARLEY-NET3 descr: Network of Harley Davidson Europe country: GB admin-c: AB1067-RIPE tech-c: AB1067-RIPE status: ASSIGNED PA remarks: MPN customer remarks: Please send SPAM reports to postmaster@ibm.net remarks: Please send ABUSE reports to abuse@ibm.net mnt-by: EU-IBM-NIC-MNT changed: minas@nl.ibm.com 19990707 source: RIPE
inetnum: 62.185.243.64 - 62.186.243.127 netname: GB-HARLEY-NET3 descr: Network of Harley Davidson Europe country: GB admin-c: AB1067-RIPE tech-c: AB1067-RIPE status: ASSIGNED PA remarks: MPN customer remarks: Please send SPAM reports to postmaster@ibm.net remarks: Please send ABUSE reports to abuse@ibm.net mnt-by: EU-IBM-NIC-MNT changed: minas@nl.ibm.com 19990707 source: RIPE
inetnum: 194.126.77.192 - 195.126.77.199 netname: GLOB-PINCNXN3 descr: Pinnacle Int Services Ltd country: GB admin-c: PB4713-RIPE tech-c: HM201-RIPE rev-srv: bilbo.globalnet.co.uk rev-srv: gandalf.globalnet.co.uk status: ASSIGNED PA notify: notify@global.net.uk mnt-by: GLOBAL-MNT changed: shan.liu@global.net.uk 19990705 source: RIPE
-- 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!
-- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Service GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Prof. Michael Rotert ]
participants (4)
-
Joao Luis Silva Damas -
Michael van Elst -
Poul-Henning Kamp -
Steven Bakker