Multiple LIR Accounts: Looking Back and Thinking Ahead
• 13 min read
Why a feature introduced for a handful of members became one of the RIPE NCC's most complex operational challenges.
Marco Schmidt
Based in Amsterdam, Netherlands
8
Articles
269
Likes on articles
Based in Amsterdam, Netherlands
Marco Schmidt is the Manager of Registration Services at the RIPE NCC. He is responsible for overseeing the registration and maintenance of Internet number resources in the RIPE NCC's service region. He also manages the implementation of accepted policies in RIPE NCC procedures and operations. Marco first joined the RIPE NCC as an IP Resource Analyst (IPRA) in the Registry Services department, where he worked for five years. In that role, he gained valuable experience in evaluating IPv4, IPv6 and Autonomous System Number requests while providing support to the RIPE NCC membership. Later, he became the RIPE NCC's Policy Development Officer. In this position, he supported and drove the RIPE community's Policy Development Processes (PDP) both externally and internally.
The State of IPv4 and the Evolving Transfer Landscape
• 2 min read
The second in our series of IP reports explores the evolving role of IPv4 transfers as a necessary mechanism for managing address space in a post-exhaustion environment, alongside broader trends in availability, pricing, and usage. The report also highlights the operational and policy context in wh…
How to Get IP Addresses for Your Network
• 5 min read
Our new report provides network operators and businesses with an overview of the various options available for acquiring IP addresses today.
Country Codes in the RIPE Database
• 6 min read
Country codes in the RIPE Database serve a purely operational purpose. Nevertheless, questions can arise when defining which country code to use or what the code means. Let’s look into how country codes are maintained in the Database.
More Details on the ‘Voluntary Registry Lock’
• 5 min read
We have implemented a temporary feature for any members and other resource holders concerned that they might be forced to transfer their IP addresses to another party due to threats or coercion. This article explains how this feature works, what it does and does not prevent, and who can activate it.
Showing 4 article(s)
“Thank you very much for the research. I would like to share my opinion on the conclusions made at the end: In fact, the accumulation relates only to 2 (or 3?) real members (SC and CY). Most likely, the two SC members actually represent one person (this needs to be investigated based on the information about the initial transfers). The other members received their blocks a long time ago, and they were originally large (as seen from the number of allocations). The described problem with the load on the RIPE team is also true but only partially. The highest activity occurred once when member SC transferred their “assets” from RU to SC and when CY gathered everything under one account. How many accumulation activities (transfers) have there been since then? How does this activity compare to IPv4? The last 5 points are equivalent to IPv4, which already has an established rental market. Is anyone asking the same questions about IPv4?”
Hello Andrejs, Thank you for your feedback and questions. Our research showed that the top 10 stockpiling members are spread across several countries. Additionally, most of them have recently received numerous IPv6 allocations, primarily through transfers. For accumulation activities, you can get some indication from our IPv6 transfer statistics, which lists all IPv6 allocation transfers, including the offering and receiving parties. https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv6-transfer-statistics/ Comparing this activity with IPv4 requires taking into account several differences, especially the time component. The RIPE NCC currently provides a /24 IPv4 allocation to new LIRs only after a waiting period of 16 to 18 months, while all LIRs qualify immediately for a /29 IPv6 allocation without needing to supply any additional information. Further IPv4 can only be transferred after a holding period of 24 months, while no such limitation exists for IPv6. This results in much more rapid activities with IPv6, where allocations were sometimes requested and then transferred within a few days.
Hello ExSiXXsuser, Neither the RIPE IPv6 policies in the early 2000 nor the current IPv6 policy contain a specific recommendation or mandate for LIRs to assign static prefixes to customers. The current IPv6 policy mentions the minimum value of a /64 but makes no comments about static or dynamic assignments. https://www.ripe.net/publications/docs/ripe-684#assignment You might be interested to know that currently the RIPE BCOP TF is working on a document that seems to deal with situation like yours http://www.internetsociety.org/deploy360/wp-content/uploads/2017/03/draft-IPv6pd-BCOP-v1.pdf Maybe you are interested to join that discussion? Marco Schmidt Policy Development Officer RIPE NCC
Showing 2 comment(s)