According to information given to me by Edward Shryane <eshryane@ripe.net>, the cleanup of bogon route objects which made reference to bogon IP address space should have been completed the night before last. My latest analysis suggests that a few such route objects escaped the net and are still present within the NONAUTH data base. These route objects are summarized below. I'd appreciate it if others would take a look at these and tell me if they think that these route objects should or should not be present within the data base. Note that both batches of bogon routes given below are really rather curious due to the fact that nearly all of the routes have the exact same last-modified date (2018-09-04) and a great many of them refer either to the 192.88.99.0/24 IPv4 block, which is apparently reserved by RFC 3068, or to some IPv6 block which is *not* clearly related to RFC 3068. I am frankly not sure what to make of any of these, but I do suspect that they are all invalid, because no RIR has assigned any of the relevant IP space to any resource member. NONAUTH / IPv4 routes (36): --------------------------- 41.217.128.0/19 37034 2018-09-04 41.217.144.0/20 37034 2018-09-04 41.217.144.0/21 37034 2018-09-04 41.242.84.0/22 37609 2018-09-04 170.56.0.0/16 15854 2018-09-04 170.56.0.0/16 702 2018-09-04 192.31.196.0/24 112 2018-09-04 192.88.99.0/24 1741 2018-09-04 192.88.99.0/24 29259 2018-09-04 192.88.99.0/24 2847 2018-09-04 192.88.99.0/24 12816 2018-09-04 192.88.99.0/24 3344 2018-09-04 192.88.99.0/24 20640 2018-09-04 192.88.99.0/24 5408 2018-09-04 192.88.99.0/24 1835 2018-09-04 192.88.99.0/24 8473 2018-09-04 192.88.99.0/24 15598 2021-02-25 192.88.99.0/24 1101 2018-09-04 192.88.99.0/24 12871 2018-09-04 192.88.99.0/24 680 2018-09-04 192.88.99.0/24 25192 2018-09-04 192.88.99.0/24 35244 2018-09-04 192.88.99.0/24 39326 2018-09-04 192.88.99.0/24 5413 2018-09-04 192.88.99.0/24 25308 2018-09-04 192.88.99.0/24 3243 2018-09-04 192.88.99.0/24 29076 2018-09-04 192.88.99.0/24 29632 2018-09-04 192.88.99.0/24 8903 2020-11-18 192.88.99.0/24 21416 2018-09-04 192.88.99.0/24 43097 2018-09-04 192.88.99.0/24 29432 2018-09-04 192.88.99.0/24 50113 2018-09-04 192.107.242.0/24 394784 2018-09-04 204.144.127.0/24 40142 2018-09-04 205.166.145.0/24 394784 2018-09-04 NONAUTH / IPv6 routes (37): --------------------------- 2001::/32 1101 2018-09-04 2001::/32 12816 2018-09-04 2001::/32 12871 2018-09-04 2001::/32 1741 2018-09-04 2001::/32 21155 2018-09-04 2001::/32 25192 2018-09-04 2001::/32 25308 2018-09-04 2001::/32 25525 2018-09-04 2001::/32 29259 2018-09-04 2001::/32 29432 2018-09-04 2001::/32 44980 2018-09-04 2001::/32 57801 2018-09-04 2001:4:112::/48 112 2018-09-04 2002::/16 1101 2018-09-04 2002::/16 12871 2018-09-04 2002::/16 15598 2021-02-23 2002::/16 1741 2018-09-04 2002::/16 1835 2018-09-04 2002::/16 20640 2018-09-04 2002::/16 21416 2018-09-04 2002::/16 25192 2018-09-04 2002::/16 25308 2018-09-04 2002::/16 2847 2018-09-04 2002::/16 29259 2018-09-04 2002::/16 29432 2018-09-04 2002::/16 29632 2018-09-04 2002::/16 3344 2018-09-04 2002::/16 35244 2018-09-04 2002::/16 39326 2018-09-04 2002::/16 43097 2018-09-04 2002::/16 5413 2018-09-04 2002::/16 559 2018-09-04 2002::/16 680 2018-09-04 2002::/16 8473 2018-09-04 2002::/16 8903 2018-09-04 2011:4188::/48 12880 2018-09-04 2c0f:f260::/32 36924 2018-09-04
Hi Ronald,
On 20 Jul 2021, at 21:03, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
According to information given to me by Edward Shryane <eshryane@ripe.net>, the cleanup of bogon route objects which made reference to bogon IP address space should have been completed the night before last.
To be clear (apologies it was not), the outstanding route objects were deleted *last* night, not the night before last. The cleanup job ran first on the morning of 30th June, the maintainers were emailed a week later on 6th July, and the route(6) objects were deleted two weeks after that (last night). In summary, the job deleted 863 route(6) objects in RIPE-NONAUTH, except for 7 which were excluded. We received two tickets from maintainers, asking to exclude those 7 route(6) objects from the cleanup, and we are currently in discussion with them. The latest split files in https://ftp.ripe.net/ripe/dbase/split/ were generated this morning around 05:50 UTC so do not contain the deleted route(6) objects.
My latest analysis suggests that a few such route objects escaped the net and are still present within the NONAUTH data base. These route objects are summarized below. I'd appreciate it if others would take a look at these and tell me if they think that these route objects should or should not be present within the data base.
I will check why the routes you listed were not scheduled for deletion.
Note that both batches of bogon routes given below are really rather curious due to the fact that nearly all of the routes have the exact same last-modified date (2018-09-04)
I think this is because the NWI-5 implementation that created the RIPE-NONAUTH database for out-of-region route, route6 and aut-num objects was run on September 4th, 2018, and many of those objects have not been modified since then.
and a great many of them refer either to the 192.88.99.0/24 IPv4 block, which is apparently reserved by RFC 3068, or to some IPv6 block which is *not* clearly related to RFC 3068. I am frankly not sure what to make of any of these, but I do suspect that they are all invalid, because no RIR has assigned any of the relevant IP space to any resource member.
According to the implementation plan: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html if these ranges are not marked as "available" or "reserved" in an RIR's delegated stats, then it will be skipped, and I didn't find 192.88.99.0/24 in any RIR's delegated stats. (To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation? Regards Ed Shryane RIPE NCC
Hello db group, On Tue, Jul 20, 2021 at 10:11:46PM +0200, Edward Shryane via db-wg wrote:
According to the implementation plan: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
if these ranges are not marked as "available" or "reserved" in an RIR's delegated stats, then it will be skipped, and I didn't find 192.88.99.0/24 in any RIR's delegated stats.
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
RFC 3068 was obsoleted by RFC 7526, a document that 'deprecates' 192.88.99.0/24. The whole thing is here: https://www.rfc-editor.org/rfc/rfc7526.html Unfortuntaly, RFC 7526 is not entirely clear on what 'deprecation' means in context of for example the 'Forwardable' and 'Globally Reachable' colums of the "IANA IPv4 Special-Purpose Address Registry" table at: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... The goal of RFC 7526 seems to be to discourage further growth of the 6to4 anycast network, but doesn't specify what should happen with existing 6to4 deployments (other than needing to be 'reviewed'). I personally probably wouldn't object to the removal of 'route: 192.88.99.0/24' objects from the RIPE-NONAUTH database, but some quick testing on my personal Internet connection shows 6to4 instances still ping and forwarding paths to 192.88.99.1 still exist. I know of some corporate ISPs that block 192.88.99.0/24, but clearly not every operator filters. What does this mean? Perhaps the topic of what to do IPv4/IPv6 transition prefixes in the RIPE-NONAUTH DB should be brought up in the RIPE IPv6 WG? Kind regards, Job (speaking as db-wg enthusiast)
oops, I replied about this to the previous thread, didn't realize it had split. https://www.ripe.net/ripe/mail/archives/db-wg/2021-July/007118.html -Cynthia On Wed, Jul 21, 2021 at 12:08 AM Job Snijders via db-wg <db-wg@ripe.net> wrote:
Hello db group,
On Tue, Jul 20, 2021 at 10:11:46PM +0200, Edward Shryane via db-wg wrote:
According to the implementation plan: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
if these ranges are not marked as "available" or "reserved" in an RIR's delegated stats, then it will be skipped, and I didn't find 192.88.99.0/24 in any RIR's delegated stats.
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
RFC 3068 was obsoleted by RFC 7526, a document that 'deprecates' 192.88.99.0/24. The whole thing is here: https://www.rfc-editor.org/rfc/rfc7526.html
Unfortuntaly, RFC 7526 is not entirely clear on what 'deprecation' means in context of for example the 'Forwardable' and 'Globally Reachable' colums of the "IANA IPv4 Special-Purpose Address Registry" table at:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia...
The goal of RFC 7526 seems to be to discourage further growth of the 6to4 anycast network, but doesn't specify what should happen with existing 6to4 deployments (other than needing to be 'reviewed').
I personally probably wouldn't object to the removal of 'route: 192.88.99.0/24' objects from the RIPE-NONAUTH database, but some quick testing on my personal Internet connection shows 6to4 instances still ping and forwarding paths to 192.88.99.1 still exist. I know of some corporate ISPs that block 192.88.99.0/24, but clearly not every operator filters. What does this mean?
Perhaps the topic of what to do IPv4/IPv6 transition prefixes in the RIPE-NONAUTH DB should be brought up in the RIPE IPv6 WG?
Kind regards,
Job (speaking as db-wg enthusiast)
Hi, On Tue, Jul 20, 2021 at 10:07:53PM +0000, Job Snijders via db-wg wrote:
Perhaps the topic of what to do IPv4/IPv6 transition prefixes in the RIPE-NONAUTH DB should be brought up in the RIPE IPv6 WG?
I think this is a good idea. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
In message <6C1149E8-E751-4863-BDCF-82C5D9D1CE5F@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
I will check why the routes you listed were not scheduled for deletion.
Thank you Edward. I suppose that it may be the case that some of route objects may relate to recent allocations (and thus I might have gotten it wrong in those instances) but the last-modified dates on most of the route objects I just posted seem to suggest otherwise, i.e. most have been in existance for quite some time now.
and a great many of them refer either to the 192.88.99.0/24 IPv4 block, which is apparently reserved by RFC 3068, or to some IPv6 block which is *not* clearly related to RFC 3068. I am frankly not sure what to make of any of these, but I do suspect that they are all invalid, because no RIR has assigned any of the relevant IP space to any resource member.
According to the implementation plan: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
if these ranges are not marked as "available" or "reserved" in an RIR's delegated stats, then it will be skipped, and I didn't find 192.88.99.0/24 in any RIR's delegated stats.
The additional information that Job Snijders posted about these oddities is both helpful and enlightening, but still leaves the question of the status of such route objects a bit ambiguous, I think. I personally have no preference or opinion whatsoever as regards to whether these specific route objects should go or stay. I'll be happy to defer to wiser heads than mine on this point. All I will say is that until such time as some RIR lays claim to 192.88.99.0/24 via its daily stats file, the relevant route objects will continue to show up in my automated analysis results.
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
I would tenatively say "yes" but if others think there is some value in preserving these route objects, then I can quite easily hack my analysis scripts to ignore these ones, specifically, in future. (Or alternatively, some helpful RIR could step up and "claim" the block in its daily stats file, which would also cause the relevant routes to disappear from my bogon analysis results.) Regards, rfg P.S. The way I wrote my anaylsis scripts, *all* route objects within the RIPE AUTH or NONAUTH data bases that refer to IPv4 and/or IPv6 addresses that are not claimed by any RIR in their daily stats file will pop out at the end of the analysis as "bogon routes". I mention this only because Edward talked about "other sources of bogon prefixes". Believe me, if there were any route objects in the RIPE AUTH or NONAUTH data bases that refered to, say, any part of 127.0.0.0/8 or 10.0.0.0/8 or any other RFC-reserved IP block, then I would have reported those here already. So it's really just this RFC 3068 stuff that is at issue. No other RFC- reserved ranges seem to associated with RIPE bogon route objects.
Hi,
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
With regards to that specific prefix I feel like that should absolutely be added given that it was also deprecated and terminated in the IANA registry in 2015. With regards to other bogons, I feel like at least for the prefixes that are listed as not globally reachable in the "IPv4 Special-Purpose Address Registry"[1]. I have not evaluated this in great detail though and this is just my initial thoughts. Are there any route objects that would be impacted by this change outside of 192.88.99.0/24? If the answer is no, then I would suggest that all non-globally reachable prefixes listed in the special-purpose registry be added to the bogon cleanup. P.S. Ronald, you probably want to at least exclude this from your script " 192.31.196.0/24 112 2018-09-04". :) [1]: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... -Cynthia On Tue, Jul 20, 2021 at 10:12 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Ronald,
On 20 Jul 2021, at 21:03, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
According to information given to me by Edward Shryane < eshryane@ripe.net>, the cleanup of bogon route objects which made reference to bogon IP address space should have been completed the night before last.
To be clear (apologies it was not), the outstanding route objects were deleted *last* night, not the night before last.
The cleanup job ran first on the morning of 30th June, the maintainers were emailed a week later on 6th July, and the route(6) objects were deleted two weeks after that (last night).
In summary, the job deleted 863 route(6) objects in RIPE-NONAUTH, except for 7 which were excluded.
We received two tickets from maintainers, asking to exclude those 7 route(6) objects from the cleanup, and we are currently in discussion with them.
The latest split files in https://ftp.ripe.net/ripe/dbase/split/ were generated this morning around 05:50 UTC so do not contain the deleted route(6) objects.
My latest analysis suggests that a few such route objects escaped the net and are still present within the NONAUTH data base. These route objects are summarized below. I'd appreciate it if others would take a look at these and tell me if they think that these route objects should or should not be present within the data base.
I will check why the routes you listed were not scheduled for deletion.
Note that both batches of bogon routes given below are really rather curious due to the fact that nearly all of the routes have the exact same last-modified date (2018-09-04)
I think this is because the NWI-5 implementation that created the RIPE-NONAUTH database for out-of-region route, route6 and aut-num objects was run on September 4th, 2018, and many of those objects have not been modified since then.
and a great many of them refer either to the 192.88.99.0/24 IPv4 block, which is apparently reserved by RFC 3068, or to some IPv6 block which is *not* clearly related to RFC 3068. I am frankly not sure what to make of any of these, but I do suspect that they are all invalid, because no RIR has assigned any of the relevant IP space to any resource member.
According to the implementation plan: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
if these ranges are not marked as "available" or "reserved" in an RIR's delegated stats, then it will be skipped, and I didn't find 192.88.99.0/24 in any RIR's delegated stats.
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
Regards Ed Shryane RIPE NCC
In message <CAKw1M3PPUM4qdwCOLgiY=GkuiNtKnM4S5UmrOzRphZOC3_QsTg@mail.gmail.com>, =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me@cynthia.re> wrote:
Are there any route objects that would be impacted by this change outside of 192.88.99.0/24?
Just 192.31.196.0/24, I think, based on my results so far.
If the answer is no, then I would suggest that all non-globally reachable prefixes listed in the special-purpose registry be added to the bogon cleanup.
I agree. This is -not- actually an issue at the moment... except for the very unusual cases of 192.88.99.0/24 and 192.31.196.0/24... but I suspect that everyone would agree that *if* there existed a route object in the data bases for, say, 127.0.0.0/8, most people would probably like to see that go away. So the default should be that any routes that exist to IANA-reserved IP blocks should get cleaned up along with the rest.
P.S. Ronald, you probably want to at least exclude this from your script "192.31.196.0/24 112 2018-09-04". :)
Yes, well, I did just notice that additional oddity yesterday, and I'm frankly a bit concerned about how this one will be handled. I mean I've skimmed the relevant RFCs (RFC 7534, RFC 7535) and it is quite clearly a Good Thing that someone is sinking this inappropriate and pointless DNS traffic, but as far as having a route object for this in the RIPE NONAUTH data base? Well, I'm not so sure about that. What happens when the RIPE NONAUTH data base goes away entirely one day? Will this whole "AS112 Project" start to malfunction horribly? All things considered, I think it would be best if some helpful RIR effectively "claimed" the 192.31.196.0/24 block, started putting the block into that RIR's daily stats file, and if the route object pertaining to it were moved to a stable and permament home in that RIR's AUTH data base. Until these steps or some other appropriate solution is implemented I think it will be best if my scripts keep on reporting this one as an open issue. Regards, rfg
On Wed, Jul 21, 2021 at 8:23 PM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote: [...]
All things considered, I think it would be best if some helpful RIR effectively "claimed" the 192.31.196.0/24 block, started putting the block into that RIR's daily stats file, and if the route object pertaining to it were moved to a stable and permament home in that RIR's AUTH data base.
APNIC publishes a daily file that reformats the information published in the IANA registries: http://ftp.apnic.net/stats/iana/delegated-iana-latest Perhaps that is what you are looking for?
In message <CAPfiqjaeaNBXKNEdq6kesPVBWbx3Kx-K24c8p6tYG3PqJU4wZA@mail.gmail.com> Leo Vegoda <leo@vegoda.org> wrote:
On Wed, Jul 21, 2021 at 8:23 PM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
[...]
All things considered, I think it would be best if some helpful RIR effectively "claimed" the 192.31.196.0/24 block, started putting the block into that RIR's daily stats file, and if the route object pertaining to it were moved to a stable and permament home in that RIR's AUTH data base.
APNIC publishes a daily file that reformats the information published in the IANA registries:
http://ftp.apnic.net/stats/iana/delegated-iana-latest
Perhaps that is what you are looking for?
Ummm... no, not really. I don't know exactly what the contents of that file are supposed to represent, but it is clearly -not- all just "IANA stuff". I am now doing a daily fetch of all of the RIR-specific stats files from all five of the RIRs and that seems to be the best guide to what is and isn't allocated to any & all actual RIR resource members. Regards, rfg
On Thu, Jul 22, 2021 at 3:18 PM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <CAPfiqjaeaNBXKNEdq6kesPVBWbx3Kx-K24c8p6tYG3PqJU4wZA@mail.gmail.com> Leo Vegoda <leo@vegoda.org> wrote:
On Wed, Jul 21, 2021 at 8:23 PM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
[...]
All things considered, I think it would be best if some helpful RIR effectively "claimed" the 192.31.196.0/24 block, started putting the block into that RIR's daily stats file, and if the route object pertaining to it were moved to a stable and permament home in that RIR's AUTH data base.
APNIC publishes a daily file that reformats the information published in the IANA registries:
http://ftp.apnic.net/stats/iana/delegated-iana-latest
Perhaps that is what you are looking for?
Ummm... no, not really. I don't know exactly what the contents of that file are supposed to represent, but it is clearly -not- all just "IANA stuff".
Maybe someone from APNIC can chime in and describe how it's composed. That said, if you want the IANA data you can grab a copy in multiple formats direct from their registries. They don't publish in the same format as the RIRs. I expect it's mostly because there's never been a formal request and don't want to start taking actions without a formal consensus to do so.
Edward Shryane via db-wg wrote on 20/07/2021 21:11:
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
it's had an interesting history, but as Cynthia points out, the 192.88.99.0/24 assignment is now terminated, so it's unassigned / unallocated address space and consequently the route objects should be deleted. 192.31.196.0/24 is active according to the IANA IPv4 Special-Purpose Address Registry, so it should stay there. Nick
Hi, On Tue, Jul 20, 2021 at 10:11:46PM +0200, Edward Shryane via db-wg wrote:
(To Ronald and the list) Should we add other sources of bogon prefixes (e.g. RFC 3068) to the implementation?
While Anycast 6to4 needs to die, it isn't fully dead yet. So routes for these two prefixes are legitimate. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering via db-wg wrote on 23/07/2021 14:54:
While Anycast 6to4 needs to die, it isn't fully dead yet. So routes for these two prefixes are legitimate.
the discussion is whether it's appropriate for the RIPE NCC to continue to publish route objects for this prefix, which is a different discussion to the announcements in the dfz. The route objects are documentation of policy. If the prefix isn't legitimate according to IANA or RIR allocations / assignments (and in this case, it definitely isn't), then the route object shouldn't be in the IRRDB. There's nothing stopping operators from continuing to announce the prefix. It would be better if it were left to die, but this is ultimately a choice of each individual operator. The same argument applies to the route objects for 2002::/16. Nick
I just want to add a +1 for what Nick is saying here. Also, it was terminated according to IANA over 6 years ago, so it is not really a recent depreciation. -Cynthia On Fri, Jul 23, 2021 at 5:54 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Gert Doering via db-wg wrote on 23/07/2021 14:54:
While Anycast 6to4 needs to die, it isn't fully dead yet. So routes for these two prefixes are legitimate.
the discussion is whether it's appropriate for the RIPE NCC to continue to publish route objects for this prefix, which is a different discussion to the announcements in the dfz.
The route objects are documentation of policy. If the prefix isn't legitimate according to IANA or RIR allocations / assignments (and in this case, it definitely isn't), then the route object shouldn't be in the IRRDB.
There's nothing stopping operators from continuing to announce the prefix. It would be better if it were left to die, but this is ultimately a choice of each individual operator.
The same argument applies to the route objects for 2002::/16.
Nick
Hi Ronald, I reviewed your list of routes as follows...
On 20 Jul 2021, at 21:03, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
According to information given to me by Edward Shryane <eshryane@ripe.net>, the cleanup of bogon route objects which made reference to bogon IP address space should have been completed the night before last.
My latest analysis suggests that a few such route objects escaped the net and are still present within the NONAUTH data base. These route objects are summarized below. I'd appreciate it if others would take a look at these and tell me if they think that these route objects should or should not be present within the data base.
Note that both batches of bogon routes given below are really rather curious due to the fact that nearly all of the routes have the exact same last-modified date (2018-09-04) and a great many of them refer either to the 192.88.99.0/24 IPv4 block, which is apparently reserved by RFC 3068, or to some IPv6 block which is *not* clearly related to RFC 3068. I am frankly not sure what to make of any of these, but I do suspect that they are all invalid, because no RIR has assigned any of the relevant IP space to any resource member.
NONAUTH / IPv4 routes (36): ---------------------------
41.217.128.0/19 37034 2018-09-04
The /19 is skipped as part of the range doesn't appear in any RIR delegated stats. 41.217.128.0/20 is reserved in AFRINIC 41.217.144.0/22 is reserved in AFRINIC 41.217.148.0/22 is allocated in AFRINIC 41.217.152.0/22 is reserved in AFRINIC 41.217.156.0/22 does not appear in any RIR delegated stats.
41.217.144.0/20 37034 2018-09-04
41.217.144.0/22 is reserved in AFRINIC 41.217.148.0/22 is allocated in AFRINIC 41.217.152.0/22 is reserved in AFRINIC 41.217.156.0/22 does not appear in any RIR delegated stats.
41.217.144.0/21 37034 2018-09-04
41.217.144.0/22 is reserved in AFRINIC 41.217.148.0/22 is allocated in AFRINIC According to the implementation plan, "If a prefix is partially "available" or "reserved" then it is also considered to be unregistered." So I think we should be deleting this route object (i.e. a bug), we will check the implementation.
41.242.84.0/22 37609 2018-09-04
41.242.84.0/22 is excluded (in discussion)
170.56.0.0/16 15854 2018-09-04 170.56.0.0/16 702 2018-09-04
170.56.0.0/16 is excluded (in discussion)
192.31.196.0/24 112 2018-09-04
IETF reserved block (skipped for now)
192.88.99.0/24 1741 2018-09-04 ...
Deprecated IETF reserved block (skipped for now)
192.107.242.0/24 394784 2018-09-04
deletion pending
204.144.127.0/24 40142 2018-09-04
deletion pending
205.166.145.0/24 394784 2018-09-04
deletion pending
NONAUTH / IPv6 routes (37): ---------------------------
2001::/32 1101 2018-09-04
... reserved by IANA (teredo tunneling), skipped
2001:4:112::/48 112 2018-09-04
reserved for AS112-v6, skipped
2002::/16 1101 2018-09-04 ... reserved for 6to4, skipped
2011:4188::/48 12880 2018-09-04
Typo? (as suggested by Gert on 13th June)
2c0f:f260::/32 36924 2018-09-04
deletion pending Regards Ed Shryane RIPE NCC
In message <74D5F6B9-5B52-418D-B639-8CE91F472B8A@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
I reviewed your list of routes as follows...
Thank you Edward for the detailed review and or sharing your results derived therefrom. Based on what you posted, I'll be making some adjustments to my scripts to try to exclude some of the stuff in the gray areas in any future anaylsis results. (My assumption and belief is that it may perhaps be of some value for me to re-run my analysis and post fresh results from time to time in the future, because things that aren't bogons today may become bogons tomorrow, and thus, route objects that look just fine today may not look so fine, say, in a month from now.) I am slightly perplexed about this one item you mentioned:
2011:4188::/48 12880 2018-09-04
Typo? (as suggested by Gert on 13th June)
So this one will be going away also? Regards, rfg
participants (7)
-
Cynthia Revström -
Edward Shryane -
Gert Doering -
Job Snijders -
Leo Vegoda -
Nick Hilliard -
Ronald F. Guilmette