- address-policy-wg - mailman.ripe.net

IPv6 policy - prioritisation and outcomes discussion webinar
by Leo Vegoda 15 Feb '23

15 Feb '23

At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. The identified areas for improvement include: - Better guidance on documentation requirements for large allocations - Simpler language for the HD-ratio - Make it easier for small networks to assign a few addresses to other organisations - Ensure allocations always fall on a nibble boundary If you wants to help us set priorities and define the outcomes the community needs you are welcome to join. Monday, 20 February 2023 at 13:00 UTC (14:00 CET). Join Zoom Meeting https://ripe.zoom.us/j/94307989734?pwd=YytnQm53SjJEWUtKemxQM3dGcjZmQT09 Meeting ID: 943 0798 9734 Passcode: 339420 Leo Vegoda for the Address Policy WG co-chairs

1 1

End of Discussion Phase for 2023-01 (Reducing IXP IPv4 assignment default size to a /26)
by James Kennedy 09 Feb '23

09 Feb '23

Dear WG, The Discussion Phase of policy proposal 2023-01 "Reducing IXP IPv4 assignment default size to a /26" has now ended. Many thanks to all for your comments. Taking into consideration the community feedback, the proposers have drafted a new version of the proposal. The RIPE NCC will soon publish the new version on the mailing list and kick-off a new Discussion Phase as per the PDP: https://www.ripe.net/publications/docs/ripe-781. Regards, James

1 0

