I do also support this suggestion. Kind regards, Cynthia
On 2018-10-05 21:49, Elvis Daniel Velea via db-wg wrote: > +1 > > /elvis > > Excuse the briefness of this mail, it was sent from a mobile device. > >> On Oct 5, 2018, at 12:47, Nick Hilliard via db-wg <[email protected]> wrote: >> >> 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
