Based in Amsterdam, Netherlands
Articles
Likes on articles
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.
• 5 min read
Proposed at RIPE 91 in the Address Policy Working Group and then further discussed in the Database Working Group, the reg-nr: attribute (NWI-21) has already been implemented ahead of RIPE 92, showing how quickly community input can lead to practical results. It adds official company registration nu…
• 6 min read
Our new fully-automated self-service form lets LIRs end sponsorship of Provider Independent (PI) resources instantly - cutting errors, easing the end-of-year rush, and improving follow-up.
• 13 min read
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.
• 4 min read
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.
• 6 min read
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.
• 4 min read
We’ve updated our IPv4 graph to tell the whole story about our remaining address pool.
• 4 min read
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…
Showing 7 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)