[53995] in North American Network Operators' Group
Re: Operational Issues with 69.0.0.0/8...
daemon@ATHENA.MIT.EDU (Sean Donelan)
Fri Dec 6 23:04:46 2002
Date: Fri, 6 Dec 2002 23:03:05 -0500 (EST)
From: Sean Donelan <sean@donelan.com>
To: Rob Thomas <robt@cymru.com>
Cc: NANOG <nanog@merit.edu>
In-Reply-To: <ROTMAILER.0212061940360.17658-100000@dragon.sauron.net>
Errors-To: owner-nanog-outgoing@merit.edu
On Fri, 6 Dec 2002, Rob Thomas wrote:
> I (and Steve Gill) am more than happy to create such a list. Heck, you
> don't even have to bug me! :) I've even pondered the idea of hosting
> a WHOIS server that contains only bogon ranges.
So many martian lists, so little authority.
> whois -h whois.radb.net rs-martians
route-set: rs-martians
descr: Martian networks
members: 0.0.0.0/0^32, 10.0.0.0/8^+,
192.168.0.0/16^+, 128.0.0.0/16^+,
192.0.0.0/24^+, 224.0.0.0/3^+,
127.0.0.0/8^+, 172.16.0.0/20^+,
192.0.2.0/24^+, 191.255.0.0/16^+,
223.255.255.0/24^+, 0.0.0.0/0^26-32
remarks: these networks and any more-specific networks are not
remarks: accepted by eu-X across any peering points
admin-c: EUX-RIPE
tech-c: EUX-RIPE
notify: noc@eu-X.com
mnt-by: VASNET-MNT
changed: jules@eu-X.com 20011020
source: RIPE
route-set: RS-MARTIANS
descr: The ff. routes should be denied by all border router
members: 0.0.0.0/0, 127.0.0.0/8^+, 10.0.0.0/8^+,
172.16.0.0/20^+, 192.168.0.0/16^+, 192.0.2.0/24^+,
128.0.0.0/16^+, 191.255.0.0/16^+, 192.0.0.0/24^+,
223.255.255.0/24^+, 224.0.0.0/3^+, 0.0.0.0/0^26-32
remarks: These routes are usually blocked by ISPs.
tech-c: AP16-AP
admin-c: AP16-AP
notify: arth@apnic.net
mnt-by: MAINT-AU-BLUETOOTH
changed: hm-changed@apnic.net 20021111
source: APNIC
route-set: rs-martians
descr: Martian and IANA reserved networks
members: 0.0.0.0/7, 2.0.0.0/8, 5.0.0.0/8,
10.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8,
31.0.0.0/8, 36.0.0.0/7, 39.0.0.0/8,
41.0.0.0/8, 42.0.0.0/8, 58.0.0.0/7,
60.0.0.0/8, 70.0.0.0/7, 72.0.0.0/5,
83.0.0.0/8, 84.0.0.0/6, 88.0.0.0/5,
96.0.0.0/3, 127.0.0.0/8, 128.0.0.0/16,
128.66.0.0/16, 172.16.0.0/12, 191.255.0.0/16,
192.0.0.0/24, 192.0.2.0/24, 192.0.128.0/17,
192.31.196.0/24, 192.52.193.0/24, 192.67.23.0/24,
192.68.185.0/24, 192.70.192.0/21, 192.70.200.0/23,
192.94.77.0/24, 192.94.78.0/24, 192.168.0.0/16,
197.0.0.0/8, 198.97.38.0/24, 201.0.0.0/8,
222.0.0.0/7
remarks: these networks and any more-specific networks are not
remarks: accepted by Level 3 across any peering points
admin-c: LV3-LEVEL3
tech-c: LV3-LEVEL3
notify: routing@Level3.net
mnt-by: LEVEL3-MNT
changed: roy@Level3.net 20021125
source: LEVEL3
>
The problem with all martian lists, going back to the very first one,
is third-party maintainers eventually stop maintaining them after a few
years while the lists themselves get embedded in many unexpected places.
I'm sure Rob will do a great job for a few years, but no one does this
forever.
IANA is the source of the delegations, maintainer of the assignments,
and is authoritative (i.e. if IANA gets it wrong, we're all screwed).
The simpliest solution is when IANA delegates an IPv4/IPv6 block for
something to post a message to the IETF-Announce, and the appropriate
IANA and RIR list, much like the RFC-Editor does with RFCs.