2022-02 Policy Proposal Withdrawn (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
by Angela Dall'Ara 30 Nov '22

30 Nov '22

Dear colleagues, The policy proposal 2022-02, "Remove mandatory IPv4 PA assignment registration in the RIPE Database” has been withdrawn. The goal of this proposal was to change the registration of IPv4 assignments from mandatory to optional. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer decided to withdraw this proposal, feeling that a new proposal would be more suitable for including the suggestions and feedback provided by the community during the discussion phase. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Draft Address Policy WG Minutes from RIPE 85
by Leo Vegoda 28 Nov '22

28 Nov '22

Dear WG, The RIPE NCC has now prepared draft minutes of our session at RIPE 85. Please write to this list or inform the co-chairs of any issues or corrections. Kind regards, Leo Vegoda for the Address Policy WG co-chairs RIPE 85 Address Policy WG Minutes Wednesday, 26 October 2022, 09:00-10:00 UTC+1 Chairs: Erik Bais, James Kennedy, Leo Vegoda Scribe: Antony Gollan Status: Draft A. Introduction The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/64-RIPE-85-Address… The video is available at: https://ripe85.ripe.net/archives/video/898/ There were no changes to the agenda. The minutes from RIPE 84 were approved without changes. B. ASO AC Update James Kennedy, ASO AC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/72-ASO-AC-Report-R… The video is available at: https://ripe85.ripe.net/archives/video/901/ James Kennedy gave an update from the ASO AC. Kevin Blumberg from the ARIN region was their new Chair. Kevin had appointed Mike Silber (AFRINIC) and Herve Clement (RIPE) as Vice Chairs. There were no questions. C. Policy Update Followed by Q&A Angela Dall'Ara, RIPE NCC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/59-RIPE-85-Current… The video is available at: https://ripe85.ripe.net/archives/video/902/ Angela ran through open policies in the five RIR service regions. In the RIPE region, there were two: 2022-01: Personal Data in the RIPE Database (Database WG) and 2022-02: Remove mandatory IPv4 PA assignment registration in the RIPE Database (Address Policy WG). Jordi Palet Martinez (online), Moremar, noted all of the APNIC proposals would get a new version soon. D. (2022-02) Remove Mandatory IPv4 PA Assignment Registration in the RIPE Database James Kennedy, Address Policy WG co-chair The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/73-2022-02.pdf The video is available at: https://ripe85.ripe.net/archives/video/905/ James said that the proposer (Jeroen Lauwers) could not be at the meeting and so he would run through the proposal quickly for him. He added that he would be recusing himself as WG co-chair from determining consensus on this proposal. James’s interpretation of the intent of the policy was that it sought to allow LIRs to document only information in the RIPE Database that was needed for operational and administrative purposes, and to reduce workload by not forcing them to maintain duplicate data. Sander Steffann, 6connect, said he agreed that everything visible externally should be documented in the RIPE Database. That was an absolute minimum. However, he thought they already had this – if it was externally visible there would be a ROUTE object, in which case there would have to be an INETNUM object it pointed to. Erik Bais, Address Policy WG co-chair, said for the allocation there was not. Sander said then he would definitely put that in as a minimum requirement. For the rest, it was a contact database – so that if something went wrong, people could see who to contact and who was responsible. If the LIR was willingly taking responsibility to be the contact for all its customers, that was a business decision, and they should allow for that. Kurt Kayser (online), speaking on his own behalf, asked if the logic was correct that routed = used, and that it if was not assigned, it was not shown as used. Erik said this played into the comment from Sander. When were they going to say the address space was in use? Was it when there was a valid ROUTE object or when there was a valid assignment? James said, on that point, maybe the ROUTE object was created before being used. But a quarter of all allocations was an interesting number. Elvis Daniel Velea (online), v6escrow, said he supported the intent of the proposal. Assignments should only be registered if required by the End User or if the LIR wanted to delegate some administrative/abuse/routing decisions. Peter Koch, DENIC, said he had been a member of the RIPE Database Requirements Task Force. The TF report made a distinction between the RIPE Database and the RIPE Registry. He thought the differences and commonalities here weren’t reflected in the proposal in a way that would help with making a decision. Further, while the author pointed towards the TF report and its recommendations, he didn’t think the proposal reflected the corresponding recommendation. That was fine, because it didn’t have to, but he wanted to avoid the impression that this was a proposal to implement what the TF recommended. It did make a recommendation on the assignments, following the observation of an asymmetry in terms of depth and volume of usage by various LIRs and, as someone had said on the mailing list, maybe a policy wasn’t the way to change that. Peter made a further observation. The RIPE Chair Team had, after consultation and with the community’s support, offered clarification to the PDP. That clarification had strongly suggested that policy proposals should be the result of in-depth discussion. This proposal seemed to come out of the blue, and so he would urge the chairs to think about their gatekeeping and steering function. Finally, Peter didn’t think this proposal was getting anywhere. Unfortunately, the PDP’s was biased towards stumbling forward, and so he would suggest putting an end to the proposal and considering the problems identified in the subsequent discussion. Erik noted that the intent for creating the proposal was discussed at RIPE 84 in Berlin and the proposal was only created later. Peter said that since Berlin there had been little discussion on the list that would support the general direction of the proposal and the problem statement that needed to be fixed. A couple of people had mentioned their own surprise at seeing the proposal and two or three had said it did not seem to be addressing the problem it sought to fix. James said he thought the proposer had tried to get as much feedback as possible at RIPE 84, but he took Erik’s point that it could have been progressed further on the mailing list. James added that he had been on the Database Requirements TF with Peter and their recommendation had inspired this proposal, but it was definitely not one-to-one. Brian Storey (online), Gamma, asked if the intent of the proposal was to no longer require the registration of any downstream End User PA assignments. James said he could only give his own interpretation. The current policy text said that for any assignments it should be optional. But from the feedback Jeroen had received over the past few weeks, and from his discussions with him, he was taking that into account. So, the intent seemed to have changed since then. Erik said as chairs they had looked at all the comments on the mailing list. If this was moving forward, they would need to have a discussion with Jeroen about whether it was for all assignments or just for the resource holder of the allocation, which would probably make more sense. Kurt said he would split the main purpose of the documentation between customer data (mainly assignments) and network operator related data (such as abuse-c and admin-c). RIPE NCC needed both datasets before but now the (very sensitive GDPR-Data) purposes may allow a different handling. Erik said this was not a GDPR topic. Yes, they were trying to minimise the duplication of data. If the assignments were the same information as the resource holder, then they shouldn’t need to duplicate it. But if you were adding different information with different parties and contacts, then that should still be in the database. At least that was how he read it. Erik and James encouraged people to share their opinions on the mailing list. E. Registry Services Update Followed by Q&A Marco Schmidt, RIPE NCC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/66-RIPE85-Feeback-… The recording is available at: https://ripe85.ripe.net/archives/video/907/ Marco gave an update from the RIPE NCC’s Registry Services Department. He had three topics he wanted feedback on: 1. IPv4 Waiting List: they now had about 1,050 LIRs on the waiting list and the estimated wait time was now about two years. There were still multiple-LIRs being created, which disadvantaged newcomers. He asked if the WG wanted to accept this or if they should try to fix it. 2. IPv4 IXP Pool: the addition of a further /16 to the pool for IPv4 IXP assignments had drastically extended its lifetime. They expected this pool to become empty around 2029. He asked if that was enough. 3. Assignment Definition: the policy referred to assignments made to ‘downstream networks’ but later referred to ‘End Users’. He asked if these terms needed further definition by the WG. Shane Kerr, NS1, responded to the question about the IXP pool. This policy had been created so that IXPs wouldn’t have to go to an LIR. Now that they were out of space, he asked why they wouldn’t buy address space like anyone else. Marco said he thought this was about seeing IXPs as critical infrastructure. Shane said everyone thought their own infrastructure was critical. Sander said he’d been around since the beginning of the run-out policies. The fact that they still had some IPv4, even with a waiting list of two years, was an achievement which meant their policies had worked well. By now, they had extended this for so many years and given people many opportunities, but at a certain point they needed to say that they had properly arranged the deck chairs on the Titanic. Regarding IXPs, Sander thought they did have an important role and they should keep a separate pool for that. Maybe they could have a policy that used some of the recovered IPv4 space to top up the pool when it reached a certain level. He suggested they try a proposal that would allow the RIPE NCC to manage this without an intervention from the WG every time. Erik said they would need input from the Connect WG on this policy, and how it saw the prospect of this pool running out in seven years. Sander said he would attend the Connect WG session later that day and raise the topic there. Regarding the definition of assignments, Sander said he could vaguely remember this being discussed a long time ago; they had tried to keep it vague since there were many ways of providing a service to a customer. They had intentionally avoided going into what that service could be, as they would be stuck chasing reality. They did put in that there had to be some relation, and so he thought the RIPE NCC could be a bit stricter, but that would require a very long policy process to define what that meant. Elvis (online), suggested they not get into the leasing discussion. Since forever, LIRs in the RIPE region had assigned either PA or PI to connecting customers or customers that offered all kind of services and the colors of the IPs hadn’t really mattered. Denis Walker, Database WG co-chair, said he had a comment on leasing. What they had now was a situation where someone with spare address space was asking third-party companies to lease it out on their behalf, which might go to an LIR that saw it more as an allocation and assigned it to an End User. None of this could be reflected in the RIPE Database, because this whole structure that was hidden from view. If they were going to allow leasing, they should document it properly. Riccardo Gori, IP4WISP, wanted to go into the definition of LIR. He interpreted this as ‘Local Internet Registry’ in the same way as an RIR was a regional registry. He didn’t find a strict relation between the LIR and the services that were operated. Often the resources were associated to access offered by an operator to an Internet Service Provider or in a data centre. So, he didn’t see much need to go deeper into the definition of an LIR because it should reflect the fact that, as the comment before said, it should give the right description in the RIPE Database where the resources were being used and who was using them. If this was consistent and correct, then in his opinion it was done. End of first session. F. IPv6 Policy Goals - Review Process (Community Input Sought) [15 minutes] Leo Vegoda, Address Policy WG co-chair The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/81-IPv6_at_RIPE-85… The recording is available at: https://ripe85.ripe.net/archives/video/910/ Leo noted that they’d started a discussion at RIPE 84 to look at the goals of the IPv6 policy, which hadn’t been reviewed for many years. He asked if they wanted to adjust the policy goals, change their order of priority, or introduce new ones. Erik said there had been a lot of updates on this topic since RIPE 84. That didn’t mean that the issues raised were gone. He’d also had a discussion with a Dutch ISP that had quite some issues, because they actually planned to do IPv6 with /48s to their customers, but instead they had to refer back to /56s because they couldn’t get the documentation within a reasonable time period. This meant they had to move ahead with a /29 instead of a /25 or /27. Sander said he was part of the group that discussed all these IPv6 changes and the main thing was a steep jump in requirements and in terms of documentation they needed a full-sized novel. He asked if the RIPE NCC was still reserving three bits of adjacent address space for future growth. Marco confirmed that they were. Sander said he had heard concerns from organisations that they would have to come back and get de-aggregated blocks when they needed to grow later. So this might help to address some of their concerns. This wasn’t in the policy and was an implementation detail – so maybe to alleviate some of this stress the RIPE NCC could make this a bit more official and tell people that they had a reservation for when they came back in the future. Marco confirmed that they could extend all the way to a /26. Erik said this meant they could take a gradual approach and they could grow into their space. Sander said there was a three-bit reservation. There was an issue with older allocations, as they would be able to extend from a /32 to a /29 as opposed to others who could grow from a /29 to a /27. There might also be the issue of LIRs who opted for a /32 rather than a /29 and unknowingly limited themselves in the future. Leo asked what kind of planning horizon was reasonable from the perspective of a network operator in terms of growing to a larger allocation. He also asked to hear from the RIPE NCC, as they were the ones who would have to go back to IANA if they needed more address space. Sander said currently there was no official planning horizon and the implementation detail was that there was a planning horizon of three bits – so someone could grow up to eight times as large. He didn’t want to micromanage the RIPE NCC – maybe they needed to put this in policy or maybe they just needed to inform people what the current operational procedure of the RIPE NCC was. Erik said maybe the LIR could have some kind of first right of refusal – so they could give the RIPE NCC notice that they were intending to grow in the next three to five years so that the additional bits were not consumed. This could be a lightweight way to do it. Sander asked if this was more of an informational hint rather than a guarantee. Erik said they would still need to do the documentation part. Sander said his first preference would be to round allocation sizes to nibble boundaries. Erik said they couldn’t always, especially if they were running out and would have to go back to IANA and ask for additional allocations – IANA would ask why. Leo said, from memory, one of the things in the global policy was that reservations were considered use. But that didn’t mean they shouldn’t manage things responsibly. Marco Schmidt, RIPE NCC, said he wanted to confirm for the record that they reserved an additional three bits for every IPv6 allocation. This meant someone with a /29 had a reservation up to a /26, for a /26 up to a /23 and so on. There were a few exceptions, for example historical allocations of a /32 that were extended to a /29 and couldn’t go further, and sometimes those who transferred their allocations were unable to extend, but that was just a sidenote. This approach had been used for a long time and it worked well. They could do more to make sure that people were aware. They did things on a case-by-case basis and sometimes would tell people that they might start with a /29 so they could expand later if they needed to. They could do this in a more consistent and formal way. They weren’t too concerned about going back to IANA – the /12s they currently received lasted for a long time. Tina Morris, AWS, said nibble boundaries shouldn’t be such a concern. They were using 3% globally of what had been assigned and it was ridiculous to get these micro allocations when the whole point of IPv6 was to make things easier. When you assigned just part of a block, the entire network planning was messed up – internally you could no longer use nibble boundaries, could no longer make a good organisational plan for your network. The whole point of IPv6 was to make things easier, better, implementable, and if they didn’t make things workable for organisations, then they were blocking the growth of IPv6 networks. Elvis said the RIPE NCC already reserved three bits for larger blocks and so he wondered why they were even having this discussion. The way the RIPE NCC used the sparse allocation mechanism allowed allocations to grow further. Kurt said he would turn it around and define a nibble-boundary routing-obligation to support small IPv6 routing tables. He hated fragmentation and deaggregation. Erik said this came back to the goals of the policy. Obviously, they still thought that deaggregation wasn’t something they could fix in the policy. They encouraged everyone to use BCPs and not announce all their /48s. But if you looked at the IPv6 routing tables, it was 48% /48s at this point. Sander asked if there was interest in him drafting a policy proposal to realign the policies with nibble boundaries. That would mean changing a /29 to a /28 and asking the RIPE NCC to reserve four bits to align it with the /24. Maybe it was time to be more ambitious than to tweak this one bit at a time. He asked for a show of hands [but only saw a couple of hands]. He said he would discuss further with the chairs to see if there was support. Erik said on the next video call that they would have on IPv6 they would invite Sander and Gert to provide additional feedback. They would also invite people from the RIPE NCC to explain what their current operation was and where they stumbled on the current policy, before they made any changes. Daniel Karrenberg, Internet geek, asked why maintaining a low number of prefixes was suddenly such a big problem. They had managed a much bigger number in IPv4. Erik said it was the fact that IPv6 prefixes were longer, and if you started announcing every /29 in /48s, you got an explosion in the routing table, so that’s why aggregation was a topic. Mirjam Kühne, RIPE Chair, said she was happy to see the enthusiasm. She was going to suggest they discuss this on the list before creating a proposal, but she noted that Erik seemed to be suggesting this with the interim call. Erik agreed. Leo said he thought this had been a useful discussion. Before leaping towards a specific thing with nibble boundaries, he thought it would be good to base this in the policy goals. If they could get clear on that, it would help any discussions on the specifics to be more productive, as they would know what they were trying to achieve. Erik said that sounded reasonable. G. Temporary IPv4 Assignments - Minimum Assignment Size Leo Vegoda, Address Policy WG co-chair The video is available at: https://ripe85.ripe.net/archives/video/913/ Leo gave a brief summary of the topic. The RIPE NCC got requests for temporary allocations for academic and research experiments that often only needed a very small number of IPv4 addresses. The policy said that justification was required for experiments in the same way as anything else – meaning that if you were unable to justify 128 addresses or more, you did not get a /24. The question was whether they needed a minimum allocation size for experiments, and whether this should apply only to academic or research assignments, or if it needed to be a more general thing – because if you needed to use an assignment it had to be a /24. Elvis (online) said /24 should be the minimum size for temporary assignments, as it was unusable otherwise. Erik asked if they needed to limit this to research or if it should be for more general use. His personal feeling was that it shouldn’t be limited to specific research as the IPv4 policy had a minimum size for allocations and the policies should align. He said they would take this back to the mailing list. Edwin Verheul, SURF, said they liked that the RIPE NCC provided temporary assignments – they used them for events and were happy with that. One issue was geolocation. He wondered if certain /24s could be limited to certain countries or regions so they didn’t run into limitations in that department. Erik said geolocation was going to be an issue when they ran into leasing or temporary assignments. There might be an option where the RIPE NCC could provide a geofeed. This could feed into the IP databases that were doing geolocation. Otherwise, you could extend the time that the addresses were in use – it typically took 6-8 weeks before geolocation databases were updated unless you were willing to do the legwork. Marco said he was happy to hear the suggestion that they have a minimum assignment size and he would like to see this discussed further on the mailing list. For the RIPE NCC it was a pain point and everyone thought it should change. Erik said he would try to find someone to create a proposal. Kurt asked if there was any usability guarantee after getting the space back (getting it removed from spam blocklists and so on). Marco said they did pick address space randomly and allowed a certain quarantine time, but they didn’t check how ‘tainted’ the address space was. They tried to give space that was as clean as possible and he might contact Kurt to hear feedback on how his experience was. Radu-Adrian Feurdean, FranceIX, asked if they should plan to gradually phase out temporary allocations. Surely the message should be that IPv4 was over and IPv6 was the way. Elvis volunteered to author the temporary assignment policy proposal. H. AOB/Open Mic The video is available at: https://ripe85.ripe.net/archives/video/914/ Sander said there was a message on one of the RIPE mailing lists from Hans Petter Holen about Ukraine. This was about protecting the resources of Ukrainian members from being transferred at gunpoint. They had talked about this in Berlin, but it still seemed to be going on. In his response to the Ukrainian Government, Hans Petter had suggested they raise this in the Address Policy WG. He didn’t think protecting members’ resources was a policy issue, but he was interested to hear from the WG. Erik said the WG chairs had discussed this issue. It wasn’t unique to Ukraine, whatever they came up with should apply to other areas, such as Palestine, Syria and so on. He added that there had been a suggestion that people have some kind of ability to lock their resources in the LIR Portal. Some kind of country-specific transfer lock was not something he would envision. When looking at art [as a parallel example], this was often stolen in war. What happened was that the owners went to the court after the war and got their property back that way. His personal thinking was that they should focus more on the appeals side rather than finding a policy solution. Max Tulyev, NetAssist, agreed that it should not be handled through policy. He agreed it would be good to have a big red button that would lock transfers for some period of time. A country-specific lock was not an option. He added that there was government corruption within Ukraine and he thought some kind of government approval for transfers should not be used. Erik said that one of the risks he saw – and he was sorry to state it this way – was if a gun was pointed at a director of a company or their family. Surely in this case the best response was to process the transfer and get an appeal afterwards. That was the safest option for everybody involved. However, that was his own opinion. Max said they had some statistics that this had already happened in the occupied territories regarding other types of assets (he didn’t know of any cases involving IP resources) and they were killing people after the transfer. Reversing transfers would also open a can of worms as it could be open to abuse. Erik said the process here was similar to cases of art, for example. He added that there would be an update on this topic in the RIPE NCC Services WG. Olena Kushnir, WebPro, said they were a telecommunications provider of critical infrastructure in Ukraine. Of course, they had LIRs that only bought and sold IP addresses, and others who used these resources to provide services. When the war started in Ukraine, businesses that continued to work in the country were afraid that they would be put in danger. Of course they would do everything to save their family and their lives – but they were also afraid for their business and resources. It was first of all a matter of cyber-security. It was also a considerable amount of money that they could save [in terms of the value of the resources]. They didn’t want influence from government in their business, though she added that they had good dialogue with government through many working groups. She noted that Max said he didn’t know of any cases involving stolen IP addresses – she referenced the case of FTcom which had transferred addresses to Russian territory. She thought it was good to discuss changes to policy and she was grateful for the opportunity to be present for the discussion. She said they wanted to freeze all transfers until they found some way to protect Ukrainian network operators, because they were also part of the RIPE family. Hans Petter Holen, RIPE NCC, thanked his Ukrainian colleagues for attending the meeting and raising their concerns. What was happening in their country was terrible and he wanted to be clear on that. He noted that Athina would be presenting on this in the RIPE NCC Services WG. They would need input from the community on this and would be listening carefully to all of the input they received. And he reassured them that no matter how they would go forward, the RIPE NCC’s Board was intent on them taking timely action on the matter, so he didn’t think they should let the policy path be prohibitive just because of the timing, as perhaps the board could approve a temporary measure until the policy was ready. Artem Zurkov, no affiliation, said he was a provider from an occupied territory. He thought there should be some kind of public log so that if resources were locked, people would know that there was no ability to unlock them. This could support people’s physical safety if people with guns could see that this was the case. He supported Max’s suggestion that they should have some way for people to lock resources for a period of time. Elvis asked Hans Petter for guidance from the RIPE NCC on what kind of policy interventions would be needed. Hans Petter said the transfer policies said that the RIPE NCC should process transfers, but now they were suggesting that it shouldn’t process some transfers… but the community wanted the RIPE NCC to follow its policies. Clearly this could become complicated. He encouraged people to attend the RIPE NCC Services WG services session later that day to hear more on this. Rüdiger Volk, no affiliation, said he wanted to raise a different topic. He wondered whether the status field in the delegated extend file as it was defined and operated by the RIPE NCC should get some attention in the Address Policy WG. He noted that ISOC had reported some confusion using the data and, as far as he could tell, there was not really any clear documentation or attention to what was being done in that file. A couple of years ago, people had said this was just some statistics the RIRs were putting out and didn’t have much meaning. At the time of RIPE 75, policy changes in RPKI provided arguments that the delegated extended file actually had to be taken seriously. At RIPE 78, he had reported operational problems with the file, and he thought that if ISOC people, who were quite knowledgeable, were getting confused, then this was something that should be reviewed from a policy point of view. Erik thanked Rüdiger for his feedback and said this was definitely a discussion they needed to have on the mailing list, so they would need some more feedback from him there. End of second session.

1 0

Re: [address-policy-wg] Minimum size for IPv4 temporary assignments
by Erik Bais 24 Nov '22

24 Nov '22

Hi Edwin, Thank you on stepping forward on this. And I think that it would make sense to have a discussion on this with a policy proposal on the table. As you mentioned, this has been brought up multiple times already, so it would be good to see if we can get this sorted. It would be nice if the AP-WG members could provide some insight if the would support (or not) a policy proposal as suggested. Regards, Speaking as one of the Co-Chairs, Erik Bais From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Edwin Verheul <edwin.verheul(a)surf.nl> Date: Thursday, 17 November 2022 at 16:24 To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] Minimum size for IPv4 temporary assignments Dear colleagues of the Address Policy Working Group, During (my first!) RIPE85 there was short discussion about the minimal size for IPv4 temporary assignments in this workgroup. The policy for temporary IPv4 assignments requires you to use 50% of the assigned addresses [1]. This requirement pushes events or experiments into smaller assignments less than /24’s, which are mostly unroutable on the internet. This is mentioned before by Marco Schmidt [2] in October 2022 and Randy Bush [3] in Januari 2022. It looks to me this is a legitimate reason to propose this in a policy change: * Temporary IPv4 assignments ≤ /24 should NOT subject to the 50% usage requirement; * Only smaller assignments will be handed out if the assignee is explicitly willing to have (sub optimal) unroutable IP space on the internet; * If it is required by the assignee to advertise multiple subnets, the policy should allow to assign multiple /24’s( or a bigger assignment, so the assignee can split and advertise by themselves). Elvis Velea and myself are willing to (co) author this proposal. We will do our best to hand in the proposal by the end of this year. Any thoughts on this? Kind regards, Edwin Verheul SURF AS1103 [1] https://www.ripe.net/publications/docs/ripe-587#utilisation-rates [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-October/0135… [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-January/0134…

1 0

Minimum size for IPv4 temporary assignments
by Edwin Verheul 17 Nov '22

17 Nov '22

Dear colleagues of the Address Policy Working Group, During (my first!) RIPE85 there was short discussion about the minimal size for IPv4 temporary assignments in this workgroup. The policy for temporary IPv4 assignments requires you to use 50% of the assigned addresses [1]. This requirement pushes events or experiments into smaller assignments less than /24’s, which are mostly unroutable on the internet. This is mentioned before by Marco Schmidt [2] in October 2022 and Randy Bush [3] in Januari 2022. It looks to me this is a legitimate reason to propose this in a policy change: * Temporary IPv4 assignments ≤ /24 should NOT subject to the 50% usage requirement; * Only smaller assignments will be handed out if the assignee is explicitly willing to have (sub optimal) unroutable IP space on the internet; * If it is required by the assignee to advertise multiple subnets, the policy should allow to assign multiple /24’s( or a bigger assignment, so the assignee can split and advertise by themselves). Elvis Velea and myself are willing to (co) author this proposal. We will do our best to hand in the proposal by the end of this year. Any thoughts on this? Kind regards, Edwin Verheul SURF AS1103 [1] https://www.ripe.net/publications/docs/ripe-587#utilisation-rates [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-October/0135… [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-January/0134…

