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
On Fri, 10 Jan 2020 at 16:34, Nikolas Pediaditis <npediaditi@ripe.net> wrote:
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. -- ++ytti
On 1/10/20 10:07 AM, Saku Ytti wrote:
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? -- Grant. . . . unix || die
Couldn't you just get a VPS with Vultr and set up BGP on it? On Fri, Jan 10, 2020, 11:44 AM Grant Taylor via NANOG <nanog@nanog.org> wrote:
On 1/10/20 10:36 AM, Saku Ytti wrote:
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.
-- Grant. . . . unix || die
On 1/10/20 11:01 AM, Ross Tajvar wrote:
Couldn't you just get a VPS with Vultr and set up BGP on it?
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. -- Grant. . . . unix || die
There are other options besides Vultr, that's just the one I've used the most. Check out http://bgp.services. On Fri, Jan 10, 2020, 12:34 PM Grant Taylor via NANOG <nanog@nanog.org> wrote:
On 1/10/20 11:01 AM, Ross Tajvar wrote:
Couldn't you just get a VPS with Vultr and set up BGP on it?
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.
-- Grant. . . . unix || die
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. -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern
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 On Fri, Jan 10, 2020 at 7:08 PM Rabbi Rob Thomas <robt@cymru.com> wrote:
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. -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree." - Leo McKern
On 1/10/20 2:49 PM, Baldur Norddahl wrote:
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. -- Brandon Martin
On Fri, Jan 10, 2020 at 10:19 PM Brandon Martin <lists.nanog@monmotha.net> wrote:
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 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
On Jan 10, 2020, at 13:18 , Brandon Martin <lists.nanog@monmotha.net> wrote:
On 1/10/20 2:49 PM, Baldur Norddahl wrote:
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.
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.
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
On Jan 10, 2020, at 09:07 , Saku Ytti <saku@ytti.fi> wrote:
On Fri, 10 Jan 2020 at 16:34, Nikolas Pediaditis <npediaditi@ripe.net> wrote:
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.
-- ++ytti
On 10/Jan/20 19:07, Saku Ytti wrote:
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.
Tend to agree with Saku on this one. Mark.
participants (10)
-
Baldur Norddahl -
Brandon Martin -
Grant Taylor -
Joe Maimon -
Mark Tinka -
Nikolas Pediaditis -
Owen DeLong -
Rabbi Rob Thomas -
Ross Tajvar -
Saku Ytti