+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
> 

Reply via email to