Summary of Proposal
The RIPE NCC publishes statistics on inter-RIR IPv4 and ASN transfers (including legacy resources). It also publishes statistics for IPv4, IPv6 and ASN transfers within its service region. However, there is currently no mandate for the RIPE NCC to publish updates regarding who holds a legacy resource.
This proposal adds a requirement that the RIPE NCC publish all changes to the holdership of legacy resources in the existing transfer statistics.
In addition to introducing greater transparency, this policy change would also protect legacy holders from potential hijacks.
Policy Text
[The following text will update section 4.0 in the RIPE Policy Document “RIPE Resource Transfer Policies“ and section 1.1 in the RIPE Policy Document “RIPE NCC Services to Legacy Internet Resource Holders” if the proposal reaches consensus.]
a. Current policy text
RIPE Resource Transfer Policies
[…]
4.0 Transfer Statistics
The RIPE NCC will publish a list of all transfers. This publication shall occur on a monthly basis or more frequently if the RIPE NCC so chooses.
This list will contain information about approved changes. The following information will be published:
- The name of the offering party
- The resource originally held by the offering party
- The name(s) of the receiving party or parties
- Each subdivided prefix (each partial block derived from that original block) or resource received
- The date each resource was transferred
- Whether it was a transfer according to this policy or a transfer due to changes to an organisation's business structure (such as a merger or acquisition)
5.0 Attribution
This document is developed by the RIPE community.
The following people actively contributed by making proposals through the RIPE Policy Development Process:
Erik Bais
RIPE NCC Services to Legacy Internet Resource Holders
[…]
1.1 Definitions
[…]
Registry services
Services provided by the RIPE NCC in its capacity as a Regional Internet Registry, including the following and such additional services as may be identified from time to time as registry services:
- Maintenance of data relating to Internet Resources by the NCC in their Internet Resource registry;
- Access to these data for update by or on behalf of the respective holder;
- Public availability of registration data;
- Certification of these data; and
- Delegation of reverse DNS to the registered DNS servers.
b. New policy text
RIPE Resource Transfer Policies
[…]
4.0 Transfer Statistics
The RIPE NCC will publish a list of all transfers. This publication shall occur on a monthly basis or more frequently if the RIPE NCC so chooses.
This list will contain information about approved changes. The following information will be published:
- The name of the offering party
- The resource originally held by the offering party
- The name(s) of the receiving party or parties
- Each subdivided prefix (each partial block derived from that original block) or resource received
- The date each resource was transferred
- Whether it was a transfer according to this policy, a transfer due to changes to an organisation's business structure (such as a merger or acquisition) or a change in the RIPE Database to the organisation holding a Legacy Internet Resource.
5.0 Attribution
This document is developed by the RIPE community.
The following people actively contributed by making proposals through the RIPE Policy Development Process:
Erik Bais, Elvis Daniel Velea
RIPE NCC Services to Legacy Internet Resource Holders
[…]
1.1 Definitions
[…]
Registry services
Services provided by the RIPE NCC in its capacity as a Regional Internet Registry, including the following and such additional services as may be identified from time to time as registry services:
- Maintenance of data relating to Internet Resources by the NCC in their Internet Resource registry;
- Access to these data for update by or on behalf of the respective holder;
- Public availability of registration data;
- Certification of these data;
- Delegation of reverse DNS to the registered DNS servers; and
- Transfer services as per RIPE Resource Transfer Policies. Any change in the RIPE Database updating the organisation holding the Legacy Internet Resource can only be finalised once the RIPE NCC has received and verified a written request signed by authorised representatives of both the current holder and the new holder.
Rationale
a. Arguments supporting the proposal
- Providing complete statistics about IPv4 transfers and updates to the holdership of legacy resources would clearly show the whole picture of a young, unpredictable and volatile transfer market. We currently see only partial information and it is difficult to understand the real dimensions of the size and number of IPv4 transfers.
- Over the past few years, this update has been requested by everyone analysing the IPv4 marketplace and presenting at RIPE, ARIN or APNIC conferences. The RIPE NCC already publishes statistics on inter-RIR transfers and adding this last bit (updates on who holds legacy resources) would be consistent with the community’s requests around transparency and consistency.
- In order to identify all legacy changes, a confirmation will be sent to the RIPE NCC to finalise the process (currently this is only checked for legacy resources that have a contractual relationship with the RIPE NCC or sponsoring LIR). This verification requirement does not impact the transfer of legacy resources or the updates in the RIPE Database. It only adds an additional step to increase the registration quality.
- This policy proposal protects both old and new legacy holders from hijacks. If a maintainer is hacked and details of the resource are changed so that a resource appears to belong to a hijacker, the change would be signaled by the RIPE NCC and potential buyers would be more careful if they could see that the change had not been finalised or verified by the RIPE NCC.
- The proposal improves consistency between the RIPE Database and the RIPE NCC delegated files. Currently if legacy holders update the RIPE Database without informing the RIPE NCC, the delegated files are not updated. This leads to inconsistencies in the country code shown in the RIPE Database versus the delegated extended files.
b. Arguments opposing the proposal
- Legacy holders might not want their RIPE Database updates to be published because they don’t want to be in the spotlight.
- The proposal creates extra work for the RIPE NCC to verify a RIPE Database update on an organisation holding a legacy resource
- Legacy holders might avoid updating the RIPE Database so they don’t have to go through the process of verification.