[db-wg] remove bogon prefixes in the RIPE IRR NON-AUTH DB?

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
>