RIPE 84 Address Policy Working Group Minutes

Session 1

Wednesday, 18 May 09:00 - 10:00 (UTC+2)
Chaired By: Erik Bais, James Kennedy, Leo Vegoda
Scribe: Matt Parker
Status: Draft

A. Introduction

Leo introduced himself and his co-chairs, James and Erik, and informed everybody that the session was being recorded.  He reminded the session that there was a Code of Conduct in place designed to make everyone feel welcome and treated with respect.  Leo asked for, and received, approval for the minutes from RIPE 83 and summarised the agenda for both sessions.

Leo introduced the first item of business for the session, selecting a new Working Group Co-Chair. He explained that Erik had stepped down from the role and had also nominated himself for re-selection.  There were no other volunteers.  Erik briefly introduced himself to the Working Group and was re-appointed as Co-Chair for another term. 

B. NRO NC Update

Sander Steffann, 6connect

The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/83-2022-05-18-RIPE-84-ASO-AC-Update.pdf

Sander presented the report from the Address Supporting Organization Address Council (ASO AC). He explained who the ASO AC are, what the relationship is with the Number Resource Organisation Numbers Council (NRO NC), what they do, how they are organised and who the current members of the council are. Sander spoke about Global Policy Development, explaining that the NRO has a Global Facilitator team which is tasked with helping people understand what global policies are and how they can be submitted.  Sander announced that Christian Kaufmann had been selected for Seat 10 on the ICANN Board for the 2022-2025 term.  Christian is currently Chair of the RIPE NCC board and has confirmed that he will not run again for the role at the end of his term to minimise any conflict of interest. 

Hervé Clement, Orange/ASO AC, remarked that the ASO AC will work on updating their operational procedures over the coming years.  

There were no questions.   

C. Policy Update followed by Q&A 

Angela Dall’Ara, Policy Officer, RIPE NCC

The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/54-RIPE-84-Policy-Update.pdf

Angela presented a summary of policy development within the five RIRs since RIPE 83, including topics such as transfers, RPKI and leasing of IP space.  She reminded the working group that the Policy Development Process is defined in a RIPE document (ripe-710) and is currently being reviewed.  Version 3 of the proposed draft has been published and is available for discussion, the community was encouraged to provide feedback to RIPE Discussion List before 27 May 2022. 

Angela reviewed the policy-related discussions on the mailing list since RIPE 83, including the stockpiling of IPv6 allocations and temporary assignments.  She also discussed the results of the RIPE Database Requirements Task Force and the resulting policy proposal in the RIPE Database Working Group.  

Jordi Palet Martínez, The IPv6 Company, commented that he is one of the authors of the non-leasing proposal and that it is also being prepared for the APNIC and AFRINIC regions. He explained that the policy proposal does not represent a change to the current policy but instead is a clarification of the existing situation.  

There were no questions. 

D. IPv6 Policy Goals Report from Community Team Followed by Discussion

Gert Doering, SpaceNet

The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/82-musings-0516-01.pdf

Gert explained that at RIPE 83 the WG chairs had asked for volunteers from the community to form a team to investigate whether an overhaul of the IPv6 policy is required.  Gert, along with Kurt Kayser and Sander Steffann, volunteered to form this team and proceeded with a full investigation of the history of IPv6 policy. They identified an underlying principle, that IPv6 should be easy to get, and that the policy should encourage IPv6 rollout. They also noted that aggregation is very important, and that conservation, whilst being less important than for IPv4, remains relevant. 

The team identified some friction in the requirement to justify and provide documentation for allocations larger than /29. They commented that it is a large step from requiring no documentation for a /29, to requiring extensive documentation for a /28 and questioned whether this could become a sliding scale where the amount of justification would increase with the size of the allocation requested. They also discussed the HD Ratio, commenting that it is seen as very complicated and could be simplified, or even removed entirely, in future revisions. 

There was some discussion of “special networks” such as Root DNS operators, Anycast DNS operators, IXP networks and other special cases.  The team felt that many of these use cases were still valid, but that it would be helpful to have them together in a single document rather than being distributed across several documents.  They also raised the topic of the different flavours of IPv6 space (Provider Aggregatable and Provider Independent), weighed the pros and cons of this approach and questioned whether the current compromise is still a good balance. Finally Gert spoke about aggregation, identifying several concerns whilst also acknowledging that enforcing routing policy is outside of the mandate of the Address Policy WG. He has passed their recommendations to the Best Current Operational Practices (BCOP) Task Force. 

Jan Zorz, 6connect and BCOP Taskforce co-chair, congratulated Gert on winning the speaking slot at the next BCOP meeting. 

Kurt Kayser joined Gert on stage. 

Raymond Jetten, speaking as IPv6 Working Group Chair, thanked the team for their work and commented that unfortunately there wasn’t enough time in the agenda to include this in the IPv6 session scheduled for the next day, but that the working group would provide some feedback.  Raymond also commented, this time speaking as a RIPE NCC Board Member, that the board does not have an opinion on IPv6 policy in general, but that they do have a responsibility to ensure the RIPE NCC staff are not overloaded, and this might be a reason for not liking a specific element of the policy. 

Sander Steffann, speaking as a community member, said that he thinks the routing BCOP was long overdue and that he strongly supports this approach. He also volunteered to help Gert with any further work that involved. 

Sander joined Gert and Kurt on stage. 

Rob Evans, Jisc, commented that ripe-399 (RIPE Routing Working Group Recommendations on Route Aggregation) exists which could be used as a basis for some of this work, but that it might need to be updated. Gert thanked Rob for reminding him of that document. 

Secondly, Rob explained that he has a small number of larger customers who often need more than a /48 and he is therefore concerned about the bits between /32 and /48.  He has found the justification of assignments larger than /48 to be onerous in the past and would like to see this improved.  Sander asked whether a more liberal definition of ‘end site’ would help?  Gert commented that he did not have this on the radar but that it merits further investigation. 

Maximilian Emig, speaking as a former IPv6 PI holder, said that he had heard frequent complaints that it was easier to get multiple /48 PI assignments rather than a single larger PI assignment which might be aggregated in the future.  He asked whether the team had any comments on this.  Kurt acknowledged that there was demand for this and Gert commented that it was good to bring the topic up to be added to the list. 

Jan Zorz, 6connect, spoke about a situation where people apply for IPv6 PI space to address the one or two racks that they have rented in a data centre. When they mention that they will also host a neighbour’s or partner’s server in the rack they find that their requests are rejected by the RIPE NCC because this is not permitted by the current policy text. Jan explained that he reluctantly tells these people to withhold information on their requests but does not feel that this is the best way to move forward. Sander replied that they should investigate this in more detail and perhaps focus more on the network than on the servers inside the network.

Mirjam Kühne, RIPE Chair, commented that she had enjoyed the discussion and thanked both the team and the Working Group for all the hard work that they have done analyzing the IPv6 policy so far. 

There were no further questions or comments.  

Session 2

Wednesday, 18 May 10:30 - 12:00 (UTC+2)
Chaired By: Erik Bais, James Kennedy, Leo Vegoda
Scribe: Ulka Athale

E. Registry Services Update

Marco Schmidt, RIPE NCC

The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/78-RIPE84-Feeback-from-RS-final.pdf

Erik Bais, A2B Internet, remarked that the sub-assignment ban for IPv4 PI was interesting as an option and might break further with what was currently being done for IPv6. He also asked if the slide shown in the presentation referred to mergers and acquisitions or when a company goes from one legal entity to another.

Marco said that it was a change of organisation structure.

Erik pointed out that the transfer policy does allow for mergers and acquisitions while the RIPE NCC needs to be updated. He asked what date the RIPE NCC considers for the 24-month holding period – whether it was the date the RIPE NCC is informed or the date of the merger – because this date also resets the holding period.

Marco clarified that the RIPE NCC uses the date on which it processes the merger.

Erik said that he disagreed although he understood the RIPE NCC’s position. He said that he had had difficult conversations with customers on this topic and it needs some review.

Gert Doering, speaking as a sponsoring LIR, said that he agreed with Erik on the date, and that it needs further discussion. He said that the holding period is intended to dampen certain effects and that is when the company is merged and not when the paperwork is completed. He then asked whether the PI space coming back to waiting list was when companies disappear and how that worked.

Marco replied that when the RIPE NCC finds out that a company has ceased to exist, it tries to find the legal successor and reach out to contacts. If there is no response and it appears that the resources have been abandoned, they are returned to the pool.

Gert said he appreciated the complexities for the RIPE NCC in dealing with these abandoned resources. He also said that speaking as a sponsoring LIR, it is not that easy to keep track of the names of companies that are their customers, because customers get renamed all the time. Erik agreed with Gert.

Marco said that it was indeed complicated and the original idea was that the sponsoring LIR would act like a registry. 

Peter Hessler, DENIC, said that he has received several temporary assignments in the past for events. One thing he has run into when requesting address space is the question of utilization, because with several end users, it’s hard to predict how many people will sit at a table and be in a particular VLAN. He interprets it as ensuring that at least 50% of the prefixes are properly utilized with a reasonable idea of how they should be allocated, which he believes is compliant with the requirements. He also added that he was aware that this was a slightly different interpretation than the one Marco presented. He said that an assignment size of less than a /24 was not useful as it couldn’t be announced. 

Marco said that there was no minimum in the current policy, and if someone needed just on IP, strictly speaking as per the policy, they should get a /31. 

G. Concept Policy Proposal - Remove Policy for Mandatory IPv4 PA Assignment Registration in the RIPE Database

Jeroen Lauwers, A2B Internet

There was a change in the order of discussions, and agenda point G was taken up before agenda point F. 

The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/81-Ripe-Policy-Proposal-IPv4-PA-Assignments.pdf 

Leo thanked Jeroen for stepping forward to volunteer to turn this recommendation that came out of the RIPE Database Requirements Task Force into a concept for a policy proposal. He asked the working group whether there were reasons to retain the existing policy or should a change be considered.

Gert appreciated that there were new proposals being brought forward by newer people in the community, even if he didn’t agree with the actual idea. He thought it was important to have newer community members. He said his disagreement was that he believes that the users of address space need to be documented regardless of whether it is the same company or multiple companies. He pointed out that for him as an LIR it made no difference whether he got two /25s or one /24 that he gives to customers as two /25s through the IRR. He said that it is the database that needs to be fixed and not policy issues. Changing requirements for old space and customer space complicates things without fixing the problem. He said that if the proposal was to stop registering personal data for administrative contexts because it is no longer useful for assignments he agreed with it, but not with its current form.

Jeroen thanked Gert for his insights and the additional information. 

Peter Hessler, DENIC, was concerned that two different problems were conflated. The underlying problem remained that you cannot make an assignment which is the same size as your allocation, which is very apparent in the case of a /24 because it is not appropriate to split it into two /25s. He pointed out that the same could apply to a larger allocation received in the past, and some artificial restrictions might not be reflective of the actual use of the address space. He felt that a policy in the working group was the wrong way to solve this issue. He agreed with Gert’s objections but thanked Jeroen for bringing the proposal and also stated his support for newer community members coming to mic.

Denis Walker pointed out that the RIPE Database Requirements Task Force is also examining the issue of making an assignment the same size as an allocation, but that it’s a technical issue rather than a policy issue. He felt that the RIPE Database Requirements Task Force didn’t look into the purpose of the RIPE Database in 2022, leaving the question of whether assignments need to be documented open.

He added that the deeper issue is what the purpose of the RIPE Database is, and why we have assignments documented in the RIPE Database.

F. IPv4 Waiting List

Erik Bais, Working Group Co-Chair

There were no slides, the video archive is available at:
https://ripe84.ripe.net/archives/video/791/ 

Erik proposed discussing the issue of IPv6 address stockpiling as highlighted by Marco Schmidt of the RIPE NCC, and whether the Working Group wants to make changes regarding policies concerning multiple LIRs. He asked the group several questions including whether the minimum holding time for address space needs to go up to five years from the current duration of two years or should those with multiple LIRs be excluded from the IPv4 waiting list. 

Peter Hessler, DENIC, said that as a new LIR a few years ago, they benefitted from the last /8 policy and that he felt strongly that providing address space to newcomers is a critical part of the current policy. He said that he had a deep hatred of transfers of address space from the last /8 policy. One idea was to forbid transfers of waiting list allocations – either the LIR would have to continue or return the address space. This might help counter the fact that it is economically beneficial to pay the fee for two years and then transfer address space.

Elvis Velea proposed keeping the last block for newcomers and that there should be a new system where if a company doesn’t have LIRs they move to the top of the list and the more LIRs a company has, the lower they drop on the list.

Erik pointed out that a system like this could get very complicated, and the RIPE NCC already vets membership applications to check the ultimate beneficial owner due to sanctions regulations. Therefore, why not simply scrap everyone who has an LIR from the waiting list. 

Kurt Kayser said that there needs to be some coordination between the RIRs, otherwise it could inadvertently create a competitive scenario in which one RIR becomes more attractive than another which could have a high impact on business.

Erik replied that there have been policy differences in the past between RIRs, but at this point he didn’t think competition between RIRs would be a big issue. 

Hans Petter Holen, Managing Director of the RIPE NCC, said that he was the RIPE Chair when this was last discussed and the RIPE NCC Executive Board had recently requested a recap of the developments. Without taking sides for or against the policy, it would be useful to get the policy proposal on the table so that the RIPE NCC can do an impact assessment. Regarding Erik’s suggestion that the RIPE NCC already checks for beneficial owners, it sounded nice in theory but there might still be manual workloads and a significant number of legal hours involved. He added that this policy discussion was important as there are several aspects that touch upon this such as shell companies, leasing etc. which need to be evaluated when deciding a new policy.

Wolfgang said that so long as the policy makes it possible to make a profit, there will always be people gaining from it, also as the policy development process is much slower and there is movement in prices for IPv4 addresses. It is difficult to set a policy that makes it impossible to make a profit. 

Erik said that the waiting list time is currently 18 months, after which and LIR receives an allocation, followed by two years of waiting before addresses can be transferred. The most friction is being caused by organisations requesting multiple LIRs, and newcomers, for whom the pool is intended, do not have any options. If this is what we want to fix, this is what we should focus on rather than the waiting list.

Wolfgang agreed and pointed out that the going price for an IPv4 address at the last physical RIPE Meeting was $20 and was currently about $50, meaning that a profit can be made by setting up a new company that has just one LIR, even if you have to wait for three and a half years. 

Jordi Palet said that is should be much easier for only real newcomers, like in other regions.

Harry Cross suggested having a priority queue for those who have never received address space and the potentially allocating it to others. That would link to checking ultimate beneficiaries to verify newcomers.

Denis Walker said that he felt the horse had already bolted, and there was no point in creating such a restrictive policy now that there is no address space left. It should have been done three years ago.

Elvis commented that the people who profit from IP addresses will find a way around any policy changes. They will create new companies if we try to find ultimate beneficial owner, which is a tremendous task, and fake their way to the top of the queue. 

Peter Hessler reiterated that just because people could abuse the system wasn’t a reason to not write a policy. Any malicious and fraudulent actors should be caught and potentially banned from other activities.

Erik agreed and added that although this might be hard, that was not a reason to not write the correct policy. Operations should align with the intentions of the policy and Working Group.

Denesh Bhabuta, UKNOF, said that he would repeat his advice from other Working Groups, which is to keep things simple. He asked why things couldn’t be sped up, as the group is looking at making a radical change.

Erik commented that the issue of multiple LIRs had been addressed very swiftly at the GM right after the initial /8 policy came in a few years ago. The logic at the time was that it would be harder to track activities if multiple shell companies were set up. However, the RIPE NCC’s current tools and the information received might be used similarly. He thought that issues would need to be addressed sooner rather than later, as there are still deregistered resources being returned to the pool and this could potentially cut the waiting list to a shorter time, maybe by as much as half.

Peter asked Denesh to clarify which process he thought was taking too long.

Denesh clarified that he was referring to the duration of the policy process.

Erik commented that a new Policy Development Process was under review, and that he would provide feedback on it. He then thanked the stenographers and closed the session.

 

 

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum