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 current combination of RIPE policies and rules for RIPE NCC membership enable IPv6 stockpiling. And what might sound like an unlikely activity is not only happening, but is actually on the rise. Here we look at the trends and some of the potential consequences and ask where we go from here.
It was about one year ago that the RIPE community reached consensus on a policy proposal that introduced additional criteria for initial IPv6 allocations. We thought it was time to look back at the origins of this proposal and see how the change has worked out since.
The RIPE NCC has developed an additional interface for the RIPE community mailing lists – something that we hope will encourage more interaction and discussion among the RIPE community.
When re-designing www.ripe.net, we paid extra attention to how we can improve the interface for the Policy Development Process (PDP). This open and transparent process determines RIPE Policies, which govern the distribution and use of nearly all Internet resources in the RIPE NCC service region. Ou…
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.
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.
“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
“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)