RIPE 89
30 October 2024
Address Policy Working Group
9 a.m.
LEO VEGODA: Hello everyone, good morning. I can see people are trickling in, which probably means that everyone had a lovely time last night. We have a genuinely packed agenda for both this session and the session to follow, so, we do need to be relatively strict on the time. So, let's get going.
And welcome everyone. This is a hybrid session. That means there is people in the room and there is people online. You can participate through meet Meetecho, and when you speak at the microphone, please give your name and affiliation. If you want to make a comment or ask a question, whether you are in the room or not, you are welcome to ask your question on Meetecho and Ed will read out the question for you, and we would very much welcome questions that are asking suspecting relatively basic. We don't want this session to be something which is only for insiders, we want it to be welcoming, that means we have got to make sure that people feel comfortable asking the fundamental questions, and so, if you have a question, there is probably other people who also have that question. Feel free to ask the question and you'll get answers.
We have a Code of Conduct. It boils down to please treat everyone else with respect, and they, in return should treat you with respect.
We would like to thank our scribes, Allen is taking notes for us today, and Mary is doing the stenography, thank you very much. Genuinely useful both excellent services.
We have minutes from the last meeting. They were published and we got feedback, which is really good, Both because it means the minutes end up being better and because it means people are actually reading the minutes. So, everyone who commented, your comments are appreciated. Your comments have been integrated into updating minutes. Are there any any objections to accepting the published minutes as final and carving them in stone?
Seeing no objections. The minutes are accepted.
ALEX LE HEUX: Good morning everyone. Shortly after the last RIPE meeting, Erik Bais our co‑chair sadly passed away, and when Erik asked me to volunteer for the Chair position, this was not the moment I envisioned. And I think I speak for many people when I say that's, that his absence here is as loud as his presence always was before. And to be honest, I find it pretty difficult to be here without Erik. I have had a few difficult moments already.
What's really lovely, though, is that in this community, when something like that happens, there is always some warmth and love. There is always someone to listen, maybe even a shoulder to cry on. I think that's one of the things that Erik always brought to this community, that in our daily work we built networks, we manage things, we write policies but in the end everything we do is about people first, we are humans first, and I think Erik always was very good in that.
And Erik, I think he touched more of our lives, or more people's lives than anyone can know. And I would like to invite or even encourage everyone who has had even a short meeting, a short talk with Erik, to seek out the condolence register, that's the RIPE NCC was kind enough to set up opposite the registration desk, and right write down a little memory or something, because Erik's family was always very supportive and very proud of the work he did, and maybe reading all your little stories is going to make his passing ever so slightly easier for them. So, please some time this week find a few minutes and write a few words in memory of Erik.
I will miss Erik a lot. And if any other people in this room would like to add a few words, then there is space for that as well. Either at the microphones in the room or here.
MIRJAM KUHNE: Thank you Alex. It's hard for me to find better words than you already have found, but I remember we were sitting actually in Krackow outside in the grass, the Working Group Chairs, and Niall and myself, we made some plans, certain projects and activities, we were all going to take on and move ahead and Erik as always was being very active and constructive and engaged and passionate about making this community better. So he really cared a lot about this community and about individuals in this community. And as you said at the beginning I have a feeling it's got a bit more empty and quiet, certainly he in this room, and he will certainly leave a gap, and he left a mark of course also to this community. After we take something for granted or someone for granted until we have to miss them, and I will certainly miss Erik in this community, and will probably remember him for a long time, and yeah, it's all I just wanted to add to this. Thank you.
SANDER STEFFANN: All the years working with Erik with coming up with new crazy ideas and policy proposals, later he became the Chair himself, so, he experienced what it was to suffer at the other end, but he always did such amazing job and like you said, he was always there for people, and in the run‑up to this meeting, even though I knew he was gone, inside all the time I expected to just run into him at the airport or outside in the smoking area or somewhere, and I still don't fully parse that he is gone. It's... he will missed a lot.
NATHALIE TRENAMAN: Now, I don't like to go to microphones. I speak now. Also I think on behalf of my fellow NLNOG crew I would like to say something about Erik's incredible sense of humour, and his dark, sometimes inappropriate, sometimes quite extreme but always hilarious giving /24s away at NLNOG quiz with a huge cheque, always finding ways to set a little fire here, or make a joke there, and that's what I have been missing in this week tremendously is that hard laugh and that humour.
BRIAN NISBET: I think again, and it's what Nathalie touched on, it was the joy, and as you said Alex, the joy in in community, the joy in the people who he got to interact with and work with and help. And I think that as we have, with other people who have sadly, members of the community who have passed away, it's taking that inspiration, that joy and kind of going how can I be more like that? Maybe not the extreme sense of humour all the time, but, you know, how can I bring more of that joy into this community and make it a better place. And that will be my biggest memory and thing that I will carry on.
ALEX LE HEUX: I think we would now like to observe one minute's silence and remember Erik.
(R.I.P. Erik, gone but not forgotten!)
LEO VEGODA: Thank you everyone. So, we do need to return to business. We have a packed agenda today on both sessions, so, in order to be respectful of everyone, we do need to be respectful of time, so, we are going to ask everyone, when they have questions, to wait until the end of the speaker's talk and then ask the questions at the queue.
This is the agenda for us, our first session, this session. I had a question mark over who would present for the ASO AC, and this is both Constanze and Herve, both presenting. In our next session, we have three very packed talks and a little bit of time at the end for Open Mic, anything that anyone wants to raise, does anyone want to suggest any changes to the agenda that we have planned? Is there anything that is is not going to work for anyone?
I'm seeing none.
This is our current session agenda, I am going to invite Constanze and Herve up to give an update on the ASO AC, thank you very much.
HERVE: Good morning everyone, not very easy to do a representation just after this moment but we will do the business.
Constanze Burger under Erik Clement so we are currently the two RIPE NCC Services region representative for the NRO NC and serving for the ASO AC functions. Constanze will first present as I say the usual acts of the ASO AC and I will a few words after that about the ‑‑ you see the questions regarding ICP‑2. I will just say a few words and it will be developed tomorrow during the Community Plenary session. Thank you.
CONSTANZE BURGER: Hello good morning. First of all, it's very hard to speak after these words, I knew Erik as well and he is gone too early.
My name is Constanze, I was elected to the NRO NC in the last year, and I wanted to thank you again for the trust. It's really structured disciplined and well educated Council, thank you for the leading of the Council, Mr. Chair. So, I wanted to introduce what we do.
So, the Number Resource Organisation council is established to serve the ‑‑ to support the ICANN and the RIRs in case of address parting organisation stuff, so we are binding unit to inform and synchronise our belongings with the ICANN.
How we are organised:
We are usually 15 members. Each from ‑‑ three persons from each region. In each region, two members elected from the community and one member is appointed by the RIR Board.
How long do members serve?
This is quite different and depends from the region. In between the electing phase is from two until three years.
What are we doing?
So, we advise the ICANN Board. We oversee the global policy development process. We appoint two members of the ICANN Board. And we appoint one member for the ICANN Nominating Committee.
When does it meet?
Usually we meet monthly and the face‑to‑face meeting is annual, but in the moment, we have a lot of work and Herve will continue later.
You see here the members of the NRO NC. You see we have no persons mentioned on the AFRINIC side. And we have one member less in the RIPE NCC, and you see here Herve Clement, our Chair, and Nicole Chan, our Vice‑Chair, she is also in the room here and Riccardo is from LACNIC, he is not able to come. We miss one person in the RIPE NCC ‑‑ Sander, yes, we miss you a lot, but in case of the rules of the RIPE NCC is not, Sander was not able to join us any more because he was elected to the Board. So, we are hopeful that we can welcome a new member after this RIPE meeting and I want to motivate to elect please, then we have three members on board on the RIPE NCC side.
What are we doing is really transparent. We have annual face meetings. These are open to observers. The last meeting was in Sanquan, the next meeting is in Istanbul, feel free to join us. Our mailing lists are open with archives. We have a wonderful structure. We have a lot of information on our website. You will find the documents, protocols, information in ongoing procedures.
We have these monthly telephone conference, it's open as well.
Global policy development is also a task for us. If NRO NC members follow their respective RIR policy forum for any proposed global policy, then we are going to coordinate this and we want to take over and vary the rules and try to cooperate in this case as well.
The current appointments from the ICANN Board is Alan Barrett, he was elected in May of 2025, and Christian Kaufmann, you know him, he is also in the ICANN Board.
Now, I want to motivate the ICANN Board seat is, it's open for nominations. The nomination phase is from 16 September until 16 December. Please nominate if you are interested. You will find all the information on the website.
And now, I hand over to our very important task for the ICP2.
HERVE CLEMENT: Thank you Constanze. So we were requested last year by the NRO AC, this time, which is a body comprises of the four current CEOs of the different regions. On two important tasks, two consolidate the governance system globally. So, coming back to the NRO AC, Hans Petter will take the lead of the NRO AC from 1 November, as Oscar, the CEO from the LACNIC is stepping down at the end of this month.
So, just a little piece of history.
In 2001, there were three RIRs, so the RIPE NCC, the APNIC and the ARIN. So 2000, the ASO AC recommended to recognise new Internet registries and this is ICP‑2, this is the document which is the Internet coordination policy, it was adopted by the ICANN in 2001, and because of this ICP‑2, and we have ICP‑2, the LACNIC first in 2002 and the AFRINIC then in 2005 have been created.
The ICP‑2 review project requested by the NRO AC in October 2023, with two tasks because it was important to consolidate this document created in 2000, so 23 years ago. First, task is the ICP‑2 implementation procedures, to be brief, the criteria defined in the ICP‑2 current document was only serving to create new regional Internet registries, but ‑‑ so it was requested to take this criteria into account for the current run of regional Internet registry to have criteria as defined to see if the things are going well. But it was the first task. And the second one is to strengthen the ICP‑2, so in other words to update the criteria because in 23 years the world has evolved, that's the reason why it was requested to do that. So it's something we have done in collaboration with the NRO AC, with the legal, and now it's very important to have something very consolidated to have the advice from the communities, so the regional communities, the ICANN communities globally.
Just an overview of the agenda. So the first task I talk about, about taking into account the criteria for the run of regional Internet registry, it's something we are worked in January, we proposed it in February. And it was pretty accepted and we have worked then to the principal document to update the criteria, and now you have the questionnaire, you can go to the questionnaire, have a view on this criteria and give your advice through something like strongly supported etc to the criteria. It's nothing very ‑‑ something new that we have created, nothing from scratch, but updated and to be sure it's adapted to the current ecosystem.
After that through the questionnaire will end nearly around 25th November and we will be able after to analyse that, to take into account and there will be another round of consolidation to the communities to have something consolidated.
There is a QR code to the questionnaire, so you can go directly to it, and you have the slide via the RIPE 89 website.
And that's it. And one more time, so we will try to explain that more slowly and more completely tomorrow during the Community Plenary Working Group. Thank you.
(Applause)
LEO VEGODA: Thank you very much. Thank you both. And I'd also like to express thanks, not just to the ASO NC and the NRONC but also the staff who who put together that questionnaire, it really is a very effective form of consultation, and would I like to urge again everyone in the room. Just go and take a look at it, answer the questions that you want to answer. It's very effective form of consultation.
HERVE CLEMENT: Yeah the communication team was from the region so all the staff have been very, very supportive to that. So thank you.
CONSTANZE: I have one thing to add. The time has changed, and so, the Internet policies, we have to change it as well. So, and this ICP‑2 policy is from 2001, so please do the questionnaire. That's my favourite wish for today. Thank you.
LEO VEGODA: Thank you. He had?
AUDIENCE SPEAKER: Good morning. I have one comment or question from Jordi Palet online. "I already answered the questionnaire some weeks ago. No feedback received. Not sure if this will be provided in some way or in a selective document." (Collective)
HERVE CLEMENT: No feedback received is, so we are waiting for people on all the communities to provide a questionnaire and we will analyse once we will have all. Not to add some to the answer from the others.
AUDIENCE SPEAKER: Rudiger Volk. I'm not sure whether I missed it, that may have happened. What would be interested in hearing a little bit of outline, what actual changes you have in mind and in the plan for the ICP‑2. I remember that a year ago in Rome, Randy was giving a really nice talk and pointing out quite specifically problems of the existing document, and I am really looking forward to seeing answers to very particularly for that.
HERVE CLEMENT: It will be difficult in a few minutes or seconds to answer, so all the questions, perhaps we can go back to the presentation from Randy, he has presented last year, to see point by point if finally it was etc., etc., that's a good point. Thank you Rudiger. And after that, for instance, so there was 20 years ago, for instance, a big importance of the word of ISPs and etc., so is there are no more actors in the ecosystem, for instance. So, the technique of the Internet is different, there was some governance events happening after that, etc. So, I think we have answered the question, but if you want, so we can go further to that and to answer one more time.
LEO VEGODA: Thank you very much. And Angela, would you like to take the stage?
ANGELA DALL'ARA: Good morning everyone, I am Angela, Policy Officer in the RIPE NCC, and I am happy to give you the traditional update regarding the policy development process in our region, the current topics that are under discussion and also give you a brief overview about what happened in other RIRs.
So, since we left each other from RIPE 88, we implemented a couple of changes in the statuses for the RIPE database. One was coming from a policy proposal that was implemented in July this year. And now you can register multiple IPv4 assignments that have the same contact details and have the same purpose under a unique object with a status aggregated by LIRs. This makes it similar to IPv6. In IPv6 you have to specify an assignment size. In IPv4, this is optional, you can have different sizes of the assignments included in this inetnum object.
Then we implemented also the allocated assigned PA for IPv4. This is a particular case because you can modify your allocation inetnum when you assign it, it is an authority to your infrastructure or an end user. So in this case, you can just modify the status of the inetnum object.
This was implemented in May and was following the discussion in the Database Working Group and registered, recorded in the Whois release 1.112, and this brought changes, updated the support addresses location and assignment policies for the RIPE NCC Services region. Currently this document is RIPE‑826.
Then you will see now today during the session, what we are now under discussion are two policy proposals, both regarding IPv6. The first one is revising the IPv6 PI assignment policy. And the discussion phase ends on 22 November. It's touching on many topics. It's reviewing a bit the usage, the assignment size, the practice for assignments, and the renumbering of assignments, providing only one assignment instead of multiple assignments in some cases. Tobias will deal tell us more about that.
And then we have another policy proposal that is suggesting to extend the current is / 29 to a /28 for allocations in IPv6. And Jordi will give you more details about this proposal.
For this proposal, the discussion phase ends on 12 November, and both are affecting RIPE‑738 allocation, IPv6 address allocation and assignment policies.
Then we have a suggestion from a proposal from Remco. Here you have the link to his proposal in the mailing list, to simplify the assignment status, to reduce them, and this would affect RIPE‑826, again that the IPv4 address allocation and assignment policies, but would have also repercussions on the IPv6 allocation, so Remco will tell you more about it.
Forward now to our PDP, I thought to give a bit of update regarding the PDP timeline. We have standardised process and it's divided in different phases. The suggestion for the proposal is the really initial phase, so Remco is going to seek feedback if his suggestion can become a proposal and be submitted to start the PDP officially, while the two policy proposals are in the discussion phase. The discussion phase is used to, let's say, reach a sort of text that can be a candidate for the new protocols. This is a good moment to make questions, to ask for clarification, to offer feedback, to find an agreement with the proposal for a, let's say, a version of the policy that can be analysed by the RIPE NCC to provide the impact analysis, and also to be discussed in detail in the review phase, provided this is going on with the PDP.
I really would like to remind you that if this proposal would go to the review phase, your comments, your objections or your support should be repeated during the review phase, because during that phase, all comments are counting for the consensus determination that has to be done by the Working Group Chairs, so this in times is not clear, but this happens because at that point, you are really discussing a policy draft. So, repeat please your comment in case these proposals are going to the review phase.
In the last call, if the proposals are going to the last call, no comments are actually confirming the rough consensus that has been reached at the end of the review phase. So only new objections can be submitted.
Just to clarify for who is new and for who doesn't remember how the PDP works.
What happened in other regions?
Going very fast. Let's see if something can be done ‑‑ will be done in AFRINIC if they receive, to manage to have the Board reconstituted shortly. I don't know how these proposals will be considered, also because they are already a couple of years old, awaiting ratification for a couple of years.
In APNIC, they have no new policy proposal, but they are busy implementing a reduction of the IPv4 assignments for the IXPs. This is similar to the proposal that we accepted recently for reducing to /26 the assignment for Internet Exchange points. And the assignments of a separate pool of resources for temporary IP resources. If I remember correctly, it should be a /21 for IPv4, a /29 for IPv6, and 8 AS number if I remember correctly.
Then in ARIN, they are implemented four policy proposals that the last two are just a clean‑up an editorial change. And the first two are actually codifying what was already a practice, because the first one is a slow start, it was a gradual implement a rate in allocations that was already, let's say, not in use since the free pool was exhausted. And the ARIN wait list qualification is clarification about how ARIN can evaluate the requirements for ISP end users and so on.
Then last week, ARIN had a very busy public policy meeting, discussion, that there were 12 proposals on the table. The Advisory Council and the community did a wonderful job in reviewing the manual and they are still busy ‑‑ as you see, there are many clarifications, definitions and so on. So, going through the recommended draft policies, we're waiting, let's say, to see what the Advisory Council is deciding, they recommended draft policies could go to last call, and if you see there is a set of definition and clarifications, direct assignment language update comes from the fact that ARIN doesn't make direct assignments anymore and only allocations. And the rest are clarifications and definitions. I won't go into details because more or less the title of the proposals are telling you about the content.
Instead, the draft policies, there are also here definitions and clarifications, but there is a reduction of the maximum allocation under discussion for IPv4. At the moment, it's not clear if this is having support or not. They would go to ‑‑ if this is accepted, it would go to /24 like it is in our region.
.
And ARIN‑2024‑8 would restrict the largest initial IPv6 allocation to /20. ARIN assigns allocations in IPv6 to the nibble boundary and at the moment the largest allocation that they issue is 1 /16, and this policy would lower the maximum size to /20.
All the rest I think doesn't change the practice for the distribution of resources and are mostly definition.
The last one: IPv4 transition efficiency reallocation policy. You see they also provided an acronym for that just to five better the proposal, would allow the redistribution of very small sub‑net for the transition to IPv6 when operators receive a particular Sub‑net dedicated to this purpose. So ‑‑ but it is a proposal. It has to be decided by the Council if this goes to draft policy.
In LACNIC, they implemented a couple of proposals that change the PDP, and the second one is interesting because now they can, the moderators of the PDP, can abandon a proposal if it is to the worked on for more than one year. Before, in LACNIC, a proposal where let's say in standby, they were dormant for a long period. Now, after one year they can be abandoned.
And lack‑2023‑6, allows also DNS route server operators from outside the region of LACNIC to receive resources from the special global critical infrastructure pool.
Under discussions, they have two proposals, one is to allow temporary transfers in the region (LAC) and the other one is to create a page where there is a log, where the, they make visible the assignments made from the pool of IPv4 addresses that are reserved for critical infrastructure. And there are going to be under discussion I think the second one until the 4th November and the first one until 11th November, so if you have any comment, provide it really soon.
And as usual, I leave you with the useful link. The first one is the RIR comparative policy overview. It's updated every three months, with the main aspect of different policies in different RIRs. And the other ones are the links to the policy manuals and the policy proposals in different regions.
And with this, I am done. If you have questions and you want to keep them for later, you can also write to me to pdo [at] ripe [dot] net.
LEO VEGODA: Thank you very much Angela. We have time for one question.
AUDIENCE SPEAKER: It's just a clarification. I am Karla from APNIC. So, just a clarification on the prop 156, the temporary assignment is for conferences and events only, so that's just a six month temporary assignment to it's not a general one. The details are in the deck but I just wanted to a make a point of clarification there.
ANGELA DALL'ARA: Thank you, Karla.
LEO VEGODA: We don't have anything online. In that case, Angela, thank you very much.
(Applause)
And we now have Marco coming to the stage, and we're not going to let him go until the coffee break.
MARCO SCHMIDT: Good morning everybody. I am Marco Schmidt, I am the manager of the RIPE NCC Registration Services and I would like to give you the regular update from my team, what do we see and where policies works, not working, what we do with our procedures. But first I want to say that I feel already that for me personally this is not such a regular update due to the very loud absence of Erik Bais. I worked with him in several policy proposals that he did. He usually moderated this session. He asked questions, he was supportive, he was challenging when it was needed. So, I really miss him, and I also think one of the best things that this Working Group actually can do in memory of Erik Bais is to continue this very important work that this Working Group is doing for the registry in our service region and in for the good of the Internet. I think that's very important.
And then to go into my updates. First I would like to tell you a bit about what's going on with IPv6 allocation transfers.
To the ones of you that have been at the last RIPE meeting in Krakow, you remember there was a very intense discussion on this observation that there are a few members that are stockpiling, collecting a lot of IPv6 allocations through transfers. And there was a clear guidance from this Working Group actually that the RIPE NCC should try to prioritise the policy requirements stronger, meaning an LIR can get one allocation without much justification but everything additionally would need to pass through a need justification.
And we are doing this since June. We still apply a more flexible approach. If we see there is something usable, the allocation and transfer is passionally used and so on. But other things is unused, then we come to an agreement that maybe the unused resources that the receiving party has instead are being returned. Also, if it turns out that both parties actually don't want this allocation any more, but they also don't want to go back to their CEO to have to transfer agreements signed, then we say okay, we process the transfer and the receiving party returns the space straight away afterwards. It's maybe not so good for the statistics, but it's in a more practical approach.
And I think that helped that overall there's a pretty good acceptance what we observed by the members. And only a few expressed some disagreement, and we are shall working on it also to make it more clear, make people more aware even before they are submitting allocation transfers of IPv6 type, what is required.
It is effective because we still allow transfers where needed and unused address space in the sense of a good address management is being returned.
Looking at some numbers.
So basically the last four months, we do this adjusted approach, and I looked at the previous three periods of four months and you can see a clear drop. So, before until May this year there was a huge spike even in allocation transfers, more than 800, and in the last four months, we have 79. And even of those 79 there were around 30 for such cases where in order to ease the process for the two parties, the resources were transferred but then returned straight away afterwards.
And also, it's good to know we have cases where allocations are being transferred and there is a good need for it and then of course we support that.
We also apply a similar approach, a bit more soften for LIR consolidations. People with more LIR accounts they can request an application for each account, but also the policy talks per account per LIR, so if then that they try to consolidate that we also check if there actually is the utilisation requirement, the policy requirements are met.
We also are keeping an eye out, it is possible that a member, an LIR got an IPv6 allocation, they transferred it away because they don't need it and later they want another allocation. That can happen. There are good reasons for it, but if somebody would like to do this again and again, then we would challenge this a bit more, but that's so far not happening.
And we also are planning, if we the workload allows it to actually some audits of members with many IPv6 allocations to understand better their need and if this is complying with our policies.
Next update that I would like to give is about IXPs, and IXPs assignments.
Around one year ago there was a policy proposal accepted by this Working Group to reduce the default assignment size for IXP, the IPv4 assignment size from a /24 to a /26. So, for you who don't know we still have a dedicated IPv4 pool for Internet Exchange points only, and if an Internet Exchange point refused the requirement we can provide them IPv4.
And at RIPE 85, basically I presented that on the current consumption rate this pool would deplete in a couple of years, and there were concerns because this critical infrastructure is needed. So, a proposal was discussed and reached consensus to provide smaller assignments by default and bigger if just identified.
So now twelve months have passed, it's good to have a look what happened there. And you see here, the numbers of approved IXP assignments over the last five years or so. And the dotted line shows from which moment the new policy kicked in. And you actually see yes, there is a little reduction, or there is a reduction in requests but still requests are coming in and being approved. So, also, these assignment sizes are useful for IXPs, and if you then look actually at the amount of address space handed out, due to the smaller assignment size by default, you can see a big difference here. So, before per quarter, we had several thousands of IPv4 addresses to IXPs and now this amount is significantly lower. It's around an average 1/26 per month. And if you keep in mind that currently our dedicated pool of IPv4 for IXPs is a bit more than a /16, if you do the MAT you come to an estimated depletion date somewhere in the next century, which is actually probably nobody in this room, if nothing changes, will see that depletion and I think that is mission accomplished for this Working Group so I think it's a very good success story.
Another update I want to give is about temporary transfers. You saw in Angela's presentation, other regions actually discussing such policy changes. In our region, temporary transfers exist since quite a while, so somebody wants to make a transfer, it can be permanent, it stays with the other party, or it can be for an agreed period of time and then it goes back to the offering party.
And at RIPE 86, I presented on that one, especially that we observed some very short and very long transfer periods which are a bit confusing. Also, that by design, there are different rules about temporary transfers because there is no holding period, there is also ‑‑ it cannot be transferred further. And we actually saw also some complications if something would happen to the involved parties during the transfer period.
And on the last point I have actually good news. A few weeks ago the Executive Board approved a change to the RIPE NCC transfer procedure, so not a policy, the procedure under which we are working, that is based on the policy, and thanks to a very good collaboration with my colleagues from the legal team, especially Theo, we actually clarified now this this proceed what will happen if something happens to the parties during that transfer period. If something happens to the receiving party, they are a member, at the terminate their membership, they are an end user, they lose their sponsorship, they can't find a new one or they might be even subject of EU sanctions in that case it's pretty clear it goes back to the offering party and we now have this now documented. And if something happens to the offering party, they terminate their membership, then in this case at the end of the transfer period it will be deregistered because the member doesn't exist. If it's an end user and they don't have a sponsorship anymore or cannot establish a new one within the official documented periods, it also would be deregistered and for the case of the offering party becomes subject to EU sanctions, the RIPE NCC would take control of this address space at the end of the transfer period, we would set it aside and it will wait there until that member hopefully will be no longer subject of an EU sanction.
There is still something that this Working Group maybe can consider to take action or not. We still receive transfer requests just for a few weeks, which costs a lot of work. And we also receive extremely long transfer requests, ten years, the maximum is almost 20 years, so it could be a consideration to define because currently in the policy there are no specifications about temporary transfers to... does it make sense to make any reasonable transfer periods documented there? So, that would be food for thought.
And the last topic that I have is also related to transfers. Transfer statistics that we publish on our website. Here is a screenshot below, and what we are publishing currently is a very respective defined by the RIPE transfer policy. I quoted it here, so we published two involved parties. We published the original range, the transferred range, what type of transfer it was, a policy transfer or merger, and the date.
However, there actually are ‑‑ we also sometimes get additional requests, or we get requests for additional information, people would like to know actually in which country those parties are located. Is it a permanent or a temporary transfer? So I just mention a temporary transfers are a bit strange because if you look at the transfer statistics it appears that the same party, at different times, transfer the same range to a different relieving party. So it's currently missing this information.
So, it would be probably beneficial to show that, and I want to actually ask this Working Group do you think that the policy requirements should be seen as a minimum standard and that the RIPE NCC, based on need and observed and justified requirements, provide more information in the transfer statistics? Or of course the other option would be, run the PDP extent very prescriptive list and do this update?
That is the end of my first presentation. I am looking forward for comments and questions.
LEO VEGODA: So, any questions?
AUDIENCE SPEAKER: Wolfgang Tremmel. Question: How many of the new IXPs were actually happy with the /26, and how many immediately asked for a larger network?
MARCO SCHMIDT: I don't have the exact numbers but over all there was not a big discussions and so on. So when we received the request, it went actually pretty smooth and of all the assignments that we handed out, it was mostly /26, and I think one or two could justify a /25. So, it went smoothly.
AUDIENCE SPEAKER: Gert Döring: Thanks for the update. Thanks for the clarification on the transfers, what happens if there is a sanction or a close down or whatever, because that is helpful just to understand what you do and why you do it. And that seems to make sense.
On the question of the transfer statistics my personal feeling is that we shouldn't micro manage you. So if you say it's useful to add these columns, please do.
AUDIENCE SPEAKER: Clara Wade, AWS: Great to see the implementation of the changes to IPv6 transfer procedure, having the needed effect, so great job on that. In terms of temporary transfers, I think if we're receiving requests for just a few days and especially considering we currently do not have transfer fees, and this increases costs for NCC staff and diligence checks, yes, we should definitely have a minimum period, I believe.
And I guess the community will probably look to you to determine what is reasonable there in terms of use cases. And in terms of statistics, I agree that we trust your judgment in terms of what should be reported and I think categorising whether it is a permanent or a temporary transfer would also help us understand what ‑‑ you know, the current situation is a little better.
ED SHRYANE: There is one comment online from Jordi Palet: "When I discuss about temporary transfers policies in other regions that don't have them, APNIC and LACNIC, suggesting minimum or maximum periods is always a heated discussion. If the folks in the room have a different view for this region, I am happy to work on a proposal. I think a minimum transfer period should be 30 days, not sure about maximum."
LEO VEGODA: Thank you very much.
AUDIENCE SPEAKER: Tobias: I was wondering whether there were any IXP assignment requests did not ask for v4?
MARCO SCHMIDT: I don't know off the top of my head. I'd have to check with my team and let you know.
LEO VEGODA: Well, Marco, please don't run away. Thank you very much, and now we need to ask you to speak again. Thank you.
MARCO SCHMIDT: And just because you cannot get enough of me, I am going to stay here, but I promise this is the last presentation that I plan to give during this RIPE meeting.
Leo actually asked of me around a month ago, there was an Open House organised by the RIPE NCC on the topic of personal ASNs, to give you a brief recap and some more considerations after that one. So, I included here in the slides, the link to that Open House, and first of all, to one of you that might not really be familiar what is a personal ASN, actually also I have to admit I had to look it up for a while, or I had to get familiar again. It's basically that an individual gets an ASN and it starts testing, deploying it on the network at home to see how things are working and so on. And I also should say that currently in RIPE policies, and also for the RIPE NCC, that term "Personal ASN" doesn't really exist in our work flow. We hand out ASNs to legal entities, or to natural persons based on policy requirements.
And the discussion actually during the Open House focused a lot around okay, how good or bad is our personal ASN, so there were some concerns, do they actually meet the current policy requirements? Or they maybe tell something that is not really true. Is it something negative for the quality of the data. Is it maybe something impacting the service region concept? But the discussion was, I would say, inconclusive, but it was good to have it, there were also actually two RIPE Labs articles on that topic representing very well the different points of views on that one.
Taking the perspective from the RIPE NCC. I think if really personal ASNs are something that should been coded in RIPE policy, it would indeed need a policy change, what is a personal ASN, what are the requirements. But I am personally not sure in this is really needed. But actually I felt it touched upon some wider topics, like where should RIPE ASNs be used? So ASNs issued by us, is there any concern where they are being used? And also, do our current policy requirements still align with what is needed in the Internet ecosystem?
It's a bit difficult to get very good data there, but looking at the service region concept, I had a brief look after around 38,500 ASNs that we currently should, where the users legal registered. That is necessary where the resources are being used but it's a first indication. It's more than 95 percent are registered to holders that have a citizens, that are legal registered in our service region, and 1,700 are registered to people living or being organisations registered somewhere else in more than 50 different countries and economies. The largest one are the US with more than 700 and China and Hong Kong I combined them here and also there are some countries that are known as tax havens, they also hold a lot. But we even have holders from rather remote and exotic locations like Brunei, Togo or Tockalow.
Still if you look at the keep it's a rather small.
Then the more interesting part for me at least is the multi‑homing requirement. Right now in order to qualify or to justify the need for an ASN, you need to have a new routing policy with at least two peering partners, and you only can actually submit the request if you fill in two peering partners, and they must be different.
But now, looking at the reality, what we see out there, so I ask my team to check okay, what is the visibility? And of all the 38,500, it was actually only half of them appeared multihomed. 30% look single home. There might be some that have a backup peer so that could be also counted as multihomed and around 20% is not visible at this moment. And as we were talking about personal ASNs and personal ASNs are usually related to natural persons, he looked there at numbers as well, it looks a little bit less good, but overall, also not that different from the overall average.
So, of course one approach would be okay, there is this requirement of the policy that must be enforced, but actually that's why I put it here also involved it might be a good question: Is this still relevant? But first off, you also saw there was a significant amount of ASNs not being in use, but I do expect that this number is going down as a result that there will be a charging ‑‑ there is a fee from next year based on the charging scheme. And also, my team makes special efforts to each out to unused ASNs and right now reaching out to members that are sponsoring many resources to review their pile of resources if they are still all needed, if they are still all sponsored.
And we see already that in the last month, so, an average between 150 and 200 ASNs are being returned, and I expect this will even pick up towards the end of this year. And I actually want to use this opportunity to reach out to everybody, if you are a member and you sponsor resources, have a look at at them if they are all really needed, if you still have contact to your end users, the sponsorship agreement is still up to date and let us know if something has changed. And also, spread this information with your peers and your country that might not be so familiar with all the parts of our registry with the new charging scheme and so on.
But going back to the multihoming requirement, is it still relevant? I mean, one reason that it was introduced a long time ago was to control how many ASNs were being handed out, because at the time of the 16‑bit ASN, there were naturally not so many. 32‑bit ASNs, there are much more.
Several providers, Cloud providers, they offer services bring your own IPs and also bring your own ASN. But usually this is not something we multihome because you will be pinging your resources and this provider will basically take care of them.
And also, good to know that this multihoming requirement at this moment also exists in our region, and in AFRINIC, and AFRINIC actually has a policy proposal that is stuck, due to the reasons that Angela mentioned before, but only our region currently has the multihoming requirement, and it still stands there.
So that's the end of this shorter presentation. I am happy to hear comments and questions. It looks like we have got loads of comments and questions. Gert, first?
AUDIENCE SPEAKER: Gert Döring: Thanks for the update. It's interesting to see the different distribution of not visible multihoming and single home for these two classes of ASNs. It does make me wonder about the non‑personal ASNs, why so many of them are not visible as being multihomed. On the other hand, there is good technical reasons why you wouldn't just see the second path. So if somebody peers privately, they are multihomed. But it's not like they are cheating, it might be a thing of visibility.
I did read the policy text just now. It says "must be multihomed" and it also says "Must have a unique routing policy." Which is in effect saying the same thing, because if you are single‑homed, you do not have a unique routing policy because then you have the policy of the network you are attached to. Or you could have a unique routing policy for just your network without even having your own ASN. So, not exactly sure technically how to evaluate that at all.
I know why the text is there, because even if there is 32‑bit numbers galor, they are not free. They cause work for you, they cause costs for us, people complain that the NCC is too expensive. So having some sort of mechanism that makes people think twice before just clicking themselves €20 new ASNs is useful.
Now that we actually have the charging back, which I always lobbied for because I think it's a useful way to once a year you think do you really want to keep this? If yes €50 is good, if not €50 is a good incentive is to just return it and be rid of it. If we manage to keep that incentive, we can be more loose on the policy side, and that's always a tricky thing here.
AUDIENCE SPEAKER: I just have a question what is done with the return ASNs? So with numbers, and I would like to have an answer for ‑‑ so are they just recycled or are they just well not used and then the next one? I would like an answer for 32‑bit and for 63 bit.
MARCO SCHMIDT: So, indeed they go into our counting pool, so they are being recycled after six months they go into the available pool. Currently we don't really make a distinction any more between 16‑bit and 32‑bit ASNs. So currently what we hand out is because we start from the largest one, so we hand out 32 bits.
AUDIENCE SPEAKER: Thank you.
AUDIENCE SPEAKER: Tobias: The first thing is you can actually have a unique routing policy for an ASN even though you are technically single‑homed if you are behind that ASN multiple locations and they allow you to adjust how your routes propagate via, for example, a community which might deviate from how that AS distributes its own routes. So unique routing policy and multihome might not actually be the same. Then I do have one AS, AS215‑250 which most likely counts as single‑homed but is present on a lot of IXPs. And the question then would be: Is that single‑homed? Is it multihomed? Basically I get a full table with an AS from peerings because it's everywhere. But if we say like well you have to be multihomed, it's not really, really, really. So I think there is a lot we have to consider. I think pressing more in the unique routing policy might make sense, but then we end up with a policy that is really hard to check because I mean there is people like doing research and figures out how people route. And I doubt that RIRs have time for doing a full scale study to figure out what somebody is planning to do in the future with their routing policy. Requiring glass balls for AIs might help. There is of course bring your own IP. I am a big fan that have because it gives autonomy to users. We are facing a centralising Internet. So I kind of do like everything which gives people the opportunity to relatively easily pack their bags and leave.
MARCO SCHMIDT: Thanks. Also just quickly to respond. Indeed these charts that I showed, I did not want to say that let's say half of them are in conflict with the policy. We need to look at them, we would need to contact them, are you really multihomed? Which is of course lots of work, and seeing it from that perspective, yeah... that's a concern.
AUDIENCE SPEAKER: Hello. You see those whole bunch of unannounced ASNs. Well, other than some very technical reasons, there is one very specific reason that everybody should know about, and I think ‑‑ and well actually I'm not sure whether you take for that reason is route servers. You never see a route server ASN, and even when we ask for a route server ASN, it looks like the process is different, because you cannot say I am multihomed to that and that ASN. Well we could do, but it sounds bad, and we enter to another process. Do you take those ASNs as such as route servers? In which case you could put them as a separate case and we would see how much are not visible because the route servers how much are not visible because some other reasons.
MARCO SCHMIDT: Absolutely. And indeed this is a very simple view, there are different reasons why something is not visible. Some are just freshly assigned and not deployed yet. Some have been forgotten, and some others are cases, the one that you mention indeed.
ED SHRYANE: I have one comment online from Rinse Kloek, speaking for themselves. "Seeing the stats about single multihomed, the additional fee and the other arguments Marco mentioned, I think we can remove the multihoming requirement."
AUDIENCE SPEAKER: Dominic: So, keep in mind that many ASNs are used also for businesses, personal ASNs, and many people just don't use their business ASN, don't register as a business, but it's a natural person. Keep in mind many ASNs are used for example for like some unannounced applications, for MPLS, it was probably mentioned before. Keep in mind that looking at the whole scale it's not a big number of ASNs all together, so thinking about even those announcements, it's looking at the general scale of how many ASNs we have. We're not really facing any problems of ASN exhaustion here.
MARCO SCHMIDT: And I totally agree. Just if we read the policy to the letter. Then we would have to follow up, but there are many things to keep in mind for good use of ASNs, as you said.
LEO VEGODA: Thank you very much, Marco. Thank you everyone who has provided input. Really useful food for thought. We do have one more thing. Just before we let everyone go for coffee, if you could put the agenda slides up on the screen. There is one ‑‑ we can't have the agenda slides.
Okay, so, if you go ‑‑ this is the slide. Alex and I discussed this, and we got input from Mirjam and Niall as the RIPE Chair and the RIPE Vice‑Chair. We do think there is still a need for a third co‑chair of this Working Group. And this is your six month notice that we would like to have the Working Group select an additional co‑chair at RIPE 90 in Lisbon. So, we're not doing a selection process today. We're not, you know, pushing anything through too fast. We want people to go away and have a think about what they want from this Working Group, and whether they might be the right fit as a co‑chair to work with Alex and me.
To help you think that through, there is a job description for RIPE Working Group co‑chairs, it's RIPE‑692. There is a training course in the RIPE NCC academy, and it's pretty good, so if you are interested, please go and take a look at that training course, and of course you are welcome to speak to Alex and me, Mirjam and Niall as the RIPE Chair and Vice‑Chair, and former co‑chairs of this Working Group, some in the room, and if you want to approach someone from the RIPE NCC, to go and get their perspective on it as well, the people from the RIPE NCC would also be willing to have a chat with you. So, in six months time, we will ask the Working Group to select a new co‑chair. But, over the next few weeks and months, please have a think about whether you would be a good fit and would be willing to work alongside Alex and me.
And that takes us up to our coffee break. But we will be back around 30 minutes from now, and we do have a jam packed second session. So, do please come back and there is a lot to talk about. Thank you.
(Applause)
(Coffee break)
