发生了什么变化
policy_chronology为空,未提供任何政策阶段、版本变更或事件级记录,因此无法确认RIR policy ripencc/2019-08发生了什么变化、变化方向或演进路径。
RIPE NCC · RIR 观察
从这里开始,逐项查看提案记录:发生了哪些变化、为何重要、各方提出了什么主张、立场如何演变、最终作出了什么决定,以及证据仍存在哪些缺口。
来源事实
究竟是谁影响了这场辩论?
BTW 分析
policy_chronology为空,未提供任何政策阶段、版本变更或事件级记录,因此无法确认RIR policy ripencc/2019-08发生了什么变化、变化方向或演进路径。
未提供讨论消息、参与者立场时间线、少数意见或未解决论点,且相关参与指标均为零,因此无法识别辩论的实质议题、利益冲突、阵营互动或共识形成机制。
现有数据既未记录讨论,也未记录正式决策事件或结果。消息数、参与者数、正式行动者数和活跃天数均为零,只能说明该数据集中没有可观察活动,不能据此认定政策已通过、被否决、被搁置,或现实中从未发生讨论。
top1、top5、top10消息份额、HHI和有效参与者数均为零,同时核心参与者和重复参与者计数也为零。这反映的是没有记录到可用于计算集中度的消息或参与者,而不是参与分布均衡,也不能证明不存在少数主体主导。
未提供政策事件、正式行动者、程序步骤或表决记录,因此无法识别提案在何处受到推动、阻断、修改或终止,也无法确定任何制度性或参与者层面的决策瓶颈。
Separate trust anchor for registry-created AS0 ROAs · Version 2 adds a dedicated trust anchor and TAL file for RIPE NCC's AS0 ROAs, so tools and researchers can distinguish registry-created records for unallocated or unassigned space from operational ROAs created by resource holders. Version 1 stated the registry's authority to create these ROAs but did not specify this separate distribution arrangement.
Only the RIPE NCC has the authority to create RPKI ROAs for address space not yet allocated or assigned to its members.来源事实 ↗
RIPE NCC creates all its AS0 ROAs under a specific Trust Anchor, and provides a specific Trust Anchor Locator (TAL) file. This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.来源事实 ↗
Revocation wording before an allocation · Version 1 explicitly allowed allocation only after the AS0 ROAs had been fully removed and were no longer visible in repositories. Version 2 retains the requirement to revoke the relevant AS0 ROAs when allocating space, but omits that explicit repository-visibility condition and the word 'beforehand'. Its opposing-arguments section still discusses a delay of at least 24 hours; this comparison does not turn that discussion into an adopted timing rule.
If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked beforehand. Address space can only be allocated once the ROA or ROAs with origin AS0 have been fully removed and are not visible in the repositories.来源事实 ↗
If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked.来源事实 ↗
Discussion of less-specific announcements · Version 2 adds an explicit limitation: a less-specific covering announcement can circumvent the AS0 ROA protection. The authors argue that a covering route spanning allocated resources would attract monitoring alerts. This is a qualified threat assessment added to the rationale, not a guarantee that monitoring prevents such announcements.
Given the state of today's RPKI infrastructure, there should be a period of at least 24 hours between the revocation of the ROA or ROAs and the notification to the LIR that a given prefix has been allocated to them. This might delay allocations considerably, unless a different procedure can be created.来源事实 ↗
The authors note that it is possible to circumvent the protection of the AS0 ROA through the announcement of a less specific covering prefix. However, it is thought that hijackers of unallocated resources are likely to try staying under the radar and by announcing a supernet which by definition also spans an allocated resource, will trigger alarms through the various DFZ monitoring services available (for example as available in the RIPE RPKI Dashboard)来源事实 ↗
Registry and validator processing costs · Version 2 adds the possible registry cost and validator processing burden of a large AS0 ROA set. It distinguishes the limited IPv4 pools described in the proposal from the potentially much larger IPv6 set associated with sparse allocation. These are the draft's operational concerns, not measured costs or a forecast that every validator will be overloaded.
Distribution through SLURM assertions · Version 3 replaces the proposed registry-created AS0 ROAs with a downloadable SLURM file containing AS0 assertions for unallocated and unassigned IPv4 and IPv6 space under RIPE NCC administration. It specifies a well-known URL and automated use by relying parties under RFC 8416. Version 2 instead separated the registry's ROAs under a dedicated trust anchor and TAL. This is a proposed distribution change, not evidence that either design was deployed.
RIPE NCC creates all its AS0 ROAs under a specific Trust Anchor, and provides a specific Trust Anchor Locator (TAL) file. This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.来源事实 ↗
The RIPE NCC will create a SLURM file containing assertions with origin AS0 for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator. The file will be available for download from a well-known URL published by the RIPE NCC, so that Relying Parties (the so-called Validators) will be able to, in an automated way, fetch them and make use of them as described in RFC 8416.来源事实 ↗
Relying-party choice and configuration · Version 3 explicitly makes use of the file a relying-party choice: a configuration directive can enable or disable processing, and users can incorporate the assertions or leave them out. The rationale also suggests CDN distribution and frequent updates. Version 2 described a separate TAL for distinguishing registry ROAs; it did not include this SLURM-specific configuration and distribution explanation. The proposal's claim of equivalent information does not mean all networks would choose identical validation policy.
This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.来源事实 ↗
Creating and publishing a SLURM file gives users the chance to decide if they want to use the information or not for their networks. Relying Parties can decide to incorporate all the assertions from this file, or they can be left out. The SLURM file could be distributed using a CDN, and it should be frequently updated to reflect the status of the unallocated and unassigned address space held by RIPE NCC.来源事实 ↗
Updating protection when resources are allocated · Version 3 requires the relevant AS0 entry in the SLURM file to be updated at the time space is allocated to a member. This replaces Version 2's requirement to revoke the relevant AS0 ROAs. The earlier opposing-arguments discussion of waiting at least 24 hours between revocation and notification is absent from Version 3; the new text does not establish how quickly every relying party will retrieve an update.
Cost concern shifts to relying-party memory · Version 2 discusses RIPE NCC's operational cost and validator processing time for many ROAs. Version 3 reframes this concern around relying-party software needing more memory to process many assertions. The IPv4-versus-IPv6 distinction remains: the draft expects a relatively limited IPv4 set and a considerable IPv6 set because of sparse allocation. Neither version supplies a measured capacity benchmark.
The addition of potentially a large number of ROAs covering all the unassigned and unallocated space might increase the operational costs for the RIPE NCC. It might also have an impact on the time needed by validators to process the data.来源事实 ↗
The addition of potentially a large number of assertions covering all the unassigned and unallocated space might increase the operational costs for the Relying Party software by requiring them to run using more memory needed to process all the data.来源事实 ↗
加载中
部分
最早收录: 1992年6月30日
最近收录: 2026年11月12日