[29463] in North American Network Operators' Group
Re: using IRR tools for BGP route filtering
daemon@ATHENA.MIT.EDU (Dana Hudes)
Sun Jun 25 07:48:49 2000
Message-ID: <004701bfde9a$ef5de060$3d5cdcd1@hudes.org>
From: "Dana Hudes" <dhudes@hudes.org>
To: "Mark Borchers" <markb@infi.net>,
"Mark Prior" <mrp@connect.com.au>
Cc: <nanog@merit.edu>
Date: Sun, 25 Jun 2000 07:46:00 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
I plan to write a WHOIS client for the RA in Perl as part of Net::Whois. =
I also plan to have a program that will walk the RA for a given AS =
(which is why I need the whois client).
Eventually I also plan to add ARIN support to Net::Whois
I'd like to see a DNS walk to compare the registry to what's out there.
Not to mention finding all the bogus records that do things like list =
ENGLAND
as a country code (instead of UK).
----- Original Message -----=20
From: "Mark Prior" <mrp@connect.com.au>
To: "Mark Borchers" <markb@infi.net>
Cc: <nanog@merit.edu>
Sent: Sunday, June 25, 2000 3:05 AM
Subject: Re: using IRR tools for BGP route filtering
>=20
> Are there any plans to correlate route registry objects against
> address registry databases?
>=20
> I believe that one of the roots of this thread is the need to =
validate
> the legitimacy of not only routes, but registered route objects.
> Although it is too much to expect that route objects will match =
up
> cleanly with address block assignments at the outset, performing
> such a correlation would at least identify the scope of the =
problem.
>=20
> It's not all that simple to do, although certainly some of the trash
> could be deleted, since it's not always the organisation "owning" the
> address space that announces it. Some process that compares the IR
> registry view to the current routing table view might be "better" but
> who would take on that task and under what mandate as its one thing to
> find the problems but it's an entirely different problem to actually
> fix it?
>=20
> Mark.
