According to address policy, the experimental address allocations for RIPE RIS beacons have to be returned soon. This would mean we have to either discontinue the RIS beacons or request permanent allocations for them according to address policy. We are asking for community support to continue operating the RIS beacons at the current addresses and for support for the address allocations.
The RIS Beacons
The RIPE NCC operates routing beacons at more than a dozen locations in the Internet topology worldwide. These beacons are used by both academics and operators to study propagation of routes throughout the Internet. Since the routes from the beacons do not carry production traffic, they can also be used to test new functionality such as ROAs and the like .
The Address Space Used
Each beacon announces at least two prefixes: one "anchor" which is announced all the time and the beacon itself which is announced and withdrawn on a fixed schedule. This means that we need at least two routes at each beacon site. Due to prefix length filtering, any beacons using smaller prefixes than a /24 in IPv4 and a /48 in IPv6 would be of very limited use. Hence we are using the following addresses for RIS beacons:
The first IPv4 block is currently fully used. Two of the eight slots in the second block are used to announce test prefixes for RPKI. Only a fraction of the IPv6 block is used; this could be reduced significantly under current policies. For details and the beacon schedules, please see the "Current RIS Routing Beacons" page.
The Case for Permanently Allocating the Current Addresses
The address space for the beacons was originally allocated as an experimental allocation. According to current policy , experimental allocations can only be extended in exceptional circumstances. On the other hand, the beacons are not a short term project. Changing the addresses would break any long term data collection. An address change would also cause grief to other users of the beacons for whom we may not even know how to contact them.
The RIPE NCC registration services do not consider the RIPE NCC eligible for the IPv4 addresses because we use only 1 host address in every /24 block for carrying ping traffic and thus we do not meet the utilisation criteria in paragraph 6.3 of ripe-530 .
This of course disregards the fact that the purpose of prefixes announced by a routing beacon is not to carry traffic other than an occasional ping. The purpose is to originate a route that should propagate as far as possible in BGP. Thus we could argue that each /24 that is announced, is in fact fully utilised for the purpose of the assignment.
Furthermore the RIPE NCC registration services suggest that we reduce the IPv6 assignment to the actual number of /48s needed. Here routing diversity justifies an assignment as per current policy. We can hand back most of that /32 without harming the beacon functionality.
Rather than arguing with ourselves we will consult the RIPE plenary as per paragraph 5 of ripe-476 . We will request that the RIPE plenary approve " reasonable address space assignments to the RIPE NCC for the purpose of operating routing beacons ".
In order to support this request we solicit your support. You can make it known as a comment here or at the meeting.
Should we not be able to obtain the necessary address space assignments, we will have to discontinue the RIS beacons. This would also mean that our de-bogonising effort would loose its anchor prefix and be less useful.
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Sascha Lenz •
I do see the problem here and it's good that you raised the problem instead of ignoring it. I don't have any objections there though, all this is rather useful service to the members/community and should be continued. Do we just need to show rough consensus here or do we have to go through the PDP here and change policies? That's what i didn't fully get from the presentation.
Hide one reply
Daniel Karrenberg •
No new policy is needed. Just an application of ripe-476. I do not expect that routing beacons will spring up all over the place; there are enough of them already.