What are Bogons?
THE GRH PROJECT HAS BEEN CONCLUDED
As IPv6 Routing Stability has improved over the years we have concluded the GRH project.
The GRH pages remain for a historical perspective.
The ULA Registry remains active.
Bogons or martians are prefixes that get announced into the Global Routing Table (GRT) that should not be there as they could possibly harm the stability and reliability of (parts of) the internet. The Looking Glass will give any of the various colors to bogies. The option called Bogies will select only these anomalies and ignore correct paths. You must enter a prefix, eg 0::/0 to see all the bogons, but selective prefixes can be used too. The system ignores direct peers (1 AS hop) and internal prefixes because that is allowed ofcourse.
Quite obviously announcing a default route into the GRT is not something that should happen.
Martian prefixes are prefixes which should only reside inside a network. The following prefixes should never be found in BGP as based on the IANA Address Space Assignments. The following prefixes are considered to be martians:
The following are a list of IX prefixes, these prefixes are handed out per /48 to Internet Exchanges. These prefixes should normally not be visibile in the GRT as they are /48's and are supposed to be not routeable. In practice though a lot of ISPs tend to provide transit to these prefixes, even though they are meant to only be used for the exchange fabric and not for any other services. The prefixes where IX allocations are made from are:
Prefixes that are not allocated by RIPE, ARIN, APNIC, LACNIC or AFRINIC should ofcourse never appear anywhere in the routing system. The GRH system keeps an internal list of all the allocated made and crossreferences this with the announced prefixes.
Subnet of big allocation
More specifics of an allocated prefix should never be announced in the GRT. See Gert's IPv6 Filter Recommendations. Some places are using more specifics for multi-homing of smaller ASN's, in this case the prefix will be sourced from a different ASN than the prefix it falls under. In cases where the prefix is announced from the same ASN though, the operator should really consider applying aggregation.
Mismatching origin ASN
The origin ASN of the announced prefix didn't match up with the well known ASN.
Multiple origin ASN's
A prefix should have only one origin ASN, multiples usually mean a routing glitch. Note that this doesn't include so called MOAS which are aggregated in the ASPath.
More specific 6to4 prefix
6to4 is one of the several IPv4 to IPv6 transition methods. Section 5.2 point 3 of RFC3056 explictely restricts the propagation of more specifics than 2002::/16 to prevent polution of the IPv6 routing table by elements of the IPv4 routing table.
Prefixes having an ASPaths of over 12 ASN's will quite probably mean that it concerns a so called Ghost Route. For more about this see the special What is a Ghost Route? page.
These allocations are special and all fall under 2001:500::/32. Typically you do want to have these in your routing table especially as the first two /48's contain the F and H root servers. Prefixes in this field are not marked as bogons but as they are special they do get a lightgrey color. For more information see: ARIN critical internet infrastructure microallocation.
2001:db8::/32 is a Documentation Prefix, it is thus used in documents and should not be used to route any traffic. More information can be found in the APNIC IPv6 Documentation Prefix FAQ.
The ORCHID (Overlay Routable Cryptographic Hash Identifiers) prefix (2001:10::/28) as specified in RFC4843, falls under the IANA IPv6 Special Purpose Address Registry RFC4773). It is a non-routed part of the IPv6 address space used for Cryptographic Hash Identifiers. As per the above RFC, this address space is non-routed and thus should not appear in BGP.
The NAT64 prefix (64:ff9b::/96) as specified in RFC6052. This prefix should be kept inside an ASN and thus should not appear in BGP.
The Benchmark prefix (2001:0002::/48) as specified in RFC5180. This prefix should be kept inside an ASN and thus should not appear in BGP.