変更点
検証済みの政策年表が空であるため、政策文言、適用範囲、権利義務、または実施状態に何が変更されたかは特定できない。
RIPE NCC · RIR ウォッチ
提案ごとの記録はここから確認できます。何が変わり、なぜ重要だったのか、誰が何を主張し、立場がどう変化し、何が決定され、どの点で証拠がなお不足しているのかを追えます。
出典に基づく事実
実際に議論を方向づけたのは誰か?
BTW 分析
検証済みの政策年表が空であるため、政策文言、適用範囲、権利義務、または実施状態に何が変更されたかは特定できない。
討議メッセージ、参加者および立場記録が存在しないため、中心的な争点、利害対立、提案理由または反論の内容は特定できない。
記録されたメッセージ、活動日、正式主体がいずれもゼロで、政策年表にも決定記録がない。このため、討議が行われたか、また採択、棄却、撤回、延期その他の正式決定があったかは判断できない。ゼロ活動は、決定が存在しなかったことの証明ではない。
メッセージ数と参加者数がともにゼロであるため、上位1・5・10参加者シェア、HHI、有効参加者数、50%・80%コア人数のゼロ値は、参加が均等または分散していたことを示さない。測定可能な参加が収録されておらず、集中度を実質的に評価できない。
発言者、反復参加者、立場保有者、正式主体および活動日の記録がないため、議題設定、修正、合意判定または最終承認を支配した主体や制度的チョークポイントは識別できない。
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.
This might delay allocations considerably, unless a different procedure can be created.出典に基づく事実 ↗
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.
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.出典に基づく事実 ↗
The RIPE NCC will update the relevant entry in the SLURM file with origin AS0 at the time of allocating address space to one of its members.出典に基づく事実 ↗
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/06/30
最新の収録: 2026/10/09