Wednesday, 24 May 2023 10:30 - 11:30 (UTC+2)
Chairs: Erik Bais, James Kennedy, Leo Vegoda
Scribe: Matt Parker
Status: Approved
The presentation is available at:
https://ripe86.ripe.net/presentations/64-RIPE-86-Address-Policy-intro.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1035/
James Kennedy opened the session, introduced the Working Group Co-Chairs and thanked the Stenographer and Scribe. The minutes from RIPE 85 were approved.
[No presentation slides]
The recording is available at:
https://ripe86.ripe.net/archives/video/1038/
Erik Bais explained the Co-Chair structure of the Address Policy Working Group and proposed a change to the term for new chairs. Erik proposed a three year term, allowing one chair to step down each year. He hoped that this would introduce more stability and improve the rotation scheme. There were no objections.
The terms of James and Leo expired at RIPE 86. They both stood down and re-applied for another term. There were no other candidates. James was selected by the WG for a two year term and Leo for a three year term.
Hervé Clement, Orange SA
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/80-ASO-AC-Report-RIPE-86.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1039/
Hervé explained the role and composition of the ASO AC and noted that there was a review of its operating procedures currently under way, which aimed to finish in September 2023.
Sébastien Bachollet, EURALO, thanked Herve for his report. He also thanked him for his valuable participation at the round table event during the previous ICANN Meeting.
Elvis-Daniel Velea, V4Escrow, asked if Herve had any idea when AFRINIC would be able to appoint members to the ASO AC again.
Herve said discussions were ongoing but he had no idea when they would be concluded.
Marco Schmidt, RIPE NCC
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-from-RS-reviewed.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1040/
Marco gave an update from the RIPE NCC’s Registry Services department. He covered the current waiting times on the IPv4 waiting list, noting that the LIR at the front of the queue had been waiting since April 2022. He explained that temporary transfers were becoming more common and suggested they might better-define these transfers through policy changes or otherwise consider throwing out the category altogether and seeing whether similar outcomes could be achieved using existing concepts. Finally, he shared some statistics on out-of-region ASN requests, noting that these requests were creating considerable workload and one third of these ASNs were not being used to announce address space.
Sergey Myasoedov, NetArt Group, said temporary transfers fit his business model perfectly and he would welcome a separate policy or policy clarification. He said he might contribute to a policy proposal.
Erik explained that there were some operational limitations to temporary transfers. For example, the end date of the transfer could not be extended. At the end of the temporary transfer period, the transfer had to be reverted, which broke RPKI. Only at this point could a new temporary transfer be initiated. He found this to be cumbersome.
Erik also mentioned that there was a limitation in the RIPE Database which prevented assignment objects from being created if the parent was an exact match allocation object. This could be a problem if an LIR wanted to lease a /24 allocation to another organisation. He said that temporary transfers could help in this situation.
Tahar Schaa, speaking for himself, asked [with regards to ASNs] whether RIPE might be suffering from stricter regulations being implemented by the other RIR communities and suggested harmonising the policies. He asked whether they were talking with the other RIR communities about this. Marco replied that each community was entitled to decide on its own policy and this was a feature of the community-driven model. He suggested it could be brought up in the individual communities.
Gert Döring, speaking for himself, said he thought it was good that RIPE policy was liberal because it did not put obstacles in the way of people deploying things in their networks. However he thought they needed a reclaim policy.
Harry Cross, speaking for himself, asked whether the RIPE NCC should start making checks, after a defined period of time, to see whether there had been any change in the legal status of the parties involved in a temporary transfer.
Marco said this was not done right now, but guidance from the working group or a policy change to introduce time limits or a check-in could help.
Sander Steffann, 6connect, said it wasn’t clear to him how and why people were using the temporary transfer policy. He said it would be nice to hear from these people at the next RIPE Meeting.
Peter Hessler, Globalways, asked if there was any comparison between out of region usage of AS Numbers and IPv6 PI space.
Marco said that he did not have the exact numbers, but out of region usage was more prevalent for AS Numbers. He added there was a small fee for IPv6 PI space which might explain the difference.
Peter suggested it would be good to synchronise the policies for IP address assignment and AS Number assignment, as this would simplify the process for both the requester and the RIPE NCC.
Elvis suggested that temporary transfers should be tagged as such in statistics.
Marco explained that publishing transfers was defined in policy and it might be necessary to update the policy to facilitate this.
Elvis said that an assignment or a sub-allocation could also be considered a lease; temporary transfers were a similar service but not clearly defined.
Sander said he would like to keep it easy to get an AS Number in the RIPE region. He considered this to be a feature.
Angela Dall'Ara, RIPE NCC
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/83-RIPE-86-Current-Policy-Topics.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1042/
Erik asked Sander Steffann to provide a brief update on the Voluntary Transfer Lock and to explain why it would be discussed in the RIPE NCC Services Working Group and not in Address Policy.
Sander explained that the policy proposal would allow LIRs to state that they do not want to transfer addresses for a certain period of time. It was something requested by LIRs in Ukraine who were concerned that they may be forced to give away their valuable resources. The proposal was being discussed in the RIPE NCC Services WG because it related to constraints on the RIPE NCC rather than transfers specifically. However, he added that should the policy proposal be adopted by the RIPE NCC Services WG, a small update to the transfer policy might be required to keep everything in sync.
End of first session.
Wednesday, 24 May 2023 12:00 - 13:00 (UTC+2)
Chairs: Erik Bais, James Kennedy, Leo Vegoda
Scribe: Antony Gollan
Status: Draft
Jeroen Lauwers, A2B Internet
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/86-Presentatie-Rotterdam-2023.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1047/
Jeroen presented on behalf of his colleague who could not attend due to work obligations. He noted that the previous version had not received much support. The goal of the proposal was to make the policy less repetitive and easier to understand. Some of the issues they sought to resolve were the non-compliance with policy by 42% of LIRs and the repetitive work to create assignments in the RIPE Database. He noted that an added benefit of introducing an AGGREGATED-BY-LIR status was that it would align the IPv4 and IPv6 policies.
Robert Scheck from ETIS GMBH said he liked the proposal because there were multiple large German LIRs that did not create any assignments, which meant it was not clear which ranges to block in abuse cases.
Erik reminded Robert to express his support for the policy on the mailing list.
Matthias Wichtlhuber, DE-CIX
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/85-APWG_proposal.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1050/
Matthias explained that with the IXP IPv4 pool expected to deplete around 2029, they needed to make a decision: they could add new space to the pool, accept that new peering projects would have to buy address space, or reduce the default allocation size. His proposal was for new IXPs to receive a /26 by default; once they were using >50% of the assignment, they could request a /24. He noted that this came at a cost, since it made it more likely that IXPs would have to renumber, which could involve chasing after their members to make sure they adapted their configurations.
Elvis suggested that the RIPE NCC could assign a /26 and reserve up to a /24 where possible.
Erik said this had to do with how registration was set up. He wasn’t sure this was possible or whether they would get a /15 in /26 with reserves.
Wolfgang Tremmel, DE-CIX, said renumbering was much less painful for IXPs than changing the netmask. It still worked if the netmask was wrong. Customers were less likely to update this than if they had to change the IP address. He said this was not a good idea.
Marco Schmidt, RIPE NCC, said he wanted to quickly respond to Elvis’s question. It would technically be possible to withdraw the space, but this might defeat the purpose of the proposal, since it aimed to make the address space go as far as possible.
Maria Matejka, developer of BIRD at CZ.NIC, asked how many of their peers had old routers which didn’t accept IPv6 next hops for IPv4 prefixes.
Matthias said this was an excellent question and they had discussed this on the mailing list. Obviously, RFC 8950 was the solution and what they were proposing was just a fix to get it implemented. The rough consensus on the list was that they should not force adoption of the RFC in the policy because they weren’t sure how well this would work. Instead, they should wait for implementation and get ready before the depletion of the IXP pool.
Maria asked if it was better to deboganise 240/4 just for the purpose of IXPs and such things.
Matthias said he had no real answer to that.
Will van Gulik, RomandIX, said he was running one of those IXPs with less than a /26. He was going to say that he could reduce his subnet mask, but he agreed with Wolfgang’s earlier point and he would ask his members to renumber for the sake of longevity of the IXP pool. He was in favour of the proposal.
Peter Hessler, Globalways, said that as an IXP user, it was hard for them to debug why they couldn’t reach a neighbour, because they had no visibility into what their neighbour’s netmask was. This often happened with medium-sized IXPs that would configure a /24 and, if they were in the wrong segment of that /23, you couldn’t send them any traffic. In extreme cases if you were getting it via the route server your traffic was effectively blackholed.
Edwin Verheul, SURF B.V.
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/61-ripe-587.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1053/
Edwin explained that the proposal set a minimum allocation size of /24, though smaller allocations could be requested. There were about twenty temporary allocations made each year. Based on community feedback, the proposal had been updated to allow for larger allocations, so long as details of the research were made public upon registration of the addresses, and provided the End User committed to making their research results available free from charge and any disclosure requirements.
Elvis, speaking as one of the proposers, said this proposal had been discussed at a few RIPE Meetings now and while they hadn’t received any negative comments, they would appreciate a few more positive ones.
Erik said it definitely helped that there were no strong objections. In response to a comment from Edwin, he clarified that it was the RIPE NCC rather than the WG Chairs who produced the impact analysis.
Leo Vegoda, Address Policy Co-Chair
The presentation is available at:
https://ripe86.ripe.net/wp-content/uploads/presentations/13-IPv6-Policy-Improvements-RIPE-86-draft-1.pptx.pdf
The recording is available at:
https://ripe86.ripe.net/archives/video/1054/
Leo gave an update from the two interim WG sessions that discussed the goals of the IPv6 policies. He noted that they had also published a RIPE Labs article which gave an overview along with minutes and video recordings provided by the RIPE NCC. The issues they had discussed were: Unclear guidance on documentation requirements; Complex language and implementation of the HD-ratio. Leo asked if there was support for the desired policy outcomes or if there was disagreement with them.
Erik asked if the room could reach agreement on the goals Leo had put forward before moving on.
Elvis said he agreed with the nibble boundary allocation/assignment limits, but Provider Independent (PI) space was more complicated. He asked if they would allow PI IPv6 resources to be sub-assigned and if they would require/allow registration of sub-assignments.
Erik said for PI space there were already proper rules about how they did that in the past. For assignments it was a bit different, as they would look at whose network it was rather than whose device it was.
Peter said applying for a /47of PI space was a painful experience that he wouldn’t wish on anyone. Having it well documented and easily understandable would be great. He liked the desired outcomes in terms of the policy limitations for PI assignments. He liked the focus on who was managing the network rather than devices connecting to it.
Erik agreed. He said they should be making it easier for companies with multiple locations to get, for example, a /48 for each location.
Maximilian Emig, speaking as a former resource holder, said right now the RIPE NCC was more likely to hand out multiple /48s rather than a /47. He suggested promoting aggregation should be a goal of the policy.
Erik said they were trying to make it so that if you did a single request for multiple locations, you would get a single allocation.
Maximilian said they needed to make that explicit in the policy text.
Dmytro Kohmanyuk, Hostmaster.UA, said he wanted to relay some feedback from other Ukrainian operators rather than his own point of view. Some of them could not afford their own LIR and so relied on an upstream provider. The typical ‘worst practice’ was to hand those companies a /48 and they complained that this forced them to make End User assignments of /60. They knew this wasn’t best practice but they couldn’t afford it, so he applauded having a /44 without needs assessment.
Dmitry added that they had said it shouldn’t be a new boundary, so he asked if that meant they would automatically round it up.
Erik said that for the nibble boundaries specifically, having a /29 was a pain for some. So this would push the /29 to a /28 and for the /48, for larger assignments, it would go to a /44.
Dmitry said they might run into conflicts pushing the sizes up but added that this was the RIPE NCC’s problem and not theirs.
Erik noted that this would be for new allocations.
Gert said there were existing /29 holders that you couldn’t bump because they were /32 holders that later got a /29 and so on – but that was old stuff. For the new stuff, he thought it should be explicit that it was actually increasing the initial allocation size to a /28, which was perfectly fine as there were plenty of /28s. You always needed to balance the numbers, routing table slots, IPv6 space, number of possible users of that space, and /28 was perfectly fine and /24 would be perfectly fine. He added that he didn’t understand the complaints about the HD-Ratio, since people could just look at the table in the appendix of the policy. He had yet to see anything better that took into account aggregation losses and aggregation density and how much the space should be filled before requesting more.
Gert noted the charging scheme discussion that RIPE NCC members would be voting on that week. He said they should be very careful to discourage things where charging factors would affect block size. They should be liberal with IPv6 allocations.
Regarding the HD-Ratio, Leo suggested they could ask the RIPE NCC to look at this from a couple of different perspectives – they had UX specialists who might see if they could create interfaces to help people better understand it. He also noted that the HD-Ratio came out of academic research 20+ years ago and at the time he thought it was looking at telephone number distribution. They could ask the RIPE NCC to do a review to see if there had been more recent research about this kind of thing and report back to the WG.
Gert said alternatively they could just go for a fixed number. For example, they could have a table that said for a /28 you needed 10% utilisation – that worked for him.
Peter said he wanted to remind the WG that, as Gert had mentioned, changing the /29 to a /28 would move ISPs into a new bracket under the proposed charging scheme. While the WG couldn’t make decisions on what the charging scheme was, it should be mindful of the potential financial impacts.
Erik agreed. He said it also depended on what sort of charging scheme they ended up with, as there were options that did not have categories. If someone had a /29, it was not always possible to expand it to a /28 if that became the policy – and then it became your decision to do so. He knew some LIRs that still had a /32.
Leo said there had been a comment during their interim sessions that if their policy relied on the charging scheme to be an effective policy, then the policy could be rendered ineffective by the RIPE NCC General Meeting. This was an important point to consider. He said they should have the right policy because it was the right policy.
Erik asked if there were any objections to the policy goals in the room. There were none.
Erik asked for volunteers.
Gert said he was willing to help but was not willing to be the primary proposer.
Elvis also volunteered to join the team working on this. He added that a lot of these goals could be achieved simply by using a table for the HD-Ratio.
Erik said they would do a recap of this on the ML and see where policy changes per-topic could be workable, instead of just doing a revamp of the entire document in one go.
There were no AOBs.
End of second session.