Yes please. This is a very sensible thing to do. Bogons do not belong
in a public IRR.
Nick
Job Snijders via db-wg wrote on 04/09/2018 11:46:
Dear WG,
I'd like to raise the issue of bogon prefixes in the RIPE IRR, and ask
RIPE NCC to remove all "bogon" route object registrations from the
"RIPE-NONAUTH" IRR database.
Today I was made aware of this example:
$ whois -h whois.ripe.net -- "-Troute6 2001:db8::/32" | egrep -v "%|^$"
route6: 2001:db8::/32
origin: AS25375
descr: AS25375
mnt-by: ch-stafag-1-mnt
mnt-by: LEUNET-SECURITY-MNT
created: 2018-08-25T15:27:50Z
last-modified: 2018-08-25T15:27:50Z
source: RIPE
I'd consider the following prefixes, and any more-specifics of these to
be bogons prefixes:
0.0.0.0/8 # RFC 1122 'this' network
10.0.0.0/8 # RFC 1918 private space
100.64.0.0/10 # RFC 6598 Carrier grade nat space
127.0.0.0/8 # RFC 1122 localhost
169.254.0.0/16 # RFC 3927 link local
172.16.0.0/12 # RFC 1918 private space
192.0.2.0/24 # RFC 5737 TEST-NET-1
192.168.0.0/16 # RFC 1918 private space
198.18.0.0/15 # RFC 2544 benchmarking
198.51.100.0/24 # RFC 5737 TEST-NET-2
203.0.113.0/24 # RFC 5737 TEST-NET-3
224.0.0.0/4 # Multicast
240.0.0.0/4 # Reserved
::/8 # RFC 4291 IPv4-compatible, loopback, et al
0100::/64 # RFC 6666 Discard-Only
2001:2::/48 # RFC 5180 BMWG
2001:10::/28 # RFC 4843 ORCHID
2001:db8::/32 # RFC 3849 documentation
3ffe::/16 # RFC 3701 old 6bone
fc00::/7 # RFC 4193 unique local unicast
fe80::/10 # RFC 4291 link local unicast
fec0::/10 # RFC 3879 old site local unicast
ff00::/8 # RFC 4291 multicast
Any route/route6 objects covered by the above prefixes should be deleted
from the database, and the software should be extended in such a way
that nobody can register new route/route6 objects covered by the above
list.
Kind regards,
Job
