Dear colleagues,
A few months ago the RIPE NCC became the first RIR to receive an additional /12 IPv6 allocation (2a10::/12) from IANA.
We will soon begin to delegate space from this IPv6 block to LIRs. Prior to this, in order to improve routability and minimise the risk of filtering, the RIPE NCC will perform several de-bogonising activities in the next few weeks.
We plan to start announcing the full /12, as well as a few /32 or longer blocks out of 2a10::/12 from AS12654 (RIPE Routing Information System (RIS)), within the next few days. We will analyse data from RIS and RIPE Atlas and we plan to write up an analysis around this effort.
We want to remind everybody to update their bogon filters and allow routes originating from 2a10::/12 in their network.
Kind regards,
Nikolas Pediaditis
Registration Services and Policy Development Manager
RIPE NCC
I'd like to remind people not to bogonise unallocated, more downside
than upside. Particularly if it's CLI jockey network, no one will
update the config once you change your employer. Even if it's
toolised, once that tool breaks, no one will fix it, if there are no
customer complains.
What's your opinion on things like Team Cymru's BGP Bogon feed?
Much safer, but for me personally, still more downside than upside.
Fair.
I wish that I could get my hands on a DFZ BGP feed. !R to unprovisioned IPs. }
But that's not easily accessible for mere mortals.
Couldn’t you just get a VPS with Vultr and set up BGP on it?
Hello, NANOG!
Did someone say, “bogon?”
We want to remind everybody to update their bogon filters and allow routes originating from 2a10::/12 in their network.
I'd like to remind people not to bogonise unallocated, more downside
than upside. Particularly if it's CLI jockey network, no one will
update the config once you change your employer. Even if it's
toolised, once that tool breaks, no one will fix it, if there are no
customer complains.
I appreciate the various views on this topic. If one is going to filter bogons, we strongly recommend that folks BGP peer with us for these updates, or use some other, dynamically updated process. We update our static lists using the same underlying process, but that won’t update remotely deployed static copies.
For all prefixes, e.g. 2a10::/12, the filtering will be automagically updated as allocations are made.
https://www.team-cymru.com/bogon-reference-bgp.html
Be well,
Rabbi Rob.
The last time I looked — it's been a while — doing that was not an option for me.
I'll look again to see what the current status is.
Thank you for the pointer.
There are other options besides Vultr, that’s just the one I’ve used the most. Check out http://bgp.services.
Hello
What is the purpose of null routing bogons? As it is, my network being default free zone, traffic to bogons will be returned to sender with no route to host.
The only way for me to send out traffic to bogons is if one my peers announces a bogon prefix. Even if I did null route bogons, manually or through the use of the Cymru service, a peer could still announce a more specific and override that.
Is there a way to use the RPKI system to ensure bogons are simply invalid? Seems much more effective to me.
Regards
Baldur
This is why the one and only proposal I’ve seen that provides an actual useful outcome for RPKI is a good idea…
RIRs issuing AS0 ROAs for unallocated/unassigned space in their inventories.
This way, it is tool-ised and the tool is run by the same organization that’s doing the allocations and reclamations of the space.
Owen
The only way for me to send out traffic to bogons is if one my peers announces a bogon prefix. Even if I did null route bogons, manually or through the use of the Cymru service, a peer could still announce a more specific and override that.
The idea isn't necessarily that you explicitly null-route them but rather that you block/ignore announcements of them on the assumption that malfeasants may be attepmting to squat on them or otherwise use them for some form of, well, malfeasance. As such, the filter you build isn't just e.g. "2a10::/12" (if indeed that range was to be considered a single bogon) but rather "2a10::/12 ge 12" which means you'd block more-specifics within that range, too.
Is there a way to use the RPKI system to ensure bogons are simply invalid? Seems much more effective to me.
Someone like ICANN or IANA could publish an ROA to a reserved ASN (or to no ASN - is that possible?) for all unallocated space or something of the like, I suppose.
Is there a good and easy way for me to generate such prefix filters automatically for common routing platforms? A BGP feed is not going to do it.
Regards,
Baldur
There is, in fact, an RFC for this which covers use of AS0 in ROAs to represent “Should Not Be Announced”.
Policy has been proposed in RIPE, AfriNIC, and LACNIC. Policy has been adopted in APNIC and is in the process of implementation.
Policy has not (yet) been proposed in ARIN.
IIRC, IANA (via ICANN) has committed to start doing this for space not yet allocated to RIRs.
Owen
Baldur Norddahl wrote:
Hello
What is the purpose of null routing bogons? As it is, my network being default free zone, traffic to bogons will be returned to sender with no route to host.
The only way for me to send out traffic to bogons is if one my peers announces a bogon prefix. Even if I did null route bogons, manually or through the use of the Cymru service, a peer could still announce a more specific and override that.
That more specifics override could use an override.
Tend to agree with Saku on this one.
Mark.