Re: De-bogonising 2a10::/12
Dear colleagues, Following the announcement of our plans to debogonise 2a10::/12, we have now shared the results of the tests we've been carrying out to check the usability of address space in this block. Read all about it on RIPE Labs: https://labs.ripe.net/Members/emileaben/the-debogonisation-of-2a10-12 Kind regards, Mirjam Kühne RIPE NCC On 16/01/2020 09:07, Emile Aben wrote: > Dear colleagues, > > We have now started de-bogonising 2a10::/12! > > As part of this, we are announcing a couple of prefixes out of 2a10::/12 > from AS12654 (RIPE's Routing Information Service, RIS). Pingable targets > have been configured in these prefixes, and we invite network operators > to test for themselves whether this address space is reachable. > > The simplest way to do this would be to perform a ping6 to 2a10:4::1 . > > Using RIPE Atlas and RIS, we will also be carrying out our own tests in > order to investigate connectivity and filtering for this address space. > We plan to share our results with the RIPE community via RIPE Labs > within the next few days. > > For those who want to do other testing, beyond the basic test described > above, we have a total of 8 targets available for this, with 2 different > prefix lengths and all variations of having ROUTE objects in the RIPE DB > and/or ROAs. > > 2a10:3:4::1 /48 ROUTE object + ROA > 2a10:3:5::1 /48 no ROUTE object + ROA > 2a10:3:6::1 /48 ROUTE object + no ROA > 2a10:3:7::1 /48 no ROUTE object + no ROA > > 2a10:4::1/32 ROUTE object + ROA > 2a10:5::1/32 no ROUTE object + ROA > 2a10:6::1/32 ROUTE object + no ROA > 2a10:7::1/32 no ROUTE object + no ROA > > Kind regards, > > Emile Aben > RIPE NCC >
De-bogonising 2a10::/12
Dear colleagues, We have now started de-bogonising 2a10::/12! As part of this, we are announcing a couple of prefixes out of 2a10::/12 from AS12654 (RIPE's Routing Information Service, RIS). Pingable targets have been configured in these prefixes, and we invite network operators to test for themselves whether this address space is reachable. The simplest way to do this would be to perform a ping6 to 2a10:4::1 . Using RIPE Atlas and RIS, we will also be carrying out our own tests in order to investigate connectivity and filtering for this address space. We plan to share our results with the RIPE community via RIPE Labs within the next few days. For those who want to do other testing, beyond the basic test described above, we have a total of 8 targets available for this, with 2 different prefix lengths and all variations of having ROUTE objects in the RIPE DB and/or ROAs. 2a10:3:4::1 /48 ROUTE object + ROA 2a10:3:5::1 /48 no ROUTE object + ROA 2a10:3:6::1 /48 ROUTE object + no ROA 2a10:3:7::1 /48 no ROUTE object + no ROA 2a10:4::1/32 ROUTE object + ROA 2a10:5::1/32 no ROUTE object + ROA 2a10:6::1/32 ROUTE object + no ROA 2a10:7::1/32 no ROUTE object + no ROA Kind regards, Emile Aben RIPE NCC
Re: De-bogonising 2a10::/12
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.
Re: De-bogonising 2a10::/12
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.
Re: De-bogonising 2a10::/12
> On Jan 10, 2020, at 13:18 , Brandon Martin 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
Re: De-bogonising 2a10::/12
On Fri, Jan 10, 2020 at 10:19 PM Brandon Martin 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
Re: De-bogonising 2a10::/12
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
Re: De-bogonising 2a10::/12
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 wrote: > > On Fri, 10 Jan 2020 at 16:34, Nikolas Pediaditis 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
Re: De-bogonising 2a10::/12
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 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 > >
Re: De-bogonising 2a10::/12
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 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 > >
Re: De-bogonising 2a10::/12
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogonising 2a10::/12
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 signature.asc Description: Message signed with OpenPGP
Re: De-bogonising 2a10::/12
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 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 > >
Re: De-bogonising 2a10::/12
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogonising 2a10::/12
On Fri, 10 Jan 2020 at 19:32, Grant Taylor via NANOG wrote: > What's your opinion on things like Team Cymru's BGP Bogon feed? Much safer, but for me personally, still more downside than upside. -- ++ytti
Re: De-bogonising 2a10::/12
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: De-bogonising 2a10::/12
On Fri, 10 Jan 2020 at 16:34, Nikolas Pediaditis 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
De-bogonising 2a10::/12
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
