RIPE 88
Address Policy Working Group
22 May 2024
9 a.m.
CHAIR: Good morning people of the RIPE Address Policy Working Group. I hope you all had a lovely time last night. And we have a fun packed agenda for today. I'm going to start with something that is not on the agenda, the RIPE NCC has requested that we remind you that if you are a RIPE NCC member, and you want to attend the AGM, you need to register before the deadline. Apparently some people have struggled with the 2FA requirement. If you have not set‑up 2FA and you want to register for the AGM, either try setting it up now early this morning, or e‑mail agm [at] ripe [dot] net, so that you aren't disappointed by not being registered for the AGM. Or of course speak to a member of the RIPE NCC staff and maybe they can help you.
That is the non‑scheduled part. And now we will start with the agenda.
Because of the lack of people so we have in the Council, we wanted to be sure that we can fulfil our functions.
So, we have reviewed optional procedures, so to be sure to have the etc. And so it was finally approved and by the AC OC and then by the NRO C. So the group ‑‑ in the last October. So, there was ‑‑ so the mentions was a new definition for the Koran. So to clarify, it was the responsibility regarding the global policy development, a clear chapter regarding the voting process. We have, because there was, there were a lot of definitions around that, so it was important to simplify that etc.
.
And there is a link to the operational procedure.
So, we have that moment weekly meeting to be sure to have something to send so the NRO C at the end, and then start the process with the consultation of the different communities.
(TECHNICAL FAULT ‑ FIRST SPEAKER NOT CAPTIONED)
So, an idea of the timeline.
So, we have approval of course the timeline to review with the document. Okay. So normally at the end of June, so we will be able to ‑‑ so we are working on one more time so the meeting when we work on the document are open, and there is no specific link in the AC OC website when you can read through the work we are doing. So if you have any questions, etc., so you have a website in it. So, you can have information.
Then during the summer we will try and finalise the document and then there will be a process for the communities, we'll have a survey or something like that, to, to have, so for the community to have the possibility to make any comments. So one more time it will be open 1. The important thing, so we don't reinvent the wheel for that, etc., in terms of process, so we try to be possible to consistent, and so the idea to reach an agreement and approval and one more time so with the agreement of the different communities, original communities, and ICANN communities as well.
Okay, so the rest of the timeline on review.
Okay, and that's it. So, we will speak of this document tomorrow during a Plenary, so, one more time. And thank you for your attention.
CHAIR: Thank you for that if we wanted to find out more and track how this is being developed in advance of the public consultation, where would we go and how will we find it and what's available?
SPEAKER: So, you had the link, so you have the AOCO website so you can see that and we are still discussing, to to have a more completed document so you can review as well, so because we are working on drafts, it's not easy to publish each step of the draft etc., but so we have in mind, to have a sort of command already, so for you to read it of course. Yeah. Thank you.
(Applause)
ERIK BAIS: Thank you Herve.
Next up, Marco.
SPEAKER: Good morning everybody. It's nice to see quite a full room this early on Wednesday morning after the social, and yeah.
As a little treat I am happy to present you the latest observations and findings for my team, the Registration Services. My name is Marco Schmidt by the way and I am the manager of the edge registration services at the RIPE NCC.
In this overview, I want to talk a bit by IPv4, then about a topic, IPv6 stockpiling that we tried some interest really, talking about ASN requests and lastly RIPE NCC and the PDP.
First, off, a bit of IPv4, that's actually recurring topic on my last presentations during the last RIPE meetings, looking a bit at how the waiting list is developing, and when we are looking at this blue chart, which is a number of LIRs currently on the waiting list, it's looking actually quite boring nowadays. So you see the number of LIRs on the waiting list is now quite stable over the last twelve months or so, around 1,000.
But this doesn't mean that there are no LIRs joining the waiting list, rather, we keep on hasn't handing out repsychoical IPv4 address space which you see on this green line and the bigger jumps you see there it's six months after we deregister bigger amounts of IPv4 due to members that haven't paid their fee on time. And basically, what is two charts show, that the number of IPv6 collations that we recycle and hand out is more or less equal to the number of LIRs that join the waiting list. And as a result also, the time that members for LIRs have to wait to get the allocation, is now also kind of stable. It's currently 460 days, so like 15 months or so.
So I would say this is like a new normal on the waiting list, and I think I will not continue this segment in the next meetings, because it's just going on regularly. So far we have handed out more than 2,000 IPv4 allocations, the LIR that is currently next in line to get the next free block is waiting there since January last year. If you are on the waiting list and your number is lower than 260, then good news, you will get your IPv4 block from us within the next six months because that's the amount that we have currently in our countering pool and we'll release it quite shortly. If your number is higher, you will have to wait a bit more. Currently the estimation is if you join the waiting list, you will have to wait between 16 to 18 months to get your block there.
Moving on, IPv6 stockpiling, and if you are a reader of RIPE Labs and the interesting articles that are published there, you might have seen that the picture. Any idea who lady could be?
.
AS sand /TKRA, and for the ones that are not to deep into Greek mythology, she was living in the city of troy, she had to give gift of foresee the future combined with the curse that nobody would believe her, which is not a good combination because she knows that this horse in front of walls would be trouble, but nobody believed her, and you know what happened to the city afterwards.
And well, I don't want to compare myself with AS sand /TKRAEU, just look at the hair and so on. I did feel in the last years a bit like her. What she went through, because I presented a topic of IPv6 stockpiling several times to this Working Group, just to summarise, we have a couple of members that collect a lot of IPv6 allocations in different means partially through consultations of different LIR counts, mostly to IPv6 transfers, and when I presented it, it was received with interest. It was a curious case, so let's look a bit more into it. Let's observe what's happening and that's basically what we did. And what I can report, and that's also in the article that was published last week, the trend is increasing. It's speeding up actually. We have members that even just joined a few months ago and immediately started collecting hundreds of IPv6 allocations. And we have now 14 members with more than 50 allocations, some even more than 300, and they now hold together around 9% of the v6 space that we have ever allocated to our members.
And of course, often the question was okay, what do you do with this? And we looked a bit into how much is routed and currently a lot is still just stock‑piled, it's not in use, at least it doesn't seem to be in use, but also a good amount is now offered to be rented out in large blocks.
And the numbers are so significant, I'm not sure if you can read it, but looking at some country statistics, the top red line is from Russia. You see how many allocations have been allocated to members in that country. It kept on growing. And since around one year, it's going down, it actually has been reduced by around 25%, and why is that? Because quite some members from Russia transferred their allocations away to these few members and those few members are located in other countries that you see at the bottom, like Cyprus, Seychelles and Emirates and as a result the country statistics for IPv6 for these countries sky rocket basically.
I could go on and on about this.to I can but if you are interested, I include here the link to that article and just in a nutshell, all the issues that we see with well this behaviour is, we currently don't have the insight, if those v6 allocations are used according to policy. It creates quite a lot of work for my team to handle all those requests for v6 allocations for transfer them, retransfer them and so on. Which creates costs, which is a big topic nowadays.
Then, those people offer like a secondary market for IPv6, and parties that will go to the secondary market are less likely to become members, which is also negative for us as a membership organisation.
And actually, those third parties also get a bit of risk because they become very dependent of those members and they are business models. And if those third parties do some malicious activities, that can have quite some, can raise some attraction from law enforcement and can have some reputational damage.
What's the best way forward, and I was also in the article a bit exploring different options, but since then I had a couple of conversations, externally and internally and actually there is actually a path forward, and basically what we are going to do as the RIPE NCC, our application of existing policies has to evolve and it will evolve, because so far, v6, for many last years, it was a lot about promoting v6, get it out, every movement of v6 around our membership is a good thing for v6 deployment, but I think it's fair to say v6 is out there, it's on the market, it is a business model.
So it's time to really apply existing policy more strictly and, yeah, don't make special treatments for v6 deployment.
And actually existing policies are pretty good on that one already. I'm quoting here part of the transfer policy, where it says clearly transfer to sources are no different than resources provided by the RIPE NCC and should be used accordingly. And what does this mean for IPv6?
.
Currently, if a member, if an LIR holds v6 allocation in their account, any ‑‑ another allocation that will come to this account should match the requirements for a subsequent allocation. And there are actually quite some good requirements there, you need to show sufficient utilisation of the space that you hold already, or you must have new needs, network plans, user numbers and so on, that cannot be satisfied with the existing address space that you have. And this is the approach that the RIPE NCC will take now, and follow policies to the letter.
(Applause)
.
AUDIENCE SPEAKER: Jan resources. Thank you. It was time to do this. I have been seeing this holding of IPv6 prefixes for years, and I'm really happy that now things are happening, but can you go one slide back? This also applies to the LIR mergers, right? Not just the ‑‑ if you merge LIRs, this is also counted as a subsequent allocation then?
MARCO SCHMIDT: Exactly. Although there of course we would look into it.
JAN ZORZ: Or the transfer. Thank you very much.
MARCO SCHMIDT: You are welcome. I think somehow this is also good news that this community was busy to promote IPv6 and I think we are there now, so it's nice to just, it's just another protocol that we're using.
SANDER STEFFANN: Thank you, please use the /TPHRAOED some the policy gives you to make good implementations. And it does worry me because you see a lot of people complaining about the RIPE NCC at the moment and about the pricing and the charging scheme. And if people are now using this to bypass becoming an NCC member and we're getting a whole, like, people who are basically starting their own unofficial RIR using all this accumulated space, that really scares me, that is a very dangerous position for the membership because fewer members means the other members have to pay more. You get into the situation that the RIPE NCC can't do due diligence because other people are basically maintaining a hidden database for their customers, and I think this is a really bad situation that we, as a community, should really take seriously now.
AUDIENCE SPEAKER: Brian Nisbet: So, great, again, thank you. Is there anything that can be done about all of the resources that have already been taken and transferred and hoarded?
MARCO SCHMIDT: Yeah, we definitely will also look into that one now that we have evolved and, yeah, we will look into that.
BRIAN NISBET: Thank you.
AUDIENCE SPEAKER: Peter Hetler, I wonder when you were investigating these entities that were sub‑leasing and making available their address space, why their customers would go to them and not come through RIPE or through another LIR address space, is it purely a financial thing? Is it a contractual thing? Are they ‑‑ and I'm not accusing anyone legally, but are they planning to do something inappropriate so to speak? And what's the deniability? Like are we aware of this?
MARCO SCHMIDT: We don't have the exact insight yet. Those members can only answer this. There are some indications it might be a financial aspect, but of course it also might be an aspect that some third parties prefer this in between because of the activities that they are planning to do. But from our side it's still quite some speculation maybe.
AUDIENCE SPEAKER: Okay, as a comment to the Working Group, as we evolve our policies for allocations to deal with the stockpiling issue, we should be, we should look into and be aware of why people would go to other sources, so we can ensure that everyone gets the best results.
MARCO SCHMIDT: Thank you.
ERIK BAIS: Jordi has a ‑‑ how can I get Jordi? Can you get Jordi online? Morning.
JORDI PALET: Okay. Marco, I agree with your point on the way forward. I think it's very important, but a side comment in your article. I think also we should consider if the transfers should have justified need verification, because otherwise, I am not really sure it will be so easy as you present in the slide in the screen the way forward. I also think that in some of the cases, it seems that some of the members are going towards this path because they don't have facility for bigger locations. And towards that, there was a couple of us who put already a policy proposal about one year ago that the Chairs still didn't allow it to go on. So I hope that we can start quickly that discussion. Thank you.
MARCO SCHMIDT: Thank you. Just to respond to your first point, actually the current policies allow a valuation for a subsequent allocation, and as transferred allocations are no different, we will do the same there.
JORDI PALET: But I'm not really convinced that that's applicable to the existing allocations and to the existing transfers because it contradicts the transfers policy. So there is somehow a mismatch over there.
ERIK BAIS: Yeah. So let me comment on that.
We looked at the policy for this, and it specifically, if you see the transfers as a subsequent allocation, then there is policy in place for that and that's why the NCC is now requiring documentation on that. So, we have, as Chairs, we looked very closely, together with the NCC on this, and this is why.
SANDER STEFFANN: I am back again. I see your red light flashing already. I am Sander Steffann again speaking for myself. When Peter asked the question like what are the reasons they are doing this? I suddenly realised that the stockpiling is happening in certain countries which are also becoming more and more under sanctions at the moment. Do you see any indication that this mechanism is used to bypass sanctions?
MARCO SCHMIDT: We haven't looked deeply into that yet, but it's worth looking to it a bit more, but I don't have the information at this moment.
AUDIENCE SPEAKER: Jan Zorz. To the point of Jordi and when you responded. Initial allocation for the LIR is /29 without additional documentation. Period. If the LIR receives in any possible way more space, then it explains why they need it.
ERIK BAIS: Thank you /SKWR*PB. And we have a question in the queue.
Max bill pen" as far as I understand signing more than a /48 to an end user leasing requires the same due diligence in terms of utilisation as PI from the NCC. Will you auth large assignments from LIR to end users?"
MARCO SCHMIDT: Yes, we have the auth procedure and it gives us the possibility to do that, yes.
AUDIENCE SPEAKER: Tobias. Do you do the needs assessment for incoming IPv4 transfers?
MARCO SCHMIDT: You mean before we complete the transfer or...?
AUDIENCE SPEAKER: Yes.
MARCO SCHMIDT: Yes, I think that transfer only could be completed if the policy requirements are met.
AUDIENCE SPEAKER: Okay. Were there any rejected requests?
MARCO SCHMIDT: Sorry, so far, we have been taking the more lenient ‑‑ the soft approach to support v6 spreading but.
AUDIENCE SPEAKER: No, I was asking about IPv4.
MARCO SCHMIDT: No, no. That's what we're going to do now.
ERIK BAIS: So, to answer your question there. There is a need requirements for inter‑RIR transfers, not for v4 regional transfers. Does that answer your question? All right, we'll take that offline. Submitted I had I have a red blinking light but I still have two items. But thank you so much for the feedback that was very welcome.
I will move onto the next topic.
ERIK BAIS: We will take the ‑‑ I have two questions here, I'll read them out and then we'll go to the AS.
From
ELVIS VELEA: "Maybe ‑‑" that's not a question. That's more a statement on the part area they going to the LIRs. That was maybe they advertise their services better than the NCC.
Another remark from
ELVIS VELEA: "What will stop them from opening an additional LIR, get v6 allocation for that LIR, rinse repeat." That is basically solved with the additional documentation on the mergers and acquisitions. Because it's being regarded as a secondary allocation.
And "what time lines are you suggesting to solve this problem" that's a question from Brian story.
MARCO SCHMIDT: I think we will need just to adjust our Internet procedures and we can start very quickly on that one.
ERIK BAIS: We hear Monday. Excellent.
MARCO SCHMIDT: More or less, more or less.
Okay, moving on. ASN requests, also an interesting topic and came up already a couple of times during previous presentations during the last RIPE meeting I reported that we want to, wanted to abandon that temporary agreement between the Address Policy Working Group and the RIPE NCC to allow the issuing of 16‑bit AS numbers on request despite that the policy says since 2010 actually, there should be an unsomething set of pool. We have now implemented ‑‑ well we have now left behind this temporary agreement and we work from an undifferent shade of pool so members and end users that request ASNs get one from the pool which are currently 32‑bit AS numbers and I am happy to report that we got very few complaints and none of them have any tech ecosystem merits. It was just a bit of unhappiness, but not so muches I would have expected. Happy to report that we are fully policy compliant on that.
However, there is still a bit of point of attention for ASN requests and that's something that also my manager, James Kennedy, highlighted in a RIPE Labs article last week, and also yesterday, if you read the Plenary, he touched upon this and he will also talk a bit from the academic perspective on this one in the second session.
Looking at the number of ASN requests, and especially the writing them the requests for our members, our LIRs, and request for end users, so you see around five years ago, around two thirds of the requests were from our members, one third from end users. Now this has actually reversed, one third is for LIRs, two thirds are for end users.
So, you might say well, total numbers of request is the same. So why are you talking about it? Because it is not exactly the same. We know our members, we screen them when they become members, we have their records on file. They don't need to do many checks if we receive an ASN request from them. End users, on the other hand, usually we hear the first time from them we need to verify the documents, we have to put them in our tools to ensure sanction compliance, to ensure compliance with our due diligence requirements. And sometimes those requests also lack some quality and when we ask questions, it costs time and then even a significant amount of request is being abandoned.
We also noticed that there is a significant increase of requests from natural persons to get an ASN from us and those end users, they are based all around the world. And why is that? Why are they coming to us?
.
Well if you look a little bit through the Internet, how to get ASNs, you will find actually that there are some, I call them, ASN dealers, and you can find offers that you get RIPE ASN for a one time fee, which is already interesting by itself, because a sponsoring LIR should have an ongoing relationship and ongoing services to their sponsored end users.
Some charge a low fee for getting the ASN and one of my favourites, there is even somebody who offers a reseller package so that they get five ASNs and then people, third parties can even resell it.
What is the consequence of this?
.
So, when you, when I tried to go through those AS applications that you can submit there, something that I notice was often missing were any reference to you need to be multihomed, which is a policy requirement, you need to us auto the ASN in our service region. Maybe they asked for this after the payment, because I didn't buy any ASN, but so far, it was not there.
However the request that we get usually has all those policy requirements met.
We get a lot of requests, they take a lot of workload off us, some of those members submit everyday several requests, and on the top of members in terms of submitted requests, several hundreds per year.
And because it's so easy to request an ASN and there is currently no charge attached from the RIPE NCC, we also see a rather easy approach and ASNs are requested and one third never becomes visible or gets invisible after a very short time. We here also I included the links to the presentations of James.
What is the conclusion out of this? So the current framework of RIPE policies and also the RIPE NCC membership rules, they energy such a care free, not to say careless, ASN number requests. And here we don't discuss fees, this will be in the afternoon at the General Meeting. But, last year, an ASN fee was proposed to the membership and it was at least last year not approved. So, I think the RIPE community still should look into ideas if there's anything that can be done on the policy side. Coming to the last topic. Basically some food for thought. Currently what we do at the RIPE NCC, we present to you to this Working Group, some observations, potential issues with policies. And if you think that is a topic, then in an ideal world policy ‑‑ community member says okay, yes, I will do it. I will start the policy proposal.
But, and that is something that we observed and you probably can confirm, making a policy proposal is quite a lot of work. You have to invest time, quite some effort. You have to be really invested, you have to be enthusiastic about the change you are proposing, and you need sometimes quite a thick skin, if you look at some discussions in the last month, it can get quite hefty.
So, as we are reporting issues to the RIPE NCC and we also have an invested interest, I just wanted to float the idea here: What if the RIPE NCC can start the policy proposal? We haven't done this for a long time. And actually I'm curious to hear some feedback on that. And I think we talked a lot about IPv6 topic, but any feedback now, I see we have people lined up on ASN numbers and on the RIPE NCC which should take a stronger role in the PDP, I am very curious to hear.
AUDIENCE SPEAKER: Sander Steffann: I have always been a big proponent of very relaxed rules about ASNs. I was talking to some junior people here, and they told me that easy access to ASNs and people building their own labs and getting some space and, it's very good also for people to get involved in this community, because it's a simple thing. We don't really have a shortage. So, I don't see ‑‑ on that side, I don't see a problem with being, like you said, very easy going with this. At the same time, I have also always been a proposer of at least attaching some charge to an ASN, because when we were talking about ASN policy years ago, one of the reasons that we were keeping the policy stricter was that the NCC might get overwhelmed if we made it too easy. Personally, I would rather see a small fee, because like I said, there is work involved etc.
ERIK BAIS: Sander, we're not talking about fees here. Come to a conclusion.
SANDER STEFFANN: So, I would like to go to a solution there that does keep it easy for people to make ‑‑ to use them. And again the same as with the v6 stockpiling, do I worry about people by passing our system. So, yeah, I think we should take this seriously, but I think for this one, the solution should be more in NCC Services.
On the other point where you asked should the NC V have a more active role, propose policies? Yes, the NCC is also a part of our community. The staff at the NCC knows very well what you're talking about. And it's not like the NCC can come up with its own rules. But it can suggest things to the community that we then can see what we want to do with it.
So if the NCC has good ideas, by all means bring them to us because I think that would be to the benefit of all.
AUDIENCE SPEAKER: Tobias. Disclaimer. I have three A in my names and I sponsor around about ten end users for the ASNs. The actual issue I'm seeing is that LIRs are not taking care of their responsibility when they do sponsor an ASN. When I do sponsor an ASN, I work with that person, I tell them and I mentor them in running something that is doing things in the GRT. And that is a lot of effort and that would. Usually probably cost a lot more than the sponsoring fee of the ASN. And I think that any policy direction that we are going, should put morrow news on the LIRs to actually do that, because that is the benefit and purpose, as Sander said, we are seeing mentoring young people and it brings people into the community. If LIRs do that, yes please, we don't need fees for that and maybe if we don't we need something like a parking ticket for the LIR and not the end user.
And coming to the proposal of policy requirements. I do think that it might be a feasible idea to get more traction into the process. However, I am somewhat ‑‑ well not sceptical, I see the issue that ideally, the community would be sufficiently staffed and motivated to do this policy proposals. The community not doing that is I think it would cause problems that also needs addressing.
MARCO SCHMIDT: Thank you for being a good sponsoring LIR and also about the idea with the PDP involvement, that would be an idea that we flood the community with proposals. That would be for sure a communication with the Working Group Chairs for example what is the best way forward.
AUDIENCE SPEAKER: Peter Hessler: I came up to talk about ASNs, but I want to quickly answer should the RIPE NCC take a more active role in the PDP? Yes. My questions about the ASNs you described the end users are all around the world. We have, like the RIPE NCC has an RIR, regional Internet registry. Is assigning these resources to people out of region, is that within policy? Should it be within policy? And do we need to change anything if we decide that it should be within policy?
MARCO SCHMIDT: Well, the current policy refers that ASN should be used in our region. When we get the request, we ask especially if we see the end users based somewhere else, are you use in our region, we ask eventually for documentation like an agreement with a data centre in our region, and we usually get it. If we do a bit more research later and that costs actually time and effort, we see that not always what they tell us later turns out to be the truth. But of course also, following up on those ones, it's time and effort that we currently have to invest in other activities like serving our members.
MIRJAM KUHNE: Basically what others said. I welcome the last point. I think the RIPE NCC staff are definitely experts in that area and I would just like to remind people of the RIPE document that the community has published recently, about the role of the RIPE NCC and the RIPE community where it clearly says the community welcomes the RIPE NCC as members of the community, However on the other hand, the NCC staff obviously need to be careful giving guidance to itself. So I guess in that framework, you know, there is definitely room for more initiative. The RIPE NCC working with the community on policy improvements. Thank you.
AUDIENCE SPEAKER: An e‑mail Peter son: As a junior who got his personal ASN some years ago, this is why I'm in this industry, because one of the big reasons, because it made it possible. So, play around with these things. Get practical knowledge, and I am very happy that it was a possibility, so I would very much like that we keep going and I don't hear anybody talk against it, so that's very nice. But what I needed when I made my allocation requests was some guidance on how to do this correctly. That was, some of it, but I needed a very technical person by my side, who is sitting right over there, to help me the whole way on how do I set up all the RIPE dB things and how do I announce stuff correctly without breaking the Internet. Mid‑
MARCO SCHMIDT: Thank you and you describe exactly the challenge that the RIPE NCC and those in the RIPE community has. On the one hand we want to make it easy to get resources for everyone who has a good need and invested need without avoiding potential abuse. Thank you.
ERIK BAIS: So, we have a remark from Jordi, stating "I think the NCC not only can but should also work in policy proposals. It has been done already a few times, so why not now?"
MARCO SCHMIDT: Thank you.
ERIK BAIS: A remark from Maximilian: "Do you monitor the DM set for unused single homes RIPE ASNs?"
MARCO SCHMIDT: Not that actively and it's mostly because of resources, you know. Registrations services is very busy with many ASN requests but yeah, not actively.
ERIK BAIS: A remark from.
ELVIS VELEA: "Regarding the ASN issue, would a change in policy affect this? Thinking about something in the lines of ASNs needs to be continuously used on the Internet if an ASN is not seen in a global routing table for more than three months the RIPE NCC will initiate the recovery process, take back the ASN if the use is not restored within one month, the ASN should stay in quarantine for one year and could be reissued to the same issue if it comes back as a need."
MARCO SCHMIDT: That's probably certain ideas for the community, for this Working Group to discuss, but it might be helpful.
ERIK BAIS: And also, a remark from.
ELVIS VELEA: "Regarding the PDP question, I recommend a lot of caution. You don't want the NCC to be seen as the one writing the rules it needs to follow."
MARCO SCHMIDT: Absolutely, that's also why I just put it out as an open question here.
Okay.
ERIK BAIS: No more further questions. Then, thank you Marco.
(Applause)
.
We are running late. Currently. Due to all the discussions. Thank you Sander. But we'll try to push the ahead a bit.
MATT LARSON: Good morning, everyone, I am Angela Dall'Ara Policy Officer at the RIPE NCC, and I am here for the traditional update about policy development in our region, and in other regions, and to see what is on the table at the moment.
We are probably running a bit late, so forgive me if I give you just the main information. I'm sure you don't mind to go to the next presentation sooner.
So, first of all, what happened since we met each other in Rome?
We implemented the voluntary transfer lock proposal, now as a policy, and now you can ask specifically to lock your resources for transfer for 6, 12 or 24 months. And we have already a couple of resources under lock, and they are listed on the web. Then in April ‑‑. I can say we have all types of resources and they are by two LIRs that are waving at the moment in the room, and so this also means that if you were to go through a transition or an organisation in your company, you want to be sure that parts of your resources are not going to be transferred and so on, you can lockdown and be sure that they are not going to be transferred.
A thing that you have to remember the transfer is irreversible. So, think about for how long you want to keep it under lock. Then we saw accepted the policy proposal that adds the aggregated by LIRs LIR status for IPv4 PA assignment in April and we are now busy implementing it. I think it's going to be ready with next database release:
.
These two policies are already in the updated documents. The IPv4 address allocation and assignment policy, and RIPE resource transfer policy. So please update your records to the new RIPE documents.
Other implementations, you heard before from Marco that the transition to the undifferentiated fool for ASN numberss have been completed and you heard everything about it. And in the Database Working Group, they reached a consensus on implementing the allocated assigned PA. I think many people are going to be happy about this, because this is going to allow people to signal that the whole allocation is assigned. Before there was the need to create two separate assignments of smaller size, so now this with one single object is /SOFRG that issue.
At the moment we are no current policy proposals, so roll up your sleeves and start thinking about it. If you are not subscribed to any mailing list, you can also periodically check this page if there is something new. And if it's useful for the discussion that is going to go on later about the IPv6 policy review, I give you here TTL links to the previous discussions.
On the mailing list of this Working Group, in the previous RIPE meeting, you can watch the recording and you can also watch the recordings for the interim sessions that were held before RIPE 87.
And if you want to be involved, in the policy discussion, what you need to know is in the RIPE PDP document in the code Code of Conduct before you start discussing, it's good to have a look at it, and the list of Working Group mailing lists where you can follow the discussions.
And then let's have a look at our colleagues in other regions. I'll just give you the main updates. In AFRINIC they are almost are the with implementation of AS 0 for ROAs regarding unallocated and unassigned address space issued by AFRINIC. They are almost there. And they have these other three proposals that are still awaiting for certification but this is going to be possible only when the Board is reconstituted.
In APNIC, they implemented a new policy. In APNIC they have tiered structure for members, and they have associated members that are members that have no resources and they have only one vote in APNIC meetings, but now they are allowed to ask for a /48 PI in IPv6, provided they are committed to use it within twelve months. And this has already been implemented. And then awaiting ratification, we have a reduction of the IXP PI assignment size to/26, very similar to the proposal that was accepted in our region last year. And then they have another proposal to reserve a /21 in IPv4 and a /29 in IPv6 for search re assignment, similarly for conferences, events and anything else that APNIC might deem appropriate.
In ARIN, having two slides. They are doing a very big ‑‑ amazing job in reviewing their resource, number resource manual. This is done by the Advisory Council. That is a group of 15 people, all volunteers, and they are reviewing the text of the manual. They have a single ‑‑ in all other RIR they have a single manual. They are reviewing the text to simplify it, but also to align it with the last changes in the distribution of resources because at the moment they only distribute allocations. They don't do direct assignments any more. So there are three proposals that are at the last stage awaiting ratification by the Board of trustees, and one in last call until tomorrow.
I'm not ‑‑ let's say a slow start is already but the policy has to be updated. It is not changing anything of what is happening. It's only clarifying and simplifying the language. I'll let you read the titles of the proposals.
And here, the same. These are all under discussion recommended draft policies are a bit further in the PDP. I highlighted the reduction of the IPv4 maximum allocation that, they want to reduce the maximum allocation to a /24, and this is under discussion. I see that there was not a lot going on at the moment. There was something in February, a lot of feedback in that period. Then in LACNIC they are going to implement, it is under implementation, a modification of the PDP. In LACNIC, they have, let's say we have in our PDP, the status withdrawn for policies that are not going through. In LACNIC, we have a status that is called "abandoned" but this proposal is going to make a stinks between a proposal that is abandoned, because nothing is happening, and it can stay in standby, let's say, in the list for a long time. And the withdrawn status, when the proposal decides to retire the proposal for discussion. This is awaiting implementation, and there is another proposal on the same line, that is proposing to withdraw, or actually retire a proposal, if it says in the abandoned state for more than 12 months. And this is awaiting decision on consensus, I think probably tomorrow they should communicate something.
Then the other policies under discussion. The first two are more or less tackling the same problem. In LACNIC, allocations can also only be used in the infrastructure of the receiver. And they want to allow sub‑allocations and sub‑assignments in the first policy. And the second policy wants to allow tempey transfers. So you can imagine that this can go into the leasing area that has been discussed so much.
The /SHEURD one wants to allow DNS route servers operations out of region to receive space from the critical infrastructure pool. And the legacy resource management proposal is similar to the one that has been approved in APNIC, so where legacy holders must claim the usage of the resources within a certain time, otherwise they are going to be put in the distribution pool.
And then the last two are adding more details to the appeal procedure and to the introduction of proposals in the PDP.
Useful links if you want to know more about other RIRs in my last slides. And if you have any questions, please go ahead.
ERIK BAIS: We do not have enough time for any questions. And since there are no people at the mic or online, thank you very much.
(Applause)
.
If there are any questions that might pop up later, please bring them to the mailing list.
TOBIAS FIEBIG: Good morning. Tobias here, and I'm talking a bit about IPv6 PI.
We currently have a couple of, let me try to that I can actually see the slides. We currently have some operational challenges in IPv6 PI. It's getting relatively fragmented. Because we are getting one /48 Perrin side and they get multiple /48s from different prefixes. It's a bit unclear what an end site is so I also have seen discussions we're having two sides, geographically distant, so several one kilometres, connected by a VLAN, make them unend site. Technically etc. Not allowed to would you say one 48. Because an assignment must be specific. It is relatively difficult to justify a larger assignment with routing needs due to a missing Oxford comma. It's unclear what is a sub‑assignment and what is not. And there is a mix‑up between the policies for LIR assigned PA to an end user, and an RIR assigned PI to an end user. And there is no nibble boundary.
So the suggested changes. Should facility aggregation because aggregation is always good. It should clarify some interimable and some unclear parts. It should allow TTL use of assignments shorter than /8 across end sites. Clarify the rules for routing. And kind of preserve the very rough one /8 for end site rule of thumb which can be used ‑‑ not addressing needs but prefix needs. It should introduce a nibble boundary because they are cool and it might be a good idea to at the time it oust first. And it should keep people from hoarding things like IPv6 PI or leveraging the policy to get more PI than they actually need.
So, specific changes. Section 2.6. First change:
Here, the infrastructure gets a little bit more clarified. So, we say that it is about infrastructure, the ISP end user operates. And that an assignment holder is not allowed to create further subassignments to another entity from address space partially or fully covering an assignment.
This kind of slips in the possibility that if you kind of semi‑sub‑assign to yourself, like same organisation, there might be ways.
Coming up then is providing another entity, with address space, so this is a thing that's relatively harshly prevents sub‑assignments. And it also prevents the assignment of static prefixes up to/128, according to the impact assessment of the last changes. So IPv6 policy in regard to this point to for example a server in your rack. So if you get homed and ASN in the rack and 48 PI because you have a hobby that that is grown a little bit too big and somebody wants to put a server in you're rack, it's relatively difficult to justify that you can give a static prefix, even 128, to that server.
And that is being a little bit relaxed. The same goes for trying a service with multiple addresses. There is Jan's examples of disabounding ports and basically having one IP address they're protocol. That would also be enabled.
That are additional examples and clarifications like that you can use PI /64s on transfer links, because some people do transfer links with 64, some with 127s, but I don't want to tell anyone how to run their network. There is a lot more wording explicitly clarifying that you cannot use PI to run a little ISP providing end‑user services to DSL customers in whatever town. That will need PA. And that exclusion is also made much more explicit because before you say, for example, well, I do have these end sites because there is this router made by PP link which I put in that end site and then... yeah, anyway, clarified.
And we are also clarifying a bit the four assignments from a providers allocations part that things must be within the RIPE NCC Services region topologically.
Then there is a lot more clarification to end sites. And also a splitting of what rules apply to PI and PA. Because at the moment, there are some cross references throughout the IPv6 PI policy, which cross references PA. And that sometimes hits is he mandatory particular differences of PA versus PI and then PA rules must be applied to PI and that is then awkward and leads to unclarity and you don't know what you are actually dealing with when you are making a request.
This also includes clear definition of what different routing policies means. It also clarifies that in a Layer2 connection between two end sites does not merge them. And again it has this clear clarification like like if you just place a single device at a user's place, and provide basically Internet services to them, that's not a new end site for you.
And section 5.4. There is an additional clarification about what assignments we are talking about, when ‑‑ So this clarification at 5.4 is about PA being assigned to end users. And correspondingly, there is also clarification that is this is, for example, for assignments made by an LIR for the allocation to an end user.
In the same breath you see this little comma in the lower left ‑‑ well, right from your side ‑‑ that is actually the problem that kind of prevented the assignment of larger prefixes due to routing requirements because a missing comma means that, well entity necessitates a larger assignment, separated that sin tactically and also bound the creation of an additional assignments which wouldn't be covered by one larger one.
Then there is the term "the minimum size for the assignment is a /8". Minimum is always a difficult word because it could mean the minimum number of IP addresses. Or the minimum prefix length depending on how you interpret that, it means that you can assign 48, period. So, that has been rephrased so PI assignments are made to end users for uses within their infrastructure that do not require sub‑assignments according to... reference" and "PI assignments have a prefix link of /8 or shorter, i.e. cannot be of prefix lending/49 to/128." Just making it very explicit.
Then, a newly introduced, there is the general reasoning of let's try to aggregate. End users are basically put in a place where they should not get additional assignments but get extended assignments. Routing requirements are this time around explicitly referenced.
And then there is 7.1.1, 7.1.2, and 7.1.3. With 7.1.1 being the assignment on the nibble boundary. Idea being here that if you do qualify for a /8, which roughly equivalents to you have one end site. The NCC gives you a 48 and reserves a 44 for further growth.
If you do have two end sites you get a 44 /48 as a reserve and of course that so introduces a point where renumbering might be necessary, but the argument is that the gross periods that are allowed for you without additional renumbering should be within the range of when it's foreseeable that you grow that much it might actually be cheaper for you and us if you just become a member.
So at nibble boundaries make things better, period.
Then we have the requesting of a larger la err assignment. If you request a larger assignment you need it reevaluated and you do receive what you need. Period.
Which means that if you happen to have like ten /8s because you had ten end sites and you do request another one, you will be reassessed and you will end up with a 44. If you are lucky, the 44 will cover a lot of the 48s you have received so far. But not necessarily. And most certainly, you will not be able to extend all your 48s to 44s, because, no.
I'm currently not sure whether the ‑‑ oh yeah. Right. Very interesting mechanic I think I found is the renumbering period here, which I think is also covered in the next slide as well. Existing PI assignments ‑‑ exactly. So let me go back one. The idea is that if we have an end user that requests a new assignment or an enlarged assignment and they do already have addresses, of course they might have to re‑number. Or if you have grown from a 48 to a 44, and then grow again and obviously no ‑‑ I forgot the word, sorry, no reservation is available, then you might also have to re‑number.
That then is, of course, always operational load. We want to reduce operational load on people. So the idea would be that you say okay, those resources have to come back to the NCC, but you can extend the renumbering period, technically indefinitely. One might think well what does that do? Then we can just leave the resources with them. Well, it does one very important thing. It makes them resources that are mandated to be returned to the RIPE NCC. And those are the resources that are explicitly excluded from transfers in the transfer policy. So, in a way, if that mechanic is implemented, it means that if an end user has such resources and it required to re‑number them, free them and return them, they cannot transfer them elsewhere.
So it's like, we're not breaking what they are currently doing with it, but they can't do something new with it because they got new addresses for that.
And of course, there is also provisions for end users who already do have PI and who want ‑‑ well who will reaggregate.
This is also more policy text on the return mechanic.
Currently missing are a couple of minor things. So, there should also be a provision in there to allow assignment holders to request regression without new addressing needs. So if you currently have, and I know of these cases, a personal who has like four /8s from the same/44 separated by the /46 reservations, yeah, like it wouldn't make sense to tell them you have to request a new assignment. It would be nice if you could just have them go to the NCC and be like: Can we just reevaluate my needs and give me something that actually fits my needs.
There should also be some minor wording edits that allow the issuing of a new covering assignment. If there are ‑‑ well, if within a block that would satisfy that, there are multiple assignments to the same assignment holder already, because the current wording with a bit buggy there, there are typos that have to be fixed and other minor things. And what is most important, getting a lot more feedback on that document after people having read that document, then three people on the mailing list saying hey, that's reasonable. So please thrash the document and tell me what to do on it.
MATTIA IODICE: Let's go to the Mike.
AUDIENCE SPEAKER: Peter Hessler. So, several years ago I requested two /8s PI assignments for two separate projects. Under your proposal, where would you see this would fall under? So, they were completely separate tickets, separate requests. Would you see this as a 48 with a 44 reserved for each of them or would you see a single 44 with a 40 reservation for this?
TOBIAS FIEBIG: And this is a discussion I had also given that what triggered this policy revision was a relatively similar need of mine, which, if I would have had PI, not PA already, would have been kind of similar to what you described. I would still actually see that as one 44 from which you can then use two 48s, there are options to make that more possible. Also considering more like purpose specificity. The danger I see though, is that, if you accommodate for that you make a lot of holes in the policy, and technically, you could just use a 44 and a 48 for one thing and the other for the other. It's not nice, but going through the policy thinking about it a long time, I think the trade‑off about introduceability versus simplicity... and like, read the whole document. Discuss it, I see the point, but my assessment is like rather strict.
AUDIENCE SPEAKER: Sander Steffann: Thank you a lot for all the work you put into this.
(Applause)
I think you did a really good job, like of course there is some tweaking that probably will still happen like the previous question showed, but in general this is definitely the way forward, and again thank you so much.
AUDIENCE SPEAKER: Jan Zorz: Thank you for all the work. I already gave you all the comments that were incorporated in the proposal, and I'm also a big fan of nibble boundaries, so, yeah, absolutely.
What ‑‑ when you were presenting it came to my mind that for 20 or 30 years we are trying to different the end site, because everybody thinks of end sites from the different point of view and we are using the end site term in lots of the policy I think. So should this be somehow also copied to a different document that defines the end site in a more global level not just for these documents?
TOBIAS FIEBIG: That's an awesome idea. Please send text.
AUDIENCE SPEAKER: Benedikt Stockebrand: Some 15 odd years ago, I have been trying to figure out what an end site is or a site is. Basically about Union lock addresses of local addresses. I think the only way to define is by saying what is not a side, something that is network topologically split whatever, I had a something there like 15 years ago, I'll try to dig them out and maybe that actually helps. So saying if it does ‑‑ if it does meet any of these criteria, it's not a single site any more. That might be actually be helpful. I'll try to look it up.
TOBIAS FIEBIG: Yeah, and also take a look at the currently present text because at the moment it is indeed revolving a lot around unique routing policies.
AUDIENCE SPEAKER: Maria, speaking for myself. I would also back the proposal to define end site as what is not an end site, especially if an end ‑‑ if that place is connected to some other place with a different administrator or somebody that is a sub‑scriber, sub‑scriber supplier relationship, then it's not an end site. But the main question is whether we are trying to define the end site in the way that people are allocating too little addresses or too many addresses. And if they are allocating too little addresses, then we are ‑‑ we have to define the end site as extensively as possible to make sure that people actually at their homes get their 48 and not 64s, as is still common. Or, on the other hand, we have to define the end sites as, like, we don't want the end site to be a single phone in the customer's home.
TOBIAS FIEBIG: So. I see two points. A) I see the important role of the end site for the NCC to roughly rule of thumb addressing needs, because counting in the area to like 17 or something, is relatively a simple task versus calculating HD ratio. And second, what I would propose is to stick with the slightly extended version of end site in this document and given the wealth of discussion you can have on the meaning of end site, moving that to an end pent policy proposal, because otherwise we are trying to bake a cake with also very many raisans and also with sausages included and that doesn't usually taste that well.
ERIK BAIS: I have one online. Maximilian: "As far as I know currently a 46 is reserved for the 48 assignments. Will users be able to extend 46 without renumbering?"
TOBIAS FIEBIG: So, there is a provision about that in the document. If possible, users can re‑number. So if there is a 48 where a 46 is reserved, and the next 46s I think should be four, well, in total four, so three more, also currently not assigned to an end user, then of course renumbering is possible. You might also have the case that you find neighbours who together go to the RIPE NCC and say hey, one of us would like to get a new 44 and the other one is willing to forfeit theirs, it could also happen. I mean, members should play along and members should make their end users play along as well. And then there is, of course, a provision of well, if you do want to re‑number, go for it. The existing 48 is placed under a must be returned, please re‑number and you get a new one. And yeah, we can't make addresses appear out of thin air.
PETER HESSLER: Because of the end site discussion, you actually said most of what I wanted to say. I just wanted to add two little equips. The Working Group is, remember, perfect is the enemy of good, and we can paint this bike shed any colour we want to. So make it simple in this proposal and then having much more specific one for general use that would incorporate into all the other documents as a separate document.
TOBIAS FIEBIG: Yeah.
ERIK BAIS: Thank you.
(Applause)
ERIK BAIS: Then we'll go for coffee and I'll see you back in a half an hour.
(Coffee break)