1 0

IPv6 Allocation to the RIPE NCC
by Marco Schmidt 11 Nov '22

11 Nov '22

Dear colleagues, The RIPE NCC Arbiters Panel has approved a request for an IPv6 allocation to the RIPE NCC for its internal network based on the RIPE Document ripe-635, "Allocating/Assigning Resources to the RIPE NCC", and the RIPE NCC Document ripe-738, “IPv6 Address Allocation and Assignment Policy”. You can find the full announcement at: https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/ipv6-allocat… If you have any questions, please send us a message at <feedback at ripe.net>. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

IXP pool lower boundary of assignments
by Matthias Wichtlhuber 08 Nov '22

08 Nov '22

Hi address policy WG, Marco pointed out in the WG session, that we should probably start a discussion on the lower boundary of assignments from the IXP pool. I would like to kick off this discussion with this post. When we had the discussion on the current policy in 2019, I posted an analysis of PeeringDB data, which I have updated with data from 2022 now (https://github.com/mwichtlh/address-policy-wg). The comparison of both analyses provides some interesting data points: 1.) The overall number of IXPs is growing fast (951 IXPs up from 672 in 2019 with 1014 peering LANs up from 726 in 2019). To me, this looks more like exponential growth and honestly speaking I doubt the linear projection of depletion in 2029 presented in the WG. I think this will happen earlier. 2.) The updated data clearly shows that the lower boundary of /24 assignments continues to create a lot of waste in terms of IP space, as ~80% of all IXPs would fit into a /25 (including 100% overprovisioning) and roughly 70% of all IXPs would even fit into a /26 (including 100% overprovisioning). Thus, decreasing the assignmemt size is unlikely to cause harm but might be very helpful to extend the lifetime of the pool into the 2030s. Another pro I see here is that lowering the boundary would allow to extend the overall size of the pool, as we could ask RIPE to add IP space dust </24 to the pool, that cannot be assigned anyways because it cannot be routed; please note that IXPs commonly have no interest in routing their peering LAN space, e.g., leaking the peering LAN space at DE-CIX is explicitly disallowed for members and will quickly lead to a port shutdown for the respective AS because we don't want a route into the peering LAN for security reasons. With regard to that, the "bug" of non-routeable IP space could even be a feature for many IXPs, because it does not require monitoring external BGP collectors for route leaks. At the same time, we should be well aware that we are only buying time. That's why we should kick off some initiative to test and deploy multi protocol BGP at IXPs (but that is probably a question for the IXP community). Regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber(a)de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net

13 35

Re: [address-policy-wg] IXP pool lower boundary of assignments
by Aleksi Suhonen 07 Nov '22

07 Nov '22

Hello, I feel that /26 is the smallest reasonable subnet size for an IXP, no matter how small the IXP is initially. If it starts growing, it will quickly grow past /27, but might just stay inside the /26. This is based on empirical experience over the decades. I do agree that it would be nice if the vendors took RFC 5549 seriously. A lot of IXPs would be ready to adopt it, if it was an option. It will create some headaches for route server scalability, but perhaps bird3 will fix those... anyway I digress... My two cents, PS. I don't think Tore appreciates how much more difficult it is to renumber an IXP compared to a data centre or an access provider. -- Aleksi Suhonen / TREX () ascii ribbon campaign /\ support plain text e-mail

4 4

2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
by Angela Dall'Ara 01 Nov '22

01 Nov '22

Dear colleagues, A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA assignment registration in the RIPE Database" is now available for discussion. This goal of this proposal is to change the registration of IPv4 assignments from mandatory to optional. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2022-02 <https://www.ripe.net/participate/policies/proposals/2022-02> As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 <https://www.ripe.net/publications/docs/ripe-781> We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 2 November 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

15 40