Wednesday, 29 November 2023 09:00 - 10:30 (UTC+1)
Chairs: Erik Bais, Leo Vegoda
Scribe: Alun Davies
Status: Draft
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/66-RIPE-87-Address-Policy-draft-2.pptx.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1182
Erik Bais opened the session, introduced the Working Group Co-Chairs and thanked the Stenographer and Scribe. The minutes from RIPE 86 were approved.
[No presentation slides]
The recording is available at:
https://ripe87.ripe.net/archives/video/1184
Erik noted that as James Kennedy has stepped down as Working Group Co-Chair, a call for volunteers will go out to fill his place. In the meantime, Alex le Heux has volunteered to help cover WG Chair duties.
Mirjam reminded the room that there is a process in place for RIPE WG Chair selection, and while Alex le Heux is stepping in for now, the process will be followed for picking a new chair to replace James.
Sander Steffann
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/71-ASO-AC-Report-RIPE-87.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1186
No questions.
Marco Schmidt, RIPE NCC
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/73-RIPE87-Feeback-from-RS-final.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1187
Gert Döring (SpaceNet AG) noted that obtaining an IPv6 allocation should be easy to align with the IPv6 policy goal of not hindering IPv6 adoption. He noted confusion created around the distinction between a member and an LIR and that this needs clarification. The focus should be on making obtaining IPv6 allocations easier for LIRs.
Elvis Velea (V4Escrow, LLC) asked via chat if it might be possible to automate v6 requests. Marco responded that the RIPE NCC has to perform due diligence on reach request - e.g. in relation to sanctions, etc. Always a particular workload is required. Erik asked, if those checks are done already, is there an option for the RIPE NCC to provide a button: "I would like to request my initial v6 prefix"? Marco said this is something they're looking into.
Silvan Gebhardt (Openfactory) noted that, regarding the LIR hoarding of 250 PA blocks, the issue might be addressed by reviewing the policy on /48 PI blocks. Changing this policy would likely decrease sub-allocations of PA blocks, suggesting a possible reason for the hoarding. Marco thanked him for the comment.
Elvis asked if the RIPE NCC sees companies requesting temporary /24s for 'unreal' work. Marco responded there is another policy that provides checks on this, and seems to work well.
Randy Bush (RGnet OÜ) noted, as the ghost of Christmas past, that 16‑bit ASNs once seemed infinite, and we're now treating IPv6 as if the address space is infinite. There's no fixed number he's known we haven't run out of.
Alex Le Heux (Tucows Inc/Ting Fiber) asked how many requests are 16-bit. Marco said they see about the same for 16 and 32.
Wessel Sandkuijl (Prefix Broker BV) asked via chat if hoarding of v6 is still happening at the same rate as two years ago. Marco responded it's growing still.
Rinse Kloek (Kindes / Delta Fiber) pointed to difficulties in larger blocks than a /29. Clear plans/proposals do get rejected. It's too hard for companies of a certain size to get a bigger block. Marco pointed out this will be discussed more in the next session.
Marco thanked everyone for their input and closed the presentation.
Angela Dall'Ara, RIPE NCC
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/74-RIPE-87-Policy-Update.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1189
No questions.
End of the first session.
[No presentation slides]
The recording is available at:
https://ripe87.ripe.net/archives/video/1191
Leo Vegoda started discussing the purpose of IPv4 assignment registration in 2024. He pointed back to the 1996 definition focusing on tracking address space use, operational contacts, and studies of address allocation. The current terms and conditions, over a decade old, added law enforcement and legal notifications, primarily for dispute resolution. Leo emphasised the need to assess and potentially update the purpose to align with current needs and changes in the world. He invited opinions and questions from the community to inform the discussion on the upcoming policy proposal after the coffee break.
Gert Döring stated we haven't got a good enough understanding of what the Admin C and Tech C are good for today. There used to be more clarity for some cases, but changes in administrative and technical aspects since 1996 have blurred roles, especially in cases where customers delegate services to data centres. He highlighted the ongoing discussion as a positive step toward finding solutions.
Peter Koch (DENIC eG) suggested reviewing the task force report for insights into the Database's purpose. He highlighted a distinction between the T&Cs and documents like RIPE-136, noting the complexity of different data sets entangled in the database. He emphasised the evolving need for registry and operator cooperation, signalling a need for further research into the issue.
Leo asked the room: If you have a PA allocation and you make an assignment to a customer, what proportion of those customers would be able to respond usefully to a contact from someone at another network?
Harry Cross suggested that the answer will vary depending on whether you ask for a residential or corporate network.
Gert noted the challenge of defining Admin C and Tech C roles. He emphasised that, for their network in 2003, a significant percentage of customers were unfamiliar with technical matters and would approach them for assistance with emails from unknown sources. Tech C should be someone capable of addressing technical issues within the network. But there's less clarity around Admin C and when and why people would contact them. There's a need for consensus on the use and content of Admin C emails, per the policy's customer-side focus.
Erik Bais, speaking from an ISP perspective, noted that after the IPv4 run-out, the requirements for obtaining new IP space changed. Assignments in the database are likely registered by the ISP, which follows up on abuse issues. He believes that, as a resource holder, LIRs should contact the ISP in most cases, and direct abuse requests are rare, involving less than 2% of customer space. He suggested focusing on the 2% who are knowledgeable and willing to cooperate rather than expecting all information to be at the same level. LIRs should be advised to concentrate on allocation information managed by the RIPE NCC for effective resource management.
Leo highlighted the importance of considering the perspective of data users in the database. He referenced feedback from Europol, emphasising the data's utility to them and urged understanding the goals of those making contact and encouraged Europol to provide written comments for broader discussion on the Address Policy Working Group mailing list.
Raymond Jetten, representing Eliza in Finland, shared insights as an operator. He highlighted the challenge of varying technical knowledge among their customers, many of whom outsource technical issues to companies, some located in India. Raymond argued that it wouldn't be a practical solution if law enforcement contacted these companies directly. Instead, Eliza uses Admin and Tech C for themselves, allowing quicker contact with the right person by handling it as the operator who provided the connection and technical support.
Gert acknowledged a difference in contact levels, noting that at the allocation level, the current Admin C represents the CEO with a contract with the RIPE NCC, while Tech C is the technical team. However, at the assignment level, there are numerous questions and uncertainties.
Leo concluded the discussion by encouraging participants to share their thoughts on using the contact information for assignments in the RIPE Database and the effort involved in maintaining IPv4 assignments on the mailing list. He suggested finding a balance between effort and utility in this work and concluded the session.
End of the first session.
Wednesday, 29 November, 11:00 - 12:30 (UTC+1)
Chairs: Erik Bais, Leo Vegoda
Scribe: Ties de Kock
Status: Draft
Leo Vegoda
The recording is available at:
https://ripe87.ripe.net/archives/video/1194/
Leo Vegoda opened the second Address Policy Working Group (WG) session and re-introduced the policy development process.
Jeroen Lauwers, A2B Internet, and Tore Anderson, Redpill Linpro
The presentation is available at:
https://ripe87.ripe.net/presentations/75-Add-AGGREGATED-BY-LIR-status-for-IPv4-PA-Assignments-2023-Rome.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1198/
Jeroen Lauwers, A2B Internet, re-introduced his and Tore Anderson’s proposal to introduce the AGGREGATED-BY-LIR status that is present in the IPv6 policy in IPv4 policy. The goal is (1) to improve assignment coverage in the RIPE database, (2) to reduce work for the LIR, and (3) to improve the alignment between IPv4 and IPv6 policies. Jeroen summarised the origin of the proposal, the discussion phase, and the impact analysis.
Tore Anderson, Redpill Linpro, then continued the overview of the impact analysis results and mentioned that there is no significant impact. However, there is a note in the legal review that the LIR needs consent before putting personal data in the RIPE Database. This is not relevant to this proposal perse, but relevant to keep in mind when changing the contact registration criteria. Finally, he discussed the differences between the proposed IPv4 and IPv6 policies.
Gert Döring, SpaceNet AG, said that he refrained from commenting but emphasised the need to address arguments from the mailing list explicitly because the PDP requires this. Arguments need to be answered regardless of whether one agrees with them or not. Gert asked the authors to go back and reread the comments. If the outcome is that the WG needs to sort the ADMIN-C and TECH-C definitions first, that is one of the possible outcomes.
Tore said and offered to send on the list that in the current proposal, throughout the aggregated assignment, the ADMIN-C and TECH-C must be consistent. If they accept the current policy, an assignment in Rome and an assignment in Milan cannot possibly have the same ADMIN-C because they are in different locations and need local staff in each location registered in those two unaggregated assignments. Then, according to the policy text, the authors are proposing, these two assignments cannot be aggregated because they do not have consistent contact details throughout the aggregated assignment.
Gert acknowledged that Tore’s point is technically correct. But he pointed out that this makes the policy obsolete, because if anyone is technically required to have different ADMIN-C’s, they cannot aggregate.
Tore clarified that this only holds if they accept that ADMIN-C is mandated by policy. Then, this has implications for more than the IPv4 policy, such as the IPv6 policy where AGGREGATED-BY-LIR is already a fact. Additionally, Tore mentioned that this definition of ADMIN-C has to do with the location of the assignment. In some cases, such as a managed data centre, none of the customers have actual access to that location, only the data centre provider/LIR has access. In that case, which happens to be the situation Tore is in, it would be appropriate to put the corporation staff as the ADMIN-C for the customer assignments. In that case, they can aggregate. There is also the case for individuals, where there is explicit permission to replace the contact information with that of the LIR, so those could also be aggregated.
Angela Dall’Ara, RIPE NCC Policy Officer, thanked Tore and Jeroen for introducing the proposal. Angela clarified that under the last modification of the policy, the limitation of assigning a /48 is not so strict anymore. The policy now requires documenting the reason for an assignment larger than a /48 for a single site. The utilisation of an allocation must be checked for the request of a subsequent allocation, but they do not need to request the RIPE NCC’s approval for a more extensive assignment. However, in the case of an audit, they should be able to justify why this assignment for each end site is necessary.
Elvis-Daniel Velea, V4Escrow, explained the rationale behind AGGREGATED-BY-LIR in IPv6. It was made to aggregate multiple similar assignments into one large object. In IPv6, people no longer connect one customer with one IP address, they assign up to a /48 for a customer with no questions asked. AGGREGATED-BY-LIR makes sense in IPv6 when they make a lot of assignments that have (basically) the same size and maybe even the same designation (e.g. customers for DSL, fibre).
Elvis questioned why wouldanyone would want to aggregate by LIR in IPv4 and remove the assignment size and why they would create that aggregation, not an assignment. Elvis also questioned the difference between an assignment of /24 with a description for ‘customers of various sizes’ over an object with the status AGGREGATED-BY-LIR.
Tore clarified that the policy does not allow a single assignment to multiple customers, neither in IPv4 nor in IPv6. In IPv4, there is a narrow exception when all the assignments in the aggregated assignment are used only for connecting to the ISP (i.e. point-to-point links). If used for something else, this exception cannot be used. This exception models a single assignment to multiple customers. AGGREGATED-BY-LIR models multiple assignments to multiple customers. We could have expanded what is permitted by the assigned PA status, but since AGGREGATED-BY-LIR is already present in IPv6 policy, they thought it made more sense to bring parity to policies and have the same thing in both places.
Leo read a comment from Peter Hessler, Globalways Gmbh, who commented that [for] the IPv4 version of AGGREGATED-BY-LIR if one was to use the assignment size attribute, would that refer to the number of addresses assigned or a CIDR size.
Tore answered that it is undefined in the proposal. In their impact analysis, the RIPE NCC proposed to make the assignment size attribute optional. But the definition has not been mentioned, whether it is the number of addresses or prefix length.
Angela added that this is open to a community decision. The syntax of assignment size is a number referring to the sub-net in IPv6 that is distributed to each assignment in AGGREGATED-BY-LIR, but thinks that this can be changed if decided for IPv4.
Leo read a comment from Gamma Storey, Gamma Telecom Holdings LTD. Gamma commented that he sees the reason and objectives Tore and Jeroen are trying to achieve. However, he does not follow the choice between PA assignment registration versus aggregated and how this will be consistent between LIRs. Gamma asked if there is an expectation of consistency of approach or if it is down to how each decides to consume the policy.
Tore replied that this was up to the LIR. The new status is in no way mandatory, just like in IPv6. LIRs can still register every single assignment individually if they prefer. They can include any amount of contact information or other optional attributes they want to include in those assignments. If they are an LIR, they can completely ignore this proposal. However, if they want to aggregate a bunch of assignments with the same purpose and contact information and think that is more convenient, they can do that. It is up to the LIR whether they want to use this new status.
Erik Bais thanked everyone for participating and asked for further discussion to be moved to the mailing list.
Leo Vegoda, Address Policy Co-Chair
The presentation is available at:
https://ripe87.ripe.net/presentations/83-IPv6-allocations-nibble-boundaries-HD1.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1200/
Leo introduced the topic by mentioning that during the period between RIPE 86 and RIPE 87, the WG had several interim sessions where IPv6 policy improvements were discussed. Now that they have proposals, the WG should focus on one proposal at a time. Leo wanted feedback on what areas need priority first and the scope of potential proposals. The proposals can be large or simple initial approaches that can be improved later.
Jan Žorž from 6connect discussed a plan to simplify IPv6 allocations to clarify processes. The idea was to align allocations to the nibble boundary. Distributing comfortably enough space results in easier addressing plans.
Sander Steffann from 6connect then continued with a further plan and proposed simplifying the HD ratio by replacing it with a table. From there, he recommended using round numbers and not being too precise. Finally, he progressed in not using prefix sizes but counting end sites to incentivize uniform /48 allocations.
Gert Döring, SpaceNet AG, then provided the counterargument by discussing the evolution and challenges of IPv6 address allocation policies. Initially, every customer was allocated a /48, but concerns arose about potential IPv6 exhaustion. A mathematical analysis by Geoff Huston suggested that with widespread allocation of /48s and users having multiple ISP accounts, IPv6 could run out. This led to a policy change allowing ISPs to assign up to a /48s at their discretion, with a nudge towards /56s.
Most broadband ISPs now opt for /56s, complicating interactions with the RIPE NCC. The policy states that allocating a /48s counts as 256 /56s, but there is still confusion over how to account for different allocations when reporting to the NCC.
Gert suggested keeping allocation size flexible and allowing ISPs to choose between /48s and /56s. He acknowledged the complexity of counting customers for RIPE NCC reports, as the space required varies depending on the prefix size allocated. He suggested clarifying the policy, making it explicit that ISPs can assign /48s and, for reporting purposes, consider one /48s as equivalent to 256 /56s given out.
Gert thought this approach balanced the mathematical constraints with the need for clear and practical guidelines for ISPs and their reporting requirements. However, this meant they could not just count customers because this would result in too much or too little space. Gert concluded that Jan wanted an easy solution that counts customers and that the math does not permit this.
Jordi Palet Martinez, the IPv6 Company, shared that he agreed with the proposal, not counting the size of the prefix but counting the number of end sites. He disagreed with the math done by Geoff Huston. Jordi asked if the discussion on this topic needed to end before moving on to other topics.
Erik clarified that this was one of the topics they wanted to discuss. There are other options that we would like to discuss during this session. This group just had a couple of slides to clarify their position. This is not a decision at this moment. The idea of the chairs was to get a feeling of which topic is most relevant to the room and most interesting for the WG.
Gert Döring shared some math on allocation sizes he did and mentioned that we could afford to give every LIR a /24 but not a /22 or a /20.
Peter Hessler, Globalways, commented that he liked the concept of nibble boundaries. It makes things easier from the operational perspective. He shared that he had no strong opinion on HD ratio vs /56s vs number of end sites, except that whatever result is chosen, it needs to consider the network size given to the end customers. Giving out /40s uses up an allocation much more quickly than /56. This must be part of the justification for getting more, or a larger, address space.
Jordi shared that there is a difference between the RIPE NCC and other [RIR] regions and thinks that means that it is extremely difficult to believe that a proposal like this could work in other regions. In other regions, the membership fee is based on the number of addresses. Based on this, Jordi thinks that the case of a /20 for every LIR in the world is not a problem because not all RIRs will work the same.
Gert clarified that he was analysing the number of LIRs in the RIPE region. Jordi said that RIPE can request additional /11s from IANA. Gert further clarified that his analysis was based on RIPE receiving a /6 from IANA, and a limited number of /6s exist. Jordi interjected that there are /3s in IPv6 as well. Gert continued, saying that if they say in the first 001, they can do this. If they consider going to the next form of prefix, the discussion is much larger. Jordi said this is not a real problem – there are seven additional /3s. Leo, based on his experience in the IANA team, said there are 512 /12s in the current /3. Leo did not want to take a position on what to do, but that answers how many /12s we have.
Urban Suhadolnik shared their personal opinion that they like the nibble bounding. However, they think ISPs and other network designers apply many bad practices when giving IPv6 to end customers.
Sander Steffan reacted by saying that there are two sides to that. First, the policy should not limit ISPs from doing the right thing. Second, the BCP task force has a big part in educating.
Urban followed up by saying he does not want ISPs to do the wrong thing. He saw that some ISPs already do not follow policies, such as the policy that you can reserve more /48s or more. That is not followed.
Erik Bais said they will have a complete discussion on the mailing list on this topic.
Leo Vegoda shared three comments from MeetEcho that he quickly shared.
Elvis-Daniel Velea commented that he loved the new HD ratio as it looks simple and clear. Rob Evans from Jisc commented that not every ISP is a massive broadband provider and that some provide connectivity to large multi-campus educational institutions and that one end site/customer might need more than a /48. Elvis responded to that comment by saying that in that case, the tool of sub-allocations can be used.
Leo Vegoda, Address Policy Co-Chair
The recording is available at:
https://ripe87.ripe.net/archives/video/1204/
Tobias FIebig from MPI-INF then presented an issue with the PI allocation policy/assignment policy. The issue is that it is close to impossible to get anything bigger than a /48, mostly rooted in the somewhat unclear definition of an end site. What Tobias would propose is to go to nibble boundaries.
Jordi said that two years ago they presented a policy to the chairs to review all the IPv6 policy. He was told to wait, because some discussions were scheduled, and in fact there were interim sessions. After the interim sessions Jordi waited a little bit, while working on the policy proposal that was never published and asked in the mailing list for other people to participate. Three people were willing to participate, and two responded to Jordi's emails. Those were Rinse and Tobias. They prepared an updated review of the full policy proposal – effectively a rewrite. The policy proposal was looking for some of each of our real needs [unclear] – the easy part. The PI thing, very close to what Tobias already explained. As Rinse mentioned earlier, problems were getting an allocation, on which Jordi got feedback from multiple community members.
The group was working on three main ideas, which were covering all the points discussed in the interim sessions: (1) changing initial and subsequent allocations, (2) change of the PI, (3) removing the HD ratio. They were not looking into the same as was presented before by Jan, Sander, and Gert, but looking at something different. Jordi thought their idea was a very good one. The perspective of Jordi, Rinse, and Tobias was to look at the same criteria as IANA has towards the RIRs, which is 50% utilisation. If they have 50% utilisation, they get more space. The group also investigated the nibble boundary, but was not fixing how many sites, or how many assignments are needed for each step in the nibble boundary.
Jordi complained that the proposals they have already submitted should have been published. Jordi agreed with the chair's suggestion that a single proposal for everything is too complex to discuss. As a result, the authors split the proposal into three parts and submitted two of those. One was the allocation part; the other was the PI part. They decided the rest, which is more editorial, would come at the end.
Jordi did not mind what order they would work on, but he said that according to the PDP if somebody submits a proposal, it should go through. And this did not happen. Jordi hoped that this discussion would help us get towards the correct use of the PDP and have those proposals published. Jordi proposed to stagger the proposals, with one proposal starting the second phase (e.g. discussion), and at that point, start the next proposal because he understands that the initial discussion is always more energetic, and from there on, there will be less and less input on the mailing lists.
Erik Bais said that in the Address Policy, they encourage people to discuss and get the feeling of the WG at the meeting here. This is also why they structured the meeting this way and have asked not to submit a full proposal with all the changes. It [the goal of the discussion] is also to prioritise what is important for the WG to start with and, based on that, move forward.
Erik's goal at the end of the session was to get a feeling from the room of which parts the WG wanted to start with. Afterwards, as Jordi suggested, and as was the intention of the chairs, process the other parts a couple of weeks later so the proposals do not collide, resulting in overlapping discussions.
Erik Bais suggested starting with the proposal from Sander, Gert, and Jan. However, Erik would like to get feedback from the room, whether they start with the one from Tobias or another and take it from there.
Jordi said he did not think the PDP was being followed. On 28 October 2020, Jordi submitted a proposal to solve those problems. Jordi said he was still waiting for confirmation because the chairs told Jordi that they would not start this proposal on the mailing list but would discuss it on the mailing list [instead]. He then continued that this was not discussed on the mailing list.
Gert Döring said that since the chairs asked for feedback on which order to start with, Gert thinks that the WG should start with Tobias's proposal. Gert thought that people who could not get big blocks under the current policy were an operational, procedural problem and that the current policy does permit big allocations. What Jan volunteered Gert to propose is good, but Tobias's need seems more urgent.
Peter Koch from DENIC said that on a previous occasion, they clarified that the PDP is a way for the community to formalise a discussion after understanding a problem statement. To some extent, the community looks for someone to do the work.
Peter understood that they did not develop the PDP and should not use the PDP as an entry ticket to a discussion. Furthermore, he says that the PDP should not be used to surprise the community with ideas – irrespective of their merit.
Erik Bais said that this WG is not the IETF, where the process starts with submitting a document. The process starts with a problem statement, and the WG acknowledged that this needs to be addressed. From there, it can start the PDP with an actual proposal.
Jordi said that this is why they had the interim sessions. Jordi thought that the WG followed the process in that sense. Jordi's point is Rinse and Jordi have already submitted a proposal for the PI. If the chairs follow the PDP and when they receive a proposal directly publish it, they do not have that problem. Now they have this problem of which one to choose.
Tobias Flebig said that he does not want to suggest what to start with but instead wants to suggest what to stop with. He proposed to stop spending time on whether to follow the PDP and procedures, also going into ad-hominem questions. Instead, Tobias argued that the WG should focus on bringing policy forward and making a positive change for the RIPE community.
Leo Vegoda shared a comment from Peter Hessler, who liked the proposed schedule of working through the proposal. They had no strong feelings about the order of the proposals and trusted the proposers and the WG chairs to schedule them. Peter would like to see a summary of what is upcoming.
Rinse Kloek from Delta Fiber agreed with the proposal to use nibble boundaries. Rinse fully agreed and shared that it would solve problems they had in a previous request for a larger block. Rinse agreed to enlarge the initial allocation to /28 and reserve for /24. Rinse wanted to hear if other people agreed to start with the larger allocation size instead of the PI.
Gert Döring commented on Rinse's statement reservations. The NCC has a /12, and it will be full at some point. Small ISPs like Gert's still use a /32 because they never needed a /29. They got upgraded to a /29 but are still in the first /32. They do not need a /24. If the RIPE NCC would push a /24 because it is reserved for t, it is not responsible stewardship. Reservations for continuous allocation, in case they grow, are good, but at some point, the ISP says, "I don’t need it," and the space can be handed out to another ISP. That is why they have reservations.
Alex Le Heux, Tucows added that reservations were also present in IPv4 at some point in time, and those expired and got reallocated to someone else.
Erik concluded by saying that this discussion continues the mailing list.
Jordi asked if he should resubmit the ASN policy proposal they submitted three years ago. Erik replied that they would discuss this afterwards.
Erik concludes that there are no further questions.
End of the second session.