RIPE 87
Address Policy session
29 November 2023
9 a.m.
ERIK BAIS: Good morning. Everyone. I see some sleepy faces from yesterday's social.
Good morning to Address Policy Working Group. We're going to kick off the session.
So this is a hybrid meeting, there are going to be people in the room. We have people in the audience, everything is going to be recorded, and if there are any questions in the room, you can just go to the mic, we have on ‑‑ online we have the chat being monitored by Leo, and we have the scribe.
So, I want to point out the Code of Conduct. I want to stress this again.
We have the Code of Conduct and we have had some incidents on the mailing lists in the last half year where we, as Chairs, had to step in. For the majority of that, we didn't do that online on the list, but we did have some off list discussions, and I would like to stress this again: Please refrain from personal attacks or suggesting alternative motives and things like that. Please keep this ‑‑ all the policy discussions professional, because other people are reading the mailing lists as well, we want to have a welcoming environment for proper discussion. So, I cannot stress this enough. We, as Chairs, have had some serious time spent on this, and if this is not improving, we do need to act upon this by blocking people if needed, to keep the complete discussion relevant to the policy discussions that we have. And I prefer not to do that.
So, everybody read the minutes from the last meeting. And we have had no comments. Any questions on that? Otherwise, the minutes are going to be final.
Anything missing on the agenda? We did change things a bit last time. So, we have two slides, or two slots. We have moved it a bit so that we had the proper discussions in this slot and in the next one. And this is the introduction.
So, no questions on the agenda?
.
So, one of the things that happened in the last period is that we had three Chairs, and then also both Leo and myself, perhaps not so much to James, but James got offered a position at the NCC. So, all of a sudden we had two Chairs and, as you have seen in the e‑mail I sent out in September and forwarded yesterday again, we ‑‑ you know, two Chairs is for the majority of the work enough to, you know, manage the Working Group. We did see the benefit of having an additional Chair. So, if people are interested in the position, please make yourselves known.
I will also, before the next RIPE meeting, send out an additional call for volunteers. We did find one person already that is willing to assist. Alex: And same as what we did with James Leo, Alex will help out and see on the Working Group Chair mailing list and see what's going to be involved and the actual Chair selection will be done at the next RIPE meeting.
Any questions on this?
Welcome Alex.
AUDIENCE SPEAKER: Middleware Jan Kuhne. As you saw there were some concerns on the list about the process. I just wanted to stress I think it's really important that we are following our own processes and I am glad you are saying that there will be an open call for new Chairs before the next RIPE meeting, and thanks, Alex, for helping out in the meantime, and then I think it's just really important that we give other people a chance to step up.
ERIK BAIS: In the e‑mail that I have sent out in September, I already asked for volunteers, because knowing that this was coming up. But it was a bit in the message itself. So there will be a more clear e‑mail sent out specifically on that topic.
MIRJAM KUHNE: Very good. Thank you.
AUDIENCE SPEAKER: Randy Bush, I J research and Arrcus. First of all, I really ‑‑ I have known Alex a little while and ‑‑ but I am a vampire, a little new blood would be nice. And other diversity issues. But it's the openness and transparency, your September message was: Well if you insist, contact us. Not, we're running an open call for volunteers through a transparent and open process that is this. And I really appreciate your being a little more open and transparent today. Thank you.
ERIK BAIS: You're welcome. Then, next point on the agenda it the NRO NC, ICANN ASO AC updates. This time by Sander.
SANDER STEFFANN: Good morning. So, I'm giving you a short update on the ASO AC, also known as the NRO NC, that's the body that performance that function. I won't take too much of your time.
So, this is the ICANN body. It's implemented by the NRO Number Council, which, for which there is an election going on at this meeting. So, please vote.
How is it organised? We have usually 15 members, three from each region. Every region, two people get elected by the community and one person gets appointed by the local RIR Board.
Terms are chosen by the RIR, So that's not universal. And we advise the ICANN Board, we oversee the global policy process, if there's a policy that spans all five regions, the policies that go, that deal with what IANA provides to the RIRs. We handle that. We also have the responsibility to appoint two ICANN Board members and appoint somebody to the ICANN NomCom.
Our default meeting schedule is once a month in a Zoom call, and under normal circumstances, well I'll get to that in a bit, we meet face‑to‑face once a year.
So, who are currently on the Council? From AFRINIC we have Saul Stein, but his term ends this year and since AFRINIC currently doesn't have a Board and can't organise any community meetings, they actually don't have a way of appointing new people to the NRO NC. That's why I said usually we should be consisting of 15 members, but at the moment we are slowly shrinking.
The Chair is Herve Clement. He is right over there in the front row. We have Nicole is also here, she is the Vice‑Chair. And as you can see the term limits are not really synced. We have app ongoing election, like I said, I am on that, together with err survey who just got reappointed by the Board.
So what is going on with the global policy? So, there is a global PDP, like how do we form these global policies? There is a list of current global policies as well. There are active global policies but there's no policy currently under discussion, hasn't been for quite a while. At the moment, things are fairly quiet in that regard.
Should there be the need for a global policy? We actually have a facilitator team with people who will assist the community on how to deal with this, what the process is and how to do that. So, if you have any questions or you think we need something, then please talk to us and we'll be happy to help you.
So, our meetings are open to observers. We actually, last year, had two meetings. One at the ICANN in Cancun and one at APNIC in key OTA owe. Because we had a lot of work. One of my next slides will go into that but basically because of changing circumstances, we had to adjust our own procedures to make sure that we, for example, with we could operate with members from one RIR not being there.
Also, the mailing list is Openflow. We have ‑‑ people can see what we are doing, we do everything out in the open, except of course when we are talking about personal things like who to appoint to the ICANN Board. In that case of course, there are some things that we do in private, because there's just personal information that shouldn't be out in the open. But for the rest, like, as much as we can, we try to keep everything open.
So, same thing for monthly teleconference or Zoom conferences: If you are interested in what we do, please join us.
And to make sure that we do all of this correctly, we even have an annual transparency report.
The positions that we currently appointed, Alan Barrett is currently on the ICANN Board in seat number 9. And Christian Kaufmann is in seat number 10.
Now, the way this works, because there's now another election process coming up, Because we cannot ‑‑ there can not be two people from the same region, and Christian Kaufmann is already there, for the next round of selections for the ICANN Board we will not be able to send somebody from the RIPE region. So, this is a restriction that we just have to live with. So we are now starting a new election process in determining who we are going to send to the ICANN Board on behalf of the RIR communities, but this time it will not be somebody from our region.
We also have Ron da Silva who is currently on the NomCom for the Board process. We are certainly in the nominations phase. So feel free to nominate people as long as they are not from the RIPE region. Then we will have a comments phase where people can comment on the nominated people. There will be an interview phase with written and live interviews with the candidates. Then will be a selection phase, which is internal, this is when the people inside our group will select the candidate that we want to send to the Board. And that will be announced in the middle of May, approximately.
So, that's the timeline for the process. At the bottom is the link. Feel free to download the PDF and click it instead of typing it.
So, like I said, we had to review our own procedures. Well, circumstances changed. There were rules about people from the five different regions having to be present at meetings about some voting procedures, what constituted a quorum for the voting, and we were running extremely close to the limit, because only Saul was there. So, for ‑‑ and even to change our own operating procedures, the procedures said we needed a certain number of votes, which was, in this case, 100% of the people needed to vote yes, otherwise we couldn't pass anything. And the moment Saul would drop out, we couldn't even do that. So we had to make sure that our procedures were more in line with the current situation. So, we worked for more than a year on that, we looked at all the other things as well like voting processes, like some things we voted on in one style, some things we voted on in a different style, so a lot of work went into this to make sure that they were simplified, clarified and made compatible with the situation we are in.
Luckily, the whole group did agree, so we get unanimous approval of the changes, and the NRO Executive Council is the one who then has to approve them, and they did so as well at the end of October. So, currently we are operating under our new procedures.
And that was it. There was bit that I forgot to mention. Like I said, we usually have one face‑to‑face meeting a year. We had more because of the procedures this year. We will have more than one next year, because some discussions came up about ICP 2 and the future and where do we want to move from here. I hope many of you watched Randy's presentation on Monday, that contained a lot of food for thought for us. So, there will be another presentation tomorrow by Herve who will talk about where do we want to go in 2024 and what should the future look like? So that bit is not in this presentation. For that please go to Herve tomorrow.
.
Any questions? Comments? Opinions? Tomatoes?
.
(Applause)
ERIK BAIS: Next up is Marco.
MARCO SCHMIDT: Good morning everybody. My name is Marco Schmidt, I am the manager of Registration Services at the RIPE NCC, and at this usual moment of the RIPE meeting would I like to give you some updates, observations that are seen by my department and that we want to bring to your attention and where we are also looking for your input.
These are the topics that I want to talk about. And actually I tried to, this time, a bit of a different approach to put everything into a bit of perspective, does policy still match reality? Because quite often, a policy is written at a certain time and then, well, the world moves on, the industry moves on, and maybe the policy gets a bit out of date. Or, another, what can happen, that a policy was written with a certain intention, with a certain goal, but after a while we see the goal is not actually really achieved. The policy doesn't work as intended.
First off, I plan to give you some updates about IPv4 and IPv6. And as ususal to the to the people that attend this session relevantly in the last couple of RIPE meeting, I give you an update about how the IPv4 waiting list is developing.
And you'll see it reached kind of its peak at the beginning of this year. Then there was a first drop that was related we handed out a bigger amount of address space that came out of quarantine and a bit later there was a slow decrease where there was a period we didn't allow new entrants
To the waiting list to Board decision. And since then it's slowly growing again.
And we are at about 1100 people, or organisations waiting for the IPv4 allocation.
And at the same time, we do hand out address space. You'll see it's constantly growing, we have these two big jumping that correlate with the list of the waiting list people. But also, on a regular basis, in a couple of days we hand out one or two IPv4 allocations once they pass the six months holding period that we do have we deregister the space.
But still the demand cannot satisfy ‑‑ well the demand is higher than what we can supply, so the orange line shows that it's still the waiting time to get address space is growing and growing, and currently the number ‑‑ or the person or the organisation first in line is waiting already since August last year to get the IPv4 block.
But overall, we handed out around 17,000 allocations since the waiting list became really active and people had to wait. And it's also interesting to know that around half of it went to multiple LIRs, and I don't want to go too much in detail at this moment but I want to bring your attention to a very interesting RIPE article that was published by my colleague Antony, it was a co‑elaboration between community engagement and registry services, or the registry team, where we looked at it actually, who got the allocations, how many were new‑comers, how many were multiple LIRs, how many never used it and transferred it away? So the link is in my slides f you download them or go to RIPE Labs you can find that article and it's very interesting.
Looking forward. We have currently in our pool around 350 allocations. The number is higher than what I showed you during the last RIPE meeting, which is due to the fact that right now we hold some address space there that was deregistered due to non‑payment of members, and there will be a significant amount being released next year in January. So you will also see that most of the space is coming from allocations currently.
And still, after that release, I don't expect so much coming out, a bit now and then, so if you happen to join now the waiting list you probably have to wait for 18 to 24 months.
Now, I want to talk about IPv6, and the topic that I reported earlier, IPv4 harvesting, and actually I have a question for you.
What would you think ‑‑ how many allocations the largest member collected so far? Any guess here? More than 100? Okay. 50? Thousands? Okay.
Well, I will ‑‑ it's somewhere there. So I kind of visualise. So if this is a /29, this little green stripe. It's actually 250 allocations that one member accumulated. So this is more than a /21, almost a /21. And to put this in perspective, this is like under the current IPv6 policy, only one time a member justified for a contiguous block of that size. And also that is address space actually we are in Italy, to give every citizen of Italy two /48s, and there is still space left over. And that's one member.
Well, I brought up this to this Working Group a couple of times and usually the reaction was, okay, whatever. It's IPv6, you know, there is enough of it. So why do we care?
.
But actually, I want to bring your attention to something as we all have to be more conscious about our expenses, our budget and so on.
250 allocations. That means the RIPE NCC had to process 250 resource requests and later 250 requests to consolidate or to transfer those resources to that member.
I did look a little bit into the processes time, and IPv6 allocations, they don't take too much but still we have to do certain due diligence checks, and then the allocation transfers take a bit longer. So all in all, this 250 allocations, the RIPE NCC had to spend 500 working hours on it, and that means, as around a month has 21, 22 working days, it's like one member of my team would be working three months straight only for this member. Which is, for the members here in the room, it's quite a significant amount of money that was given to this one person, or this organisation.
And it's also good to know that that's not a single case. We have another five members that have more than 100 allocations, so you were in, in a wider sense, close to t overall, 4000 of our allocations are currently held by members that have three or more IPv6 allocations. And 4,000, that's around 20% of all the IPv6 allocations that we handed currently out. And again, I get it, in the whole sense of v6 space, it's a spec. But looking at the working time and at the cost might be worth to think about if it's something that is really desired.
So, the conclusion that I want to bring here is, should maybe clearer guidelines who can request allocations in we had this before. There is the IPv4 policy talking about history. It uses the term LIR, and when the IPv4 policy was written, it equalled more or less a member. The IPv6 policy used to say organisation, and it was aligned with the LIR ‑‑ with the IPv4 policy, and so it says LIR, but that's not a member any more. I don't know, but that might ‑‑ having a better clarification there about qualifies might be useful.
Maybe, also the IPv6 transfers should be reviewed. If does anything need to be changed, because we are the only region who does it and the proposer, the original idea was there shouldn't be many transfers, it's just to help with some transfers of live networks if they don't fall under the merger and acquisition. Of course, on the other hand, maybe larger IPv6 allocations should not be too difficult to get them, because recently, in my team, we got a request of a new starter, a new company. They didn't really have much customers, they didn't really have real network yet but shed some ambitious plans of 5 million customers, but well they couldn't qualify that. And maybe that was a good thing. But it could maybe get a better balance how to deal with IPv6. And this is actually in the second session of this Working Group, we'll talk about the IPv6 policy that maybe can be added to the consideration there.
Now, I want to talk about about AS numbers, there is some policy requirements there and how they are dealt with in reality.
And the first one is an interesting one because there is a clear policy requirement that since 2010 we are supposed to provide AS numbers from an undifferent shaded pool. So there is no differentiation between 16 bit ASNs and 26 bit ASNs. However, in 2009, this Working Group at RIPE 08, my colleague Daniel Karrenberg presented that, back then the industry wasn't really ready for 32‑bit ASNs. It was due to hardware requirements, operational systems was not ready, and also some pool management related into that. So back then, on a verbal agreement here in this Working Group, it was decided to not follow that policy yet, but maybe a review of the policy there should be a policy change done and we kept on making a distinction.
Fast forward to 13 years later, to today, the RIPE NCC is the only RIR that still makes this distinction, because this verbal agreement always ‑‑ was never revoked, and looking at the other RIRs, they do hand out about 1% of the requests, 16‑bit ASNs, and that's not necessarily because they request it, because they all work with undifferent shaded pool but with a regular ASN recycling.
We, on the other hand, we receive around 20% of our requests people tell us they need the 16‑bit ASN, Which I'm not sure if it's really true because in all the other regions, it works pretty well with 32 bits. And also looking a bit deeper into it, most of the 16‑bit ASNs are being transferred once they pass the holding period and actually the whole transfer market is a lot about 16‑bit ASN because there is a certain vanity factor involved.
But still, from the technical point of view, I do believe it's time that the RIPE NCC starts to begin from an undifferent shaded pool. There might be common cases that we can look into it, but basically as there was a verbal agreement 13 years ago, follow the policy, there will be an agreement to follow the policy or start following the policy.
Then there are two more rather clear requirements in the ASN policy, the first one is it should be used within our service region. And the second one, it should be multihomed. However, looking at the reality, a presented on this during the last RIPE meeting, we receive more and more requests from organisations and national persons based outside from our service region, and of course sometimes they use it here, but often they are also used somewhere else in the world and it's quite significant. I mean, it's one fifth. In the Netherlands recently, a party won with just a few percent more and they might create now a new Prime Minster all right.
Looking then at the peering status. It's even more interesting because there is a multihoming requirement. And I looked at all the AS numbers that we handed out before 2023. So it's a bit more than 26,000, and actually only half of them we receive currently multihomeded. Another 30% is routed but has only one peering partner and again 20% are not visible.
And I can tell you actually when we get the requests, all the requests fit the policy. We get the peering partners, two or more, and we also get confirmation that they will be used in our service region but later a significant amount turned out to be different. And it can happen that plans changed but also we have heard already that people tell us in the request what we need to hear to match the policy, not the reality.
Now, of course, we, the RIPE NCC, could spend a significant amount of resources, that we don't have right now by the way. To ensure policy compliance because I mean every rule should be somehow enforced, or else it's not really followed. It's the same with the speed limit on the the street, If there is not occasionally a check by the police, more and more people ignoring the rules and the people that follow rules are being upset.
Or,, maybe, the ASN policy needs a review, if those requirements still are fitting to the current reality.
The multihoming requirements, there are some providers, or more providers that offer bring your own ASN, and multihoming is not possible there.
The location requirement, also is it really still needed? And of course this should be counter balanced that we follow the policy on the ASN pool management.
That's the end of my presentation. I have here one slide with the questions where I really would like to get some feedback from you and I think it's time to open the mics and I'm looking forward to any questions and input.
AUDIENCE SPEAKER: Gert Döring. I have no idea what to do about this 100 and 250 allocation holding registries. I do have very one strong opinion and it should be easy to get an IPv6 allocation, or it must be easy, because this is the pillar of the v6 policy: Do not get in the way of people trying to actually do IPv6.
On whether it's a member or an LIR, that is basically a mess‑up the Board created. So, when policy was made, a member was an LIR. So the distinction that a member could be two LIRs or not or whatever is something that's not very clear in my head either, but that's for other people to fix bus...
.
As far as Address Policy is concerned, the LIR is the body doing address management. And LIR is the body who should get an allocation. And it should be easy.
On the 251s, I don't know, maybe we can bribe somebody who actually has contact there to find out what they are doing. Directly, sending them questions directly might not yield a result, but maybe beer can be brought into play.
AUDIENCE SPEAKER: I'm reading a comment from Elvis Velea from v4 escrow. "How about automating the request/reception/transfer of IPv6 so it does not take an hour of work to evaluate a request or process a transfer of an IPv6 block?"
MARCO SCHMIDT: That's a good point and we always look into automatisation, something that I want to make people conscious, we do have to perform certain due diligence checks for each request, for example that they comply with our sanction regulations, that we receive authorised requests, we have to check signatures, but whatever we can automatize we do and we continue to that. There is still a certain workload required.
ERIK BAIS: We already had some discussions on this, Marco, and I would like to stress this to the Working Group as well. And I think I know where Elvis's question comes from. I also stated this yesterday to you.
The compliance checks and the sanction checks, things like that, are done on the creation of a new LIR becoming a member, correct? So, those checks are already done when the new member becomes active. True?
MARCO SCHMIDT: Yeah.
ERIK BAIS: So, if those checks are done already, is there an option for the NCC to provide a button: "I would like to request my initial v6 prefix"?
MARCO SCHMIDT: We already looked into it and we are working towards that idea. Indeed it also might work for ASN requests if there would not be so many checks, multihoming and so on. So that's why it also was raised here in the package.
ERIK BAIS: We're talking about an LIR and a v6 prefix which does not require multihoming, it's quite easy for v6 to basically, if you have a brand new LIR and get your initial v6 allocation which might actually help a lot of tickets in the process.
MARCO SCHMIDT: No, that's definitely an idea that we also have internally and we are working towards this, because recently we had some sessions how we can improve our focus, or customer focus, satisfaction and that came up also internally, so yes we are working on that one.
AUDIENCE SPEAKER: Silvan from Openfactory here. With regard to this LIR hoarding, 250 PA blocks, I think what can change the situation with also reviewing the policy of the /48 PI blocks, if that would be changed, I believe the sub‑allocation of PA blocks will immediately go down. And I think that's one of the reasons why those blocks are hoarded, or at least if you look into my LIR account you know why I state that.
MARCO SCHMIDT: Okay. Thanks.
AUDIENCE SPEAKER: I have another question or comment from Elvis Velea.
"A question about a maybe unforeseen consequence on my previous policy proposal that was approved. Do you see companies requesting temporary IPv4 /24s for a long amount of time and for projects that are not real? I was wondering whether the policy would require an update saying that if anyone requires a temporary resource for more than six months to have a status check every six months and a clear progress to be published as per policy?"
MARCO SCHMIDT: That is actually a different policy, a bit for everybody in the room, there is a temporary assignment policy that allows assignments of any size up to 12 months, and already this has pretty good checks in place and it can be extended with additional checks. So I think that works at least from the registration perspective, pretty well.
AUDIENCE SPEAKER: Randy Bush. As someone who has gotten temporary assignments, I wish to certify that, in fact, they do send you e‑mail reminding you it's going to expire in a week and da da da da. I think the registration service is pretty diligent about that.
But why I came to the mic was to speak as an old man in the ghost of Christmas past. I remember when 16‑bit ASN seemed infinite and we're now treating IPv6 as if the address space is infinite and there's no fixed number that I have known that we haven't run out of.
MARCO SCHMIDT: Thank you.
AUDIENCE SPEAKER: Alex Le Heux. I have a question about your ASN numbers. You say that 20% of the requests come from organisations outside the RIPE service region. How much of that 20% is 16‑bit AS numbers that are requested? Are they just ‑‑ is it just the whole world shopping for 16‑bit AS numbers over here?
MARCO SCHMIDT: No, I have to say ‑‑ I mentioned 20% of the requests coming from ‑‑ of the 16‑bit, but there is no difference between inside and outside the region. So the requests from outside the region is the same percentage asking for a regular 32‑bit and 16‑bit. So there is not a trend. But yeah...
AUDIENCE SPEAKER: I have a question from vessel San Kyle and I hope I have pronounced that right, I apologise if I haven't, from Prefix Broker Beve a "is hoarding of IPv6 prefixes still taking place at the same rate as one to two years ago or has this slowed down or stopped at the same rate as new LIRs are being created or requested?"
MARCO SCHMIDT: It hasn't slowed down, even from my perception it keen keeps on growing. So it's definitely not slowing down, at least the same level.
AUDIENCE SPEAKER: Do you have on the other region ASN registrations any indication whether this is natural persons or organisations?
MARCO SCHMIDT: As a matter of fact, indeed, in some of the other regions, natural persons cannot receive resources. That's why they come to us indeed. And we are processing them. And one point that I tried to make, that then they have to tell us that that they are going to use it in our region and we sometimes wonder this person from Indonesia, is he really using it here?
AUDIENCE SPEAKER: But do you have numbers on that, of that 20%?
MARCO SCHMIDT: I can get them, yes. I can get them.
AUDIENCE SPEAKER: Vince speaking from Delta Fibre. I want to give some feedback on the second point, just the IPv6 policy need a review especially regarding the allocation side. I think it needs review because it's almost impossible to get a larger block than a /29. I had a case that I requested a /26, I guess, for new IPv6 deployment I want to give customers a /48. I made a document with ten pages. I pays designs. We had a very good network design and I want to have immediately the right space to grow for now the next four years. So we were planning to have 2 million users. We currently have a half a million users, and it was a very good base design, but it was rejected. And I think the difference, if you start an LIR just as simple company, you get a /29 but if you have a company with investments of more than one billion euros, I couldn't get a larger block so that definitely needs to be changed. If you have a good plan and you have good designs and you can justify your needs, I think it would be nice, it would be easier to get a larger block.
MARCO SCHMIDT: Absolutely. I think there will be in the second session, a long part, and I really suggest that the Working Group talks about that one.
Okay. Then, I also, I I didn't hear any objections about RIPE NCC start to implementing an undifferentiated pool for 32‑bit ASN. We will be looking into that. Other than that, thank you very much for the input and thank you.
(Applause)
ANGELA DALL'ARA: Thank you. Good morning everybody. This is the moment for the traditional policy update. I am Angela Dall'Ara, Policy Officer at the RIPE NCC, and I am here to tell you what happened in the policy development in our region and in other regions, and you heard already about other policy topics on the table since RIPE 86.
So, let's get into it.
But, first, if you are new to the PDP and you are not really familiar with the procedure, you can find all the processes described in this document, the RIPE‑781, and as Erik said before, remember that when you take part, you have to respect the Code of Conduct when you communicate with each other.
Then, to take part is very easy. Just subscribe to the Working Group mailing list of your interest, follow the discussions, and participate. You can also be, in the beginning, a bit shy, and just follow the whole discussion, check the archives, and then be more informed and start discussing.
So, this year was an intense year, let's say, much more intense than the the previous ones. We had three policy proposals that were accepted. The first two are already implemented. They were discussed in this Working Group. One is the reduction of the IXP IPv4 assignment default size from /24 to a /26. And modified the IPv4 address allocation and assignment policies and now the new document is RIPE‑804. I have the new documents here so you can update your records if you have references to the policies in your documentation.
And the second one is the minimum size for IPv4 temporary assignments. This was referring to that before. This new policy guarantees the assignment of a /24, a routable size for temporary assignment, and also allows requests for larger assignments for research purposes to be justified by routing needs. So these are two changes and there is a specific policy for this and the new document is RIPE‑801.
Then we have the voluntary transfer lock. And this proposal was discussed in the RIPE NCC Services Working Group. It has been accepted, and is currently under implementation.
This new policy will replace the RIPE NCC temporary Board resolution that is going to be valid until the end of the year, so we really hope to be ready with implementation before then. And we'll allow the resource holders to specify, to inform us, about which resources they want to block for transfer. And also, there will be the choice to block them for six, 12 or 24 months.
This new policy as a document by itself is RIPE‑806, and also there is an amendment to the RIPE resource transfer policies and the new document is RIPE‑807.
So this is the news for our already under implementation or already implemented in the last couple of months.
Then, we have one policy proposal that is active now in the PDP. It is in the review phase. It is proposing to add the status that is already an option for IPv6 aggregated by LIR to be used for IPv4 PA assignments. The main difference is going to be explained later also by the proposer, who is going to present it later. But it's going to be that the assignment size for this status, for IPv4, is going to be optional instead of mandatory. But I will let the proposer explain this much more in detail later.
What I want to stress is that this proposal is in the review phase. The review phase is in the PDP. The phase that is the basis for the Working Group Chairs to determine if there is rough consensus. So this means that even if you expressed your opinion during the discussion phase, you have to restate it to be taken in consideration.
So, take part in the discussion and contribute to decide if this policy has to be accepted or not. It's going to be under discussion until the 20th December this year. So, plenty of time.
Then other policy topics: You heard that there is going to be a discussion about a review of the IPv6 policies. If you want to catch up with the previous conversations that there were about this topic, there were two interim sessions organised by the Working Group Chairs. There are the minutes online, so, if you want to catch up, this is the link to see what was discussed there.
Then, in parallel to this Working Group, later there is going to be the Anti‑Abuse Working Group session. I know that they are going to discuss the abuse e‑mail address verification. We have a specific policy for this, so I don't know if this is going to bring any news for us in how to ‑‑ how the RIPE NCC must implement this verification. Let's see later.
So, this was for our region. Let's see what happened lately.
What was implemented since RIPE 86. In APNIC, they have a new document that is collecting all the definitions that are used in all the policies, the terms, the technical terms and so on.
The historical resources management is about what we call legacy resource in our region. And I announced it already in the other meeting, but anyway, it's ‑‑ in APNIC, all the legacy resource holders were supposed to become member or non‑member of APNIC so, to have a contractual relationship with the RIR, and to claim their resources in the sense saying that they were going to use them, and if the resources are not being claimed, that the holders are not a member, they lose the Whois services, so they are not going to be mentioned in the Whois of APNIC. And if they are not claimed after 12 months, they are going to be put for redistribution as a normal resources.
Then there is the ROA for private, reserve and unallocated origin ASN. So it is what is called AS 0 for a more technical. And the registration of AS‑SET is now required to be using the hierarchical AS‑SET. This was also implemented in our region via NYI‑19, I think, in the Database Working Group. So let's say that it's not possible any more to register non‑hierarchical AS‑SETS.
And then in LACNIC, they have this policy that is actually, was already probably in place, but it's stating that the recovered resources that were coming from a reserved space are going to go back into that reserved pace. So this has been clarified.
In ARIN, I divided this into parts because the second part is mostly an update of the manual regarding the language, clarification and so on. So I won't go deep there, because I don't remember all the sections by heart. Sorry.
But what is more relevant is that the autonomous system origination filter that was in place to declare, let's say, the origin of certain announcement as being deprecated, that part is already, in the manual of the policy. But let's say the deletion of this field from the database is going to come later. So the system is going to be updated later. I think the time is 2025.
Then they made it easier to receive the first 32‑bit ASN for newcomers. So, it is sort of a pro forma now that this request, there are not so many requirements to be satisfied. And also, the documentation for transfers is simple because you do not have to add this additional attestation from an officer of the company that is confirming the transfer.
What is awaiting implementation in AFRINIC is this AS 0, again the RPKI for unallocated and unassigned address space, and they are working on the implementation and I expect they are going to be ready pretty soon.
And in LACNIC, they should implement in the first part of 2024, some modification of the PDP that is affecting the status, the name of the status of the policy, for example, is not going to be called abandoned any more but withdrawn because in the original language, abandoned has a different meaning than withdrawn. This is requesting also some updates in this system, and they are going to be ready in 2024.
AFRINIC, as, you know, does not have a Board yet so the ratification of this policy that were already accepted is probably ‑‑ will probably be resumed at the moment which is going to be possible with the Board. They are already waiting for certification for a long time and let's hope that ‑‑ let's see how it's going to be resumed, this ratification.
And in APNIC, there is this policy that is allowing associate members, so these are members that have no resources yet but they can anyway vote in the GM of APNIC and they should be allowed now to have an IPv6 PI without having to provide ‑‑ without having too many obstacles for the request. So to favour the implementation of IPv6 for these members.
Then under discussion in ARIN: Again the second part is more related to language and updates of the manual to make it more clear and readable.
While the first policy is proposing to have a reduction of the IPv4 allocation, it is going to be very similar to what we have in our region, because they are going to be from a maximum size of /22 to a /24, and this /24 should be available only for requesters that never receive the directly space from ARIN. And it is under discussion.
The modern identification of registration requirement is allowing a longer time to register assignments, because at the moment they should ‑‑ everybody should register assignments within seven days, and they want to prolong it to two weeks. Let's see how it's going.
And we have this reduction of the initial IPv4 allocation for IXPs, similar to what we had accepted in our region. They want to reduce it to/26. I must say that there is less support probably in that community, and it is interesting how different communities are discussing the same subject in different ways.
And then this is retire close start which is something that's not in the practice, But in ARIN, let's say that newcomers were supposed to receive space. After they had already some space from their provider. But this already is not in the practice any more because of course you know that providers have difficulties to release public space to their customers, so this slow start should be removed from the manual.
And you see in ARIN, the draft policies are going to recommend the draft policies when we are a bit further in the PDP, so there are a couple that are already a bit further.
And in LACNIC, we have three policies under discussion. Temporary transfers in that region are not allowed yet. So this is a proposal to introduce them.
And I have heard from Jordi that is also this proposal to APNIC but has not been published yet because they wait until that line for the submission time has been submitted but not published yet.
And they have a special exception for global critical infrastructure providers. This is actually for route servers to have an exception and to have the possibility to receive IPv4 space as an exception to the current policy.
And then delete ROAs for recovered resources is something that is already happening. So when they recover resources, they delete the ROAs, but they want to insert it into the policy manual.
And as usual, I leave with you all the links for all the other RIRs. If you want to follow the discussions and get updated with the situation of the policy proposals.
And I'm ready for questions, if there are any.
ERIK BAIS: Any questions? No. Thank you.
(Applause)
LEO VEGODA: Thank you very much. So, in the last half hour or so before the coffee break, we wanted to have a discussion about the purpose of an IPv4 assignment registration in 2024, which we're about to start. So, this is coming before the discussion of the policy proposal in the next session, and hopefully this will help people focus on what it is the community needs to achieve for the community and for more than the community. So, in 1996, we have this definition "track the use of address space, facilitate operational contacts, and facilitate studies of address allocation."
.
And I looked at the database terms and conditions, and Article 3, from the current terms and conditions, which I understand are over ten years old, essentially said the same things but added in two other purposes: Law enforcement and legal notifications. And I think that was in the context of disputes over address space.
Does this capture everything? Is there stuff that should be removed? Is there stuff that should be added in? Do we need to change the wording or the focus? Because if we have things in our definitions of purpose in the database terms and conditions, we need to make sure that they actually remain valid. This is a relatively old document. The world has changed in the last decade or so. So, I'm asking a very broad question, which is essentially: When we look at assignment registration from a PA allocation, what do you need? How are you going to use it? And that is going to, hopefully, help us when we come to the discussion of the policy proposal after the coffee break.
So, this is my slide which is essentially saying we would love to have people offer an opinion, ask a question of each other, whatever it is that makes sense.
ERIK BAIS: I have one raised hand on Meetecho. A Manuel Kessler ‑‑
AUDIENCE SPEAKER: Thank you very much. Well... (inaudible) I work in Europol, and I would like to take this ‑‑ (inaudible) to discuss this matter. Of use today I would like to remind that of course the IPv4 is still a great need for us... (inaudible). ...... IP address is... (inaudible).
ERIK BAIS: The audio is very noisy. Can you switch off the video perhaps?
AUDIENCE SPEAKER: Can you hear me better? So, just to address you here of what... we need an identification of IPv4... (inaudible) for other colleagues was unavailable... (inaudible) ‑‑ all kind of crimes of course, online fraud, cyber attacks, also the fight against all kinds of threats, terrorist threats. So while we have some concern, each time we lose some access to this kind of information very, very clearly.
Unfortunately, IPv6 will not be implemented in a very large extent very soon. We have still to come ‑‑ (sound gone).
ERIK BAIS: We have lost him. Okay. All right. Manuel, if you hear this, I didn't hear a specific question. If you can put a question in the Q&A I will come back to you later.
AUDIENCE SPEAKER: Gert Döring, having been around for a long time.
Thanks for taking this up, because the discussions on the mailing list actually made clear that we have no really, really good understanding what the Admin C and Tech C are good for the in these inetnum days. We knew what they were good for in 1996, but administrative things have changed, technical things have changed and while in 1996 the holder of a network was usually an entity operating a network with addresses and technical people and administrative people, nowadays if one of our customers has a /29, and that goes to a rack in our computer centre, we operate their service for them. So who is the admin contact, who the tech contact? So these questions are not as easy and clear‑cut as they used to be. And I don't have answers so I'm very happy to see that this is being discussed now.
LEO VEGODA: Thank you, yes, we recognise that there is a significant change over the last 20‑odd years, and so we wanted to make sure that we created an opportunity for people to explain how their world has changed.
AUDIENCE SPEAKER: Peter Koch, retired member of the retired Database Task Force latest edition or somehow. First, I'd like to suggest that people go back and road the report of the task force because there is probably something to find in terms of what the purpose is and the use and what you have on the slides, and I agree with Gert first and foremost, that bringing this up and having a broad discussion might be helpful.
What you have on the slides I would like to suggest that this might be confusing two different types of purpose. The purpose mentioned in the T&Cs and the T&Cs come from the NCC, not necessarily from the community. So that's more like the acceptable use of that what is in the database. Whereas, the purpose that is discussed in RIPE‑136 and other documents and it's also very, in much detail laid out in the task force report, is what suggests and what informs what should be in the database, and there might be things in the database that can be used for other things that they were designed for, which are then declared acceptable use by the T&Cs, but there is a subtle distinction to be made.
And there is also another aspect is that the database has actually two functions that were piggy‑backed on to each other. We learned yesterday, or every RIPE meeting actually, that the RIPE NCC was founded as a secretariat for the community. So the RIPE Database actually predates the RIR nature, and it was set‑up as a cooperation database. So that informed the different set of information. And now we have this RIR stuff, the registry on top of this, and it's intertwined. And again I refer to the part of the Database Task Force because that's more detail to find there. Again, that suggests maybe different, hopefully not, inconsistent but different sets of data that are entangled in there and that fulfil different requirements. So it's a bit more complicated than it might seem. And as Gert said, things change over time, especially in terms of what is necessary for proper registry to keep, and this might be incongruent by now with what is necessary to foster the cooperation of operators. The multiple dimensions, and as a famous colleague likes to say, complicated issue needs for research. Thank you.
LEO VEGODA: Thank you. Maybe I could ask another question of people in this room or online which is:
If you have a PA allocation and you make an assignment to a customer, what proportion of those customers would be able to respond usefully to a contact from someone at another network?
AUDIENCE SPEAKER: (Inaudible).
LEO VEGODA: If you want to make that comment, please come to the microphone.
AUDIENCE SPEAKER: Doesn't that ‑‑ Harry Cross here. Doesn't that depend on what of network you are talking to though? If you are talking to a residential network, they are probably not going to know what's going on if you speak to somebody in a house f you recount to a big corporate, they'll probably know what's going on or they will have somebody that knows what's going on.
LEO VEGODA: Of course it depends, but that's why I asked about proportions rather than an absolute.
AUDIENCE SPEAKER: True. And I think it's quite a hard answer.
AUDIENCE SPEAKER: I cannot give you a specific number here. But for the way we run our network in 2003, it's maybe like 10, 20% of the customers would actually know how to deal with a random e‑mail from a random person out there saying your server is doing random things.
Most of the customers would then just come to us and say, I have received this funny e‑mail from a guy I don't know anything about. Is this serious? Is this a spam trap? Can you check whether my server is doing something weird? And then we go and look at the network.
So, for us specifically, the largest ‑‑ the biggest block of customers would know nothing. And would then come to us to help with the technical question that might be in the mail. So this is why we actually put ourselves as Tech C in most registration.
Going back to your question, so for the Tech C, I think somebody who is able to do something about technical issues with that network would be a good description of the role, not necessarily at the customer side but the person who is doing the tech work. I am more confused about the Admin C to be honest, because I don't know when and why people would actually go and contact the Admin C, so this when and why, if I knew that, I knew what a good contact in the Admin C would be.
So the policy is very clear, it says something at the customer side. But who is going to use the Admin C and what's going to be in that e‑mail, and that's a question that needs a good consensus on.
ERIK BAIS: Yeah, for us as an ISP, with my ISP hat on, once the v4 run‑out was the ‑‑ the initial run‑out was done ‑‑ so back in the past there were the requirements to obtain new IP space, you needed to have sufficient assignments within the database to actually be eligible for additional space. That is not the case any more.
The contacts in the database registered for the assignments in our case is most likely going to be us, whether it's for fiber to the home, whether it's for business fiber or co‑location services, because we actually know who the contact is at the customer side. And we actually follow up on the abuse. And, as a resource holder, I think that for the LIRs, we are the contact that they should contact. In very, very, very, very few situations, we get the request: Can you delegate abuse directly to us? Most of the time larger assignments or customers that we know that actually have their stuff properly organised. But I would say that is less than 2% on all the customer space that we have.
So, for ‑‑ and I think we're not unique in that. I think that for the LIRs to focus on that 2%, those are, for the majority that want to do good, because they know what they are doing and they see the value in it, and I think there, where the must and the should ‑‑ so it still should be available as an option, but focusing on that, getting the other 89%, or 98%, in the database or expecting that the other information there should be at the same level, I think that is an illusion. So for them, I would say focus on the allocation, because that's the information that the RIPE NCC is managing and they know the resource holders.
And so for the law informers, legal notification, stuff like that. This is the entrance into who is actually using this space. Because if we're looking for the bad guys, trust me, they will not put their mobile phones in the RIPE Database.
LEO VEGODA: Yeah, of course. So I think there is one other thing that we should do, which is to go and look at this, not from the perspective of the people who are putting the data into the database, or who the data is about, but the people who are using the data. So, we did have someone from Europol who had some technical problems communicating but said hey, this is useful data to us. So, I think we should think about what is is it that the person making contact actually wants to achieve. And look at it from that perspective. So we're not just looking at it from the perspective of how much effort do I need to put in to maintaining this data, what is the data that I should be providing, but also when contact is made, what does that person who is making contact, or trying to make contact, actually need to get out of it so that the contact information we're providing is of some utility.
Now, if the gentleman from Europol is able to provide a written comment, Erik can definitely read it out, otherwise be I'd be very grateful if they could send their comment to the Address Policy Working Group mailing list, because that would be very helpful for the whole of the Working Group, but I have asked the question. We have someone at a microphone.
AUDIENCE SPEAKER: Raymond Jetten, speaking as an operator for Eliza in Finland. We have different customers who have different knowledge of technique. Most of them have outsourced their technical issues to companies, some of them for example in India, and if a law enforcement officer would contact that company in India, they would say you are not a person to discuss this with us because you are not the company. We cannot give you the information.
So that would not be a real good solution, even if that one would have been in the Admin C or in the Tech C. So what we have done is we have used the Admin and Tech C for ourselves and then we can, as an operator who provided the connection, the equipment and all the other technical stuff to the company, handle to get in contact with the correct person. It makes it much quicker for anyone to reach the person, and we can be reached night and day.
So, thanks.
LEO VEGODA: Thank you very much. Does anyone else want to speak on this topic?
We have something like seven or eight minutes until the break. Gert?
GERT DÖRING: What I clearly heard is that there is a difference between levels here. So that the allocation level, the contacts that we currently have seem to make sense the way we have them, like the Admin C is our CEO who has the written contract with the NCC and the Tech C is our team which does tech things.
On the next level the actual assignments, there is lots of questions.
LEO VEGODA: Okay. It looks like we have reached a natural conclusion. We probably don't have enough time to bring ‑‑ yes, we don't have enough time to bring the next agenda item forward into this session. But what I would like to encourage people to do is to think carefully on this and send their thoughts about how they would like to use contact information for assignments in the RIPE Database to the mailing list, and also, how much effort is involved in maintaining assignments for IPv4 in the database, because we obviously need to strike a useful balance between the effort that is put in and the utility that we get out of all of this work. And I think that means we can leave five minutes early for coffee and a little refresher.
We will see you back here in just over half an hour, and thank you very much.
(Coffee break)
