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.
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
So many martian lists, so little authority. 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.