Address Policy session
17 October 2018
At 9 a.m.:
GERT DORING: Good morning, dear Working Group. Thank you. So this is the Address Policy Working Group, as you probably all know. DNS is in the other room and in the second slot we have connect in the other room. But looking at your faces, I assume that you are in the room that you want to be because it's all people I know to be interested in this topic.
As a matter of introduction, I am Gert, I am your chairman, here comes Erik who got stuck in the coffee queue. Your new co‑chair since Sander decided to run away last meeting. I don't even see him in the room so that's a bad sign. Or the party was just too nice yesterday.
This is the agenda for the first slot now, a bit of administrative matters, informative item on 2018‑4 and sort of like the regular update from Marco on what is happening in global policy development land and then the usual update from the NCC registration services by Andrea, has a slightly different twist this time; looking more into what will happen when IPv4 really, really finally runs out and should we do something about it?
And then something that came up in discussions over the last month about the country codes in RIPE DB but Ingrid will go into more details. In the second we will do open policy proposals and open policy hour. What will exactly happen in the open policy hour is not yet known to me because a couple of people approached us and said I might have something I want to speak up on so we will see who comes up but that's the whole point of the open policy hour, come up and present your ideas and then see whether we need to do something formal about it.
So, any conflicts, anything that needs to be changed, anything I forgot? Good. Let's go on.
Minutes. The RIPE NCC produce wonderful minutes from the meeting in Marseilles, they have been sent to the list and as far as I can remember, nobody said this is inaccurate, something needs to be changed. So, anything in the minutes that need to be changed? Then I formally declare the minutes as final. Thanks to the NCC for doing a great job on this.
PDP. We used to have almost all policy proposals here in that Working Group, that has changed a bit recently. This policy proposal 2018‑04 actually affects us but it wasn't discussed here because it's affecting the whole policy development process. It wasn't something really huge, tremendously changing all the way we works; more like actually writing down that the way we do the work is officially sanctioned. What we have done for years is if, at the end of one of the phases in the PDP we just didn't have clear enough consensus, the Chairs just extended the phase to get more discussion going. Formally, this was not written down in the PDP as one possible option, with that policy proposal it is now formally written down. It was discussed on the RIPE discuss list because it affects all the Working Group and the RIPE Chair Hans Petter Holen chaired that discussion because all of RIPE. And that's pretty much it. Consensus has been reached, everybody agreed that yes, this is a useful addition, make it so done. And that is pretty much all I have to say so far. Handing over the microphone to Marco. You all know Marco, he is no longer the policy development officer at the NCC, he is not a policy officer, asked me to change this, welcome Marco, policy officer at the RIPE NCC.
(Applause)
MARCO SCHMIDT: Yes, good morning everyone, also for me and I have to say I am pretty impressed about the turn out of the people here in this room after yesterday's social and I hope I have some interesting updates for you what is going on in the policy land in our region and globally.
Usually I start with brief summary what has developed here since the last RIPE meeting in Marseilles in May, then I give a little bit of outlook what is under discussion in the four other regions and I close with some numbers, how I see the policy, participation, the participation in the development.
But first off, what proposals we have here in our region, we have currently three proposals under discussion and as Gert already said, it has shifted a little bit, only one of these three proposals is actually discussed here in the Address Policy Working Group. All the three proposals are still in the initial discussion phase and the first one, 2018‑O2, the assignment clarification on the IPv6 policy will be presented by the proposal Jordi here today in the second session at 11:00.
Then, we have a proposal that is discussed in the RIPE NCC Services Working Group, it's called the publication of legal address of Internet number resource holders, it has created quite some intense discussion. What is this all about? Currently, the contact information, the postal contact information in the RIPE database decided by the resource holder and there is not always necessary the one where they are legally registered which makes it difficult to identify where a company is based and where, for example, takes some legal action. This proposal wants to introduce that the RIPE NCC publish this legal contact information and recent discussion it might be adapted a little bit, a little bit adjusted to publishing the registration number. If you would like to know more about it today at 4 p.m., RIPE NCC Services Working Group in the big room is the place to be. And before actually in the big room at 2:00 there is the Routing Working Group and there the last proposal on the slide that we discussed RIPE NCC IR database non‑authoritative route object clean‑up, it's quite a mouth. And what what is behind this, we have in the RIPE database for resources handed out by other IRRs and it's a little bit historical remain when in the other regions routing registries. Still, as anybody could until recently create such route objects it could happen that somebody that was actually not a resource holder created this route object and tried to do some hijacking. What this proposal aims actually is if the resource holder requests a resource certification from his IRR and there is a valid ROA, then this will be checked if the route object in the RIPE database, this non‑authoritative route object is matching and if not the proposal is to delete such route objects.
Four proposals has been accepted since the last RIPE meeting, the first one the 2017‑02 is the regular abuse‑c validation. That one was discussed in the Anti‑Abuse Working Group, it reached consensus in June and basically it gave the mandate to the RIPE NCC to annually validate the technical parameters of this abuse mailbox addresses that are mandatory in the RIPE database and the RIPE NCC right now is in the middle of implementation. If you would like to know a little bit more details on this implementation, I invite you to come tomorrow to the Anti‑Abuse Working Group session. There you will get an update by my colleague Angela where we are and what is ‑‑ what will be our next steps.
The next two proposals 2018‑01 and 03 were both discussed in the Address Policy Working Group. The first one, the organisation LAR clarification, basically changed the routing in the IPv6 policy to make clear that an IPv6 allocation is given to an LAR. Similar like it was in the IPv4 policy. Because before it used the term organisation which without really having a definition what an organisation is, and that make it more clear, it's an LAR count, you get an IPv6 allocation per LAR count.
Also 2018‑03, basically it was about clarification. It removed outdated references from the IPv4 policy to RFCs that were obsolete and removed some database values or reference to database values that actually are not existing any more.
And last one Gert just mentioned it, a little change to PDP reached consensus and now will be followed, also now written to the letter.
That was a quick overview from our region. So let's have a look what is going on, what is under discussion in the other four regions and you will see there is quite a lot and I always try to group them a little bit by topic. So the first topic is still IPv4, and there is since quite a while in the AFRINIC region a soft landing proposal. AFRINIC is the region that still has the most IPv4 and why they do have a soft landing policy, it's by some people considered as not strict enough, and the proposal wants to tighten those rules but they also quite some opposition and it was discussed for several AFRINIC meetings without reaching consensus and it will be up for discussion again at the next meeting by the end of November.
A proposal that is not on the table any more is from APNIC, there was some idea to create some kind of waiting list once their final /8 pool has been depleted but and there was some balancing suggested between the two pools that APNIC has, but yeah, it could not reach consensus and it has been withdrawn. And the other three proposals here on the list from ARIN and from LACNIC, they all have just been moved to last call and I will not go much in detail into them, they are all basically about housekeeping, they want to remove requirements in the IPv4 sections of their policies that don't really make sense any more in the light that those RIRs have no IPv4 left. Because there is still some requirance to be multi‑homed or to be renumbering and so on, and yeah, they are now in last call and it's likely that reach consensus soon.
Moving on to IPv6. In three regions, actually the similar, very similar proposal is discussed like the one that you will be discussing in a second session, and clarification on the IPv6 sub‑assignments. It has not reached consensus in any of them, it was out for discussion recently at the LACNIC meeting and also the APNIC meeting, but, yeah, there was still some questions, it was sent back to the author for further development. And in AFRINIC it will be discussed at the next AFRINIC meeting.
ARIN, also has a proposal that now has been moved to last call. It started from the text very similar to the other five regions basically, but then the Advisory Council took a more general approach to basically define that if you temporary give some addresses out of your assignment and it's not considered a subassignment and then that more lightweighted version it has now been moved to last call.
Transfers of Internet resources, still a big topic: In the APNIC meeting there were a couple of proposals, two of them have been recently withdrawn,to allow a temporary transfers, and also to modify recent change to the transfers for resources from their final /8 pool because there were some restrictions implied and the proposer wanted to ‑‑ those partially but there was no consensus in sight so they were withdrawn. A proposal that is still out there in APNIC since quite some ‑‑ quite a while actually, is the no need policy, so that there would be no need evaluation required for transfers, but also it was up for discussion again at the last APNIC meeting and still did not reach consensus.
A proposal that is short before final consensus is actually in ARIN and that one is quite interesting for our region because it will allow the transfer of Inter‑RIR transfer of AS number resources and our our inter‑IRR transfer policies allows transfer from any type of resource as long as a matching policy in the other region and at this stage, we have to possibility to do transfers of AS numbers with the APNIC region and if this proposal will reach final consensus, also ARIN will join that club and not only IPv4 can be exchanged between these three RIRs but also AS numbers. And in LACNIC there is a proposal still under discussion that tries to align the rules for resources received via merger and policy transfer basically to make it a bit more strict if you receive resource via merger, that you cannot not in the next 12 months transfer immediately away or just a small amount actually, 20%, and if the merger was of a legacy resource that this legacy resource would lose that status. But it's still under discussion, it did not reach consensus at the last LACNIC meeting a few weeks ago.
Validation, another topic that I selected because it's getting more and more relevant, all around the world. And AFRINIC, since quite a while, there is a proposal out there that would mandate the AFRINIC organisation to do a quite strict audit on their members to see do they really use the resources, do they use the resources efficiently and if not take resources back but it's quite controversial and the next AFRINIC meeting that one will be on the table again.
Then, you will see now the next three of the next proposals all related to the abuse‑c, and a little bit the RIPE community is responsible for those proposals, I would say, because when we accepted 2017‑02, it was just looking at the technical parameters of an abuse e‑mail contact and there was one person in particular that thought there should be a more strict validation, there should be a manual interaction and also the annual ‑‑ the period of one year is not enough, so in AFRINIC there is a proposal right now out there that would require that a resource holder would need to respond within five working days, maximum, to a validation request and yeah, let's see what the AFRINIC community thinks about it. A similar proposal actually has reached consensus in APNIC, there the time‑lines are a bit less strict, the resource holder has up to a month, about, to respond, but he must respond not in the automated way, it must be manual response. And the validation will happen every six months.
Jumping quickly ARIN. In LACNIC, the similar proposal was discussed, still with the tough time‑lines like in AFRINIC. It did not reach consensus in that status and just yesterday I think a new version was published that is more in line with the time‑lines that I mentioned for APNIC. So every six months a validation and resource holders would have up to one month, two times 15 days to respond.
And last but not least on that page, ARIN also have something that will increase validation. In the ARIN database basically what happened that, if an assignment gets created by an ISP, a point of contact, a POC must be created and provided and often it happened that the ISP just took the contact details of its customer before that customer even knowing he is now published in the database and getting quite surprised if they were contacted by ARIN. So that proposal suggest to actually when there is an assignment made or a reassignment, that ARIN will validate if this point of contact is actually correct and aware about being a point of contact. It's still under discussion and, yeah, let's see how this one goes but it's, at the last ARIN meeting it did not receive enough report and the Advisory Council believes it needs a bit more development.
Then something to the policy development process itself. We have right now in three of the other regions proposals that want to adjust, develop the policy development itself and quite interestingly, all these proposals move toward policy development process like here at the RIPE region because until now, until recently, in AFRINIC and APNIC and LACNIC consensus was defined at the meeting and not like we do it here at the mailing list. And these proposals with a little bit of variation basically, suggest to take more the feedback into account that was given on the mailing list, that it must be considered for the judge of consensus because not everyone is able doing to those meetings and be physically present there, and give their opinion. In LACNIC, 2018‑10 actually has reached consensus and is already implemented and APNIC and AFRINIC it's still under discussion.
I am almost at the end with my global overview, just mentioning two proposals that fall out of this group that I did before. In LACNIC had a and proposal has reached consensus and is already implemented that requires from the LACNIC organisation to publish some geolocation information to their resources that they have handed out and a proposal in LACNIC has been withdrawn that created a bit of unrest at the beginning of the year because it was sent in as a global proposal which means it would eventually hit the other four regions, with the idea to create a global Internet registry. However, it was not really clear to the LACNIC community what problem they tried to solve, how it would work and consequently the proposer with decided to withdraw it so for the moment there is no global policy proposal out there in the IRR system.
And to close, a little bit, I want to give you a bit some numbers, what I see, how is the policy development doing and a successful PDP lives from a good participation. I am looking a little bit at the different mailing list, policy proposals ‑‑ policy discussions are happening, and so far, there are more than 570 posts to all those different proposals in the different mailing lists. For more than 90 participants about 26 countries, and you can see here as darker a country; more people from that country participated, and for Europe itself it's quite nice spreading of participation, sometimes people asking me okay how do you define where you find the person, basically I look a little bit where this person right MoU is based so where his work is, and I always would like a bit more participation from Eastern Europe, the Balkan area and also the Middle East, but it's not so easy, unfortunately and we also have participation from other countries that are not on the list, like the United States, for example.
That brings me to my second last slide, if you want to look up the proposals I mentioned briefly here, if you download my presentation you have the links to the different RIRs, where the proposals are mentioned, and if you have any open questions, you always can find me in the next days, you can send me an e‑mail or follow me on Twitter and if you have any immediate question I am happy to take them now. I see Jordi rushing to the mic.
JORDI PALET MARTINEZ: More than a question, it's a couple of clarifications. You had that in the slide about PDP changes. There was one additional policy in LACNIC that didn't declare that yet consensus because it needs to finish the eight weeks in the list because now it's measuring the consensus in the list and the meeting but I think it's going to get consensus and of course basically it was equivalent to the PDP change had a we did here, okay? You had in the slide but you didn't mention. What happened is that I was the author of the policy proposal to change the PDP and I didn't discover that I was making the same mistake we had here, is that if a policy don't reach consensus, actually the author is forced to send a new version even if there is no change, which is a stupid. So I published that update and well, basically in the meeting the people said yes, and we are just waiting for the decision of after the list, then clarification on the Abuse‑C, I submitted the same proposal in all the regions, except Aideen, basically what happened is that in APNIC, which one hour of difference of my submissions, somebody else submitted a different proposal and basically the main changes were my proposal was more complex and the other one was more lazy in the terms. So we adjusted basically my text with the terms they are proposing and what happened in the discussion in LACNIC is that they said we want the timing that you defined in APNIC. So that's the reason it's coming back to the list basically. I really think in the next, with the next version it's going to reach consensus, we will see what happens in May.
MARCO SCHMIDT: Thanks for the clarification. Thanks. Any other questions? Or comments? No. Then thank you very much.
(Applause)
GERT DORING: So thank you, actually, for bringing us up to speed what is happening. So, this is basically the standard reminder slides, before we enter more interactive discussions, we don't do policies here, we just get feedback and policy development happens on the list. This is all webcast so if you speak to the microphone and, please remember to speak your name and if it's relevant, the affiliation or if you think it should be mentioned. And there is an Jabber channel, so if you are remote, and want to provide feedback please do so.
Now, to the next presentation and hopefully a lively discussion afterwards, Andrea Cima from the RIPE NCC registration services about IPv4 end game.
ANDREA CIMA: Thank you. Thank you, Gert, and Erik. Good morning everyone, head of registration services at the RIPE NCC. And I think it was about five to six months ago that we were in Marseilles, in the Address Policy Working Group session, that I gave you an update about the current status of the IPv4 pool. I raised a few points that needed some discussion, that need your attention on how we should manage the remaining bits and pieces of this pool and Erik asked me to go back, think a little bit about it, come with some ideas, proposals and that's what I will be presenting to you today.
So, this is the status of our remaining IPv4 pool. As you can see, it's steadily declining, the amount available. If we look at the current utilisation we believe we still have IPv4 addresses for about one‑and‑a‑half years, so we expect it to last until around May/June 2020. So we have still about a bit more than 6,000 /22s doing to accommodate new and existing members that justified qualify for receiving one. And so what is the process that we have in place and that we will maintain until the end?
We keep our current process for first‑come/first‑served, the first people coming requesting a /22 will receive a /22 and the allocations are based on the availability of the prefix available. What do I mean by that? I mean everyone has the right for a /22, but only 5,000 LIRs will be able to receive one contiguous /22. And then there will be 1,000 LIRs that will receive a total of a /22 but it will be a combination of /24s and /23s which we have available.
Now, there is a policy which is about one /16 which is set aside for unforeseen circumstances, you as a community have decided to put this on the side, and once we have run out of the pool, the pool is exhausted, we will be able to reuse this /16 for further allocations. So, what does it mean? It means that 1,000 LIRs will receive smaller blocks, /23s, /24s, and then a number of LIRs will receive again a contiguous /22. We would receive some complaints if we were to do that, it's what like, I am first and I get the smaller pieces, someone comes after me and gets full, so what we would like to do is to make some changes to this. So as you can see the policy mentions that there is a /16, how for future use, for potential unforeseen need and if the /16 remains unused until the end it will become part of the pool, it will be distributed and there is a clause in the policy that makes this section magically disappear, Marco will take care of that from the policy and so that the peer addresses can be distributed. Now currently we have a contiguous /16 and what we to do is we re place this with smaller blocks, still totalling a /16. Once the PDP time‑lines do not allow any changes to this policy any more so we are talking about three month before the run out we would replace this contiguous /16 with smaller blocks.
So the next point is the IPv4 dust. As mentioned, last time, we have some smaller blocks that are left. It's not a lot of address space, we are talking at the moment about 6,000 IP addresses but you expect this to increase of course over the years. I can tell you from previous experience that when we hand out those small blocks, people are not happy, and of course, for obvious routing reasons. So what we want to do for the moment is we want to take those out of the pool ‑‑ keep them in the pool I mean but as reserved for future need and later I will explain what we recommend to do with that. Once we have reached the exhaustion of the regular pool we say there is no more v4, all good. Now, we have to take one fact into consideration, and it's that every year we receive back a lot of IPv4 addresses. Currently on average it's about, what is it? Half a million IP addresses a year, which seem a lot, if we look at the global need it's not a lot. But still, it can accommodate 500 organisations receiving a /22 so how are we going to deal with these addresses? Now, what we want to to is keep it as simple as possible after the exhaustion so we want to change as little things as possible. So our idea would be to just keep things as they are, continue allocating according to current policy and have a waiting list, meaning organisations that are member or that have not yet received the /22 and they have been a member for a while, even if there is no /22s available they can just still send in their request. We put them on the waiting list and when there is one available we give it to them according to current policy, nothing changes there.
We would also continue with the quarantine periods that we have now in place, which are six months and I can tell you that this very much needed because some of those that was we get back are tainted in a way that the six months are really much needed for the quarantine period.
So, it was mentioned as well, guys come up with some recommendations or with some ideas, we did that as well. And we have a few faults thoughts that we wanted to share with you so you can decide what you want to do with this. The first two points are related to the IXP pools, at the moment we have a /16 set aside for IXPs. If we look at the current utilisation we believe this pool may last another four years more or less and our question is, is this pool big enough? Is it large enough, in your opinion? We have a /16, half of it is used, is the remaining /17 large enough to accommodate the needs for IXPs? And I want to remind that these ‑‑ this pool is for the peering LAN, it's intended for the peering LAN of the IXPs.
The second point ‑‑ so the first one is a question. The second point is an idea that we think could be valuable, is still related to the IXP pool: If what if we take all those small blocks we mentioned before,/25 and 26s, why don't we add those to the IPv6 pool? The routability issue should theoretically be less of a problem because it's for the peering LAN so maybe IXPs could make a use of those smaller blocks and because IXPs come in all shapes and sizes, so you have smaller bigger and some could do with smaller blocks as well. This would, however, require a small change in policy because in the recycling section of RIPE 708 there is no mention ‑‑ there should be a mention that blocks smaller than /24 should be added to the IXP pool. Furthermore, being able to issue those smaller box would also require small policy change because at the moment an IXP will receive one number resource between a /24 and a /22 so this would also need a small change to be able to allow to assign smaller blocks.
The next point, yeah, I didn't know to bring this up because I you thought I am going to get slapped in the face really hard but I am taking the risk; we looked, we thought about, okay, people will have to wait for their IPv4 resource but how long will they have to wait? So we did, we made two models with data from 2017 so to take a full year, and what we saw is that if we would continue reissuing the returned resources, the /22 per LIR, at the end of one year, at the end of 2017 we would have had 3,000 LIRs wait for a /22. That is quite a lot. Because that is only one year, you know, and that would grow. But what if we were to distribute /24s, then you would see that many more LIRs would receive a little bit of address space and the waiting list would be much shorter. Now, like I said, shorter waiting time, why the distribution? It would make the waiting list less attractive for people that want to speculate on IP addresses because lets be honest /22 is not a lot of address space, but even if you have to wait a few years, once you get it it's still worth something on the market, so people would say I'm going to enroll on the waiting list, just for speculative reasons and lowering the size of the allocation would fight that up to a certain extent. Now, there has been a policy proposal last year about reduction of the allocation size, that's why I said it's dangerous thing to bring up because to keep it mildly, there was a lot of discussion about the policy proposal, but maybe that policy proposal was a bit too ahead of time, maybe it was a bit too early to bring this into place. And at the moment we are really dealing with the bottom of the barrel and everyone will have to move to IPv6 anyway so you can decide this, you know, how to deal with a little bit remaining.
So that was our last idea. Yeah. If you have any questions?
AUDIENCE SPEAKER: Carlos, about the returning addresses, how are you getting those? People are willingly returning them or you are getting because some members are infringing the RIPE by‑laws or whatever, the RIPE rules and they are getting returns?
ANDREA CIMA: It's a good point, I could have actually mentioned it, it's a mix, a combination of the two. Some organisations don't need the resources, they want to give them back, they know it's a good, which can be used for many ‑‑
AUDIENCE SPEAKER: It sounds very strange because people are making money out of ‑‑
ANDREA CIMA: Yes. There are still some people returning them but many of them come from LIRs which are being closed, for example that go ‑‑ businesses that close or that go bankrupt, the company doesn't exist any more, there is nobody taking over, invoices are not being paid. Part of it is registrations due to non‑policy compliance and of course there is issues with that people breaching E SS A or not complying with policy resources so it's really a combination of all of those matters.
AUDIENCE SPEAKER: I would like to see percentage figures but I am not going to ask that.
ANDREA CIMA: Yes, we can bring those numbers up, yeah.
SANDER STEFFANN: Yes, so I think moving addresses to the IXP pool would be a good thing because IXPs will be needed for a long time and like you said, four years might be a bit short. The allocation size, always been a fan of that to reduce to a /24 because I think it lowers the amount of abuse and especially when we do that at the time that the waiting list kicks in, I expect a lot less resistance than last round. So I think those are good ideas.
ERIK BAIS: Sander. You said moving IP space in the IXP pool are you meaning the extension of the current 16 to a 15 or the dust?
SANDER STEFFANN: Both.
ERIK BAIS: Just for clarification. Thanks.
AUDIENCE SPEAKER: I am from telecom Egypt. I have a question about the proposal of reducing the size to allocated ‑‑ /24. Once we start advertising /24s through the BGP table to the upstream provider, most of them are not accepting this size of addresses so what do you think about this? Because it kept asking to make more summarisation and because the abuse, the BGP table and the hardware resources and so, so what do you think about it?
ANDREA CIMA: Yeah, I think that that's a very fair point and indeed that's why I bring this point up to discussion, because you are the experts on this and you know and in real life how this works and what ‑‑
AUDIENCE SPEAKER: Most of upstream providers are not accepting /24, at least you are asking for /22 or 23.
ANDREA CIMA: Okay.
ERIK BAIS: It depends a bit about if you are talking about deaggregated space or if it's allocated space. Typically if it's allocated space and you get a /24 from the NCC, and there is a valid route object, then they will route it for you, because that is the size you have. Smaller than that, a lot of providers actually have filters that filter smaller than 24s or smaller than 25s. So, if it's a more specific from that, you are right, but a lot of providers actually have the, in their filtering just default filters and smaller than 24. Upstream providers, if they tell you can you aggregate, so if it's an 18 and you announce it in /24s, you know, that is a valid point to ask you can you actually, you know, route ‑‑ In this case, but you have to give me the blocks of /24 from the same range so to allow me to make it more aggregated.
ANDREA CIMA: And one point in addition to this is, from our experience, and again, you are the network operators, you know better than me, from our experience over the years we have issued, assigned many thousands of /24s of PI blocks, for example, and we never got complaints about the block it's not routable or it's being filtered out. Smaller, yes, but /24, usually was well accepted. But you are the expert.
AUDIENCE SPEAKER: Thank you.
AUDIENCE SPEAKER: Nurani. I think it's fantastic that you are pre‑empting some of the discussions you see will come and as we move closer to as that graph gets closer to the bottom, I think we will have a lot more of these discussions, so the fact that you are putting the statistics out there and pre‑empting it I think is very useful and I think we need to continue to do that as we reaching exhaustion.
I think most of what you have said makes sense. Replacing the contiguous /16 to /23s, 24s, I think that makes sense. I think the waiting list makes sense. I think ‑‑ I don't know if it's too early to look at the IXP pool size but I think it's a valid question. And then as for the /24 allocation size, I think we had a very heated debate about this a year ago, and the arguments put forward was mostly really in terms of how can we extend the lifetime of the IPv4 address pool and I think we all agree that we can't and we are talking about very ‑‑ you know, we are not gaining a lot of time but I do think your point about the waiting list makes sense, as we ‑‑ if we are going to have a waiting list, if we are moving to /24s, to simply being able to serve the LIRs quicker, I think that makes sense. Again maybe it's a little bit early to, you know, make decisive, well, you know, have a decision about it, but I think as we are moving into that waiting list, this will come up and we might actually converge, you know, on a /24 allocation size. Thanks.
GERT DORING: While I have you at the microphone, from your understanding of the IXP market, do you expect the growth or the number of IXPs to go up like this as in the last year or is there a saturation coming up? This is really about the question, with the IXP pool growing the way it does, do we need more space, do we need less space? What's happening in the global world of IXPs? I am not an IXP expert, I just connect to a few of them, but you know the market better. Also I will ask Nick to help us here.
NURANI NIMPUNO: We deploy IXPs all over the place, the existing IXPs they might be running one or a few. So speaking, you know, totally self‑interest, we think that there are many, many places that need IXPs still in this region. I don't know if it will be exponential, but I think smaller local interconnection IXPs, there is still a lot of place for that, and we also seeing some of the maturer market, that having more than one IXP is actually something that operators want, they want that diversity, and it also kind of keeps the incumbent a little bit honest. So I do think there is still a lot of growth potential for IXPs in the region.
GERT DORING: So if we modify the pool size at all it needs to be bigger?
NURANI NIMPUNO: Yes.
AUDIENCE SPEAKER: I have another question for you.
NURANI NIMPUNO: This is way too early.
ERIK BAIS: If you see member sizes on IXPs specifically the smaller ones, would the dust actually be useful and helpful because the IXP VLANs are typically not routable on the Internet anyway?
NURANI NIMPUNO: I don't ‑‑ I don't know. I think I have to think a little bit about that, to be honest. Yeah.
ERIK BAIS: I will ask Nick in the back.
NURANI NIMPUNO: And then I will have another coffee and we can have another discussion, thanks.
AUDIENCE SPEAKER: Speaking in a personal capacity from the as an APNIC community member, we have a waiting list in APNIC region. We have 623 people request in that waiting list. And we are 101% sure that will grow, it will not decrease at all and we are at stage, we are talking about abolishing that waiting list because it doesn't make any sense any more. Addresses will not magically appear from somewhere. There will be some people, I don't know why, they will return addresses to NCC. The only addresses that you are going to get is from the IANA recovered pool and that is very small bed. So creating a waiting list at this stage, I don't think it's necessary but of course it's your region, you decide for yourself.
ANDREA CIMA: If I may ask you because I know at APNIC there are two pools, two waiting lists, two separate ones, I think the situation is a bit more complex, because here we would say it's just one list, if you justify according to policy, you know, it's there for new members and existing members. So the situation is indeed a bit different. But what would you then do with address space that is being returned? Because there is a need out there for this IPv4 address, people, if they are waiting in the waiting list it means they want those addresses so what should we do with it if not issue them to the next person that comes and they request for it?
AUDIENCE SPEAKER: So as I say, the list is 623, people are waiting there for last two‑and‑a‑half years. If something pops up from IANA or somebody returns; of course somebody is there for last two years or three years they will get it but there should be some cut‑off date, that after this date there is no waiting list, well of course there will be thousand requests coming in before that, but the thing is, you have to come up with a solution. We are at that stage, everybody is saying this is insane, abolish that list, it's just growing on a daily basis. It doesn't make any sense. What was the last ‑‑ so how much addresses you receive from IANA last time?
ANDREA CIMA: From IANA, you know, it was a couple of thousand ‑‑ no, but that is not what it would count on. It would just for the resources that being returned. At the moment, it's about half a million a year, the registrations, indeed policy non‑compliance, non‑payments but also some people that would give back something which of course I expect to diminish, but, yeah, there is still stuff coming back.
AUDIENCE SPEAKER: If you couple that with /24 allocation size, it is still negotiatable, but with a /22 size, I don't think so it's going to make any difference.
ANDREA CIMA: And I agree with you and that's why I wanted to show what difference it would make, indeed.
AUDIENCE SPEAKER: Thank you.
AUDIENCE SPEAKER: Hello. Sebastian. A few things were already answered that I wanted to ask but the first one I think is pretty much yeah, why not, change the one block to ‑‑ I mean who could say what is unforeseen, you know, so I don't think it makes any difference. Creation of a waiting list, yeah, it's probably a thing we could do, I don't think ‑‑ I don't see any apparent harm in it. What I would like is some sort of expiry function for people in waiting list or at least they have to confirm every so‑and‑so often that they are still interested so that the list can shrink and I not stay there for the next five years and not bother because if I don't need it, the people get ‑‑ get we moved from the list, that will be something I would like.
Yeah, moving blocks under /24 ‑‑ to the IXP pool it would be interesting to have data from IXPs that are requesting stuff right now, at least to say how they really would need and if they would be happy, if they would receive less than a /24. I don't know if this data is available for the past, if that was asked, how many addresses they actually need or if they just got a /24 and went away. Yeah, and I'm not sure either, you know, like, you can grow like 200 members and a then that is it, okay it mightn't for some smaller IXPs but remembering is really a pain for IXPs, so, yeah, I am not sure about that. And /24 allocation size, I'm not sure if I am mentally stable enough to touch this right now, but it would probably make sense, coupled with the waiting list as your graphs show but I'm ‑‑ I would hope that now, that a few months have passed, this thank people will more willing to come together on this but I am not 100 percent sure on this I must say.
ANDREA CIMA: Thank you.
ERIK BAIS: I have a question for you. You stated about expiry date on the waiting list.
AUDIENCE SPEAKER: Yes, like
ERIK BAIS: Are you looking at confirmation or that people just fall off the waiting list.
AUDIENCE SPEAKER: They have to confirm, yes, I still want this address space or I want less. I wouldn't say that they can come and say now I want more, but if they say okay now I need less or I don't need it at all they should be removed, like, I don't know, every six months or every ‑‑ I have no idea. But some function to remove people that just on the list and probably forgot about it because they are probably on the list for a long time.
ERIK BAIS: Okay. Good.
AUDIENCE SPEAKER: From the RIPE NCC. We have a question from a remote participant. ‑‑ IT security solutions asks: How long would you expect until we can live without v4 as a major component and smaller companies can think IPv6 is enough? And also has a comment: I do think it makes sense to make the smaller blocks individual /24s and /23s, makes sense for IXPs instead of the /16s.
ANDREA CIMA: So with regards to the question of how long if I understood correctly, small organisations will be able to live without IPv4, actually I want to turn this question to the room because I think, like I said, I do not have the ‑‑
NICK HILLIARD: I will answer that question, it was answered 20 years ago by Father Ted: 'That would be an ecumenical matter'. There is no answer to that particular question, I think. I have a couple of comments on this. The unforeseen circumstances pool, as far as I remember that is due expire when everything runs out, is that correct?
ANDREA CIMA: That is correct.
NICK HILLIARD: I would be in favour of making this a permanent arrangement ‑‑ I would be in favour of keeping a /16 permanently squirreled away, just for some use. We never know what is going to happen in future. Removing the time limit
ANDREA CIMA: Okay. We would need a policy change.
NICK HILLIARD: It would need a policy change, you are correct in that. The waiting list, half Tab is spot on, there is no point in having a waiting list which extends to infinty, it doesn't fix any problem, it gives some sort of an illusion of fairness, but as the waiting list becomes longer it becomes increasingly clear that, in fact, the waiting list is very counterproductive and very discriminatory against new market entrants into the Internet community, and I would very much be in favour of either not having a waiting list or else have a waiting list which had a very strict cut‑off policy.
ANDREA CIMA: I would like to ask you a question as well. If there would be no waiting list, what would you suggest and instead of that because we still get some addresses back and either we leave them there on the side, we leave them in the pool, we do not touch them, but, you know, that could be a waste as well because there are people that need them. How would you handle that instead?
NICK HILLIARD: If you don't have a waiting list, there needs to be another allocation mechanism. There is random allocation, if you have a waiting list you can expire people using tail drop‑off, at the end of it. There is ‑‑ there are a lot of mechanisms, all of them are a little bit contentious, and I think from a sort of a policy optics point of view, having an infinitely extended waiting list is probably the thing least contentious but will offer the worst performance characteristics.
ANDREA CIMA: The thing is with current policy, people can still indeed request resources even if the pool is empty and we would have to accommodate them, first‑come/first‑served. Let's say the waiting list is the natural way doing if we keep things as they are, indeed certain other things like cut‑off dates and those are things that can be worked around but if things stay as they are that would be a bit, I would say the natural continuation of based on the current policy.
NICK HILLIARD: Yes. So I think, you know, we need to come up with some ideas about what sort of thing we want. It actually doesn't terribly matter what sort of policy we implement because every policy is going to be a bit contentious, but I do think that having an infinitely long waiting list is not the way doing, it's not going to implement any ‑‑ affairs. On the IXP pool size, if that expires before everything else, I don't know, that is difficult, if it were possible to throw some extra IP addresses in there it would be great but I don't know how the rest of the community feels about it. IXPs tend to be quite important in, they have their place in the ecosystem, so I think probably opening this on to the mailing list would be good idea. The blocks smaller than the /24 in the IXP pool, this is problematic and this kind of gets down to the issue of whether IXP prefixes are routable or not. I think IXPs are split on this, some IXPs like to reach the prefixes and others don't and there are good reasons for doing it and also good reasons for not doing it but prohibiting an IXP from doing this on the basis of the assignment size that they get is a difficult thing to swallow and I personally prefer if the blocks that were smaller than a /24 were just put aside as dust and according as the organisations who are claiming the rest of the /24 relinquish their space over time, it will happen eventually over time, that they just be turned into /24s, you know, it might take ten years, it might take 30 years but it will happen over time.
ERIK BAIS: I have a question for you. Having blocks smaller than /24s for IXPs, how much problem will that have with rDNS for instance?
NICK HILLIARD: It's something that can be solved with ceilings and PTRs, it's a bit of a pain to be honest with you. We have run INEX at several stages with several different /28s, 27s and 26s before we finally just went /23. So it's doable but it's a pain. And it's something that, you know, it's not a huge amount of PI address space in the scale of things and just from a strategic point of view I think it's a little bit easier for Internet Exchanges to use /24 as a number. But as I said, it's, you know, I'd welcome a community input on it, you know, I think there is ‑‑ as an IXP operator I am sort of quite happy to say that I think IXPs are sufficiently important to get slightly better treatment but on the other hand everybody else feels that their organisation is in the same boat so it's a contentious issue.
The /24 allocation size, I have argued against this in the past. But I think that once the existing pool runs down to zero, that we should probably flip over to a /24 allocation size but not before.
GERT DORING: Thank you.
AUDIENCE SPEAKER: Thank you for your presentation. I want to give some comments about small blocks and I suggest these blocks should be connected to the closest /24 blocks by two reasons: First of them, it's not much space in the dust to be significant, and the second one, we need to remember that there are another one blocks in the RIPE database that was allocated a little bit so the last segment is not routable for people who use it. And they still owns this IP space but they can't use it for routing. So when blocks will be connected and RIPE database will be simpler and clear, as I said.
ANDREA CIMA: Thank you.
AUDIENCE SPEAKER: Just a quick question. The question on IXP pool size is this large enough, you are asking what is the current size right now is
ANDREA CIMA: What is the? What is the current size of the pool ‑ we have policy /16 is set aside but half of it is being issued to IXPs. So we believe that if we take the current assignment rate for IXPs, it would last for another four years, that is with the current assignment rate only for IXPs. IXP peering LANs.
AUDIENCE SPEAKER: And do you have any data to ‑‑ as a starting point, saying in last five years we have got that many requests?
ANDREA CIMA: I can show you, I should have on the graph. This shows the last six years. IXP peering LAN assignments, yes. And you can see it's, the growth is very stable in the number of blocks issued.
AUDIENCE SPEAKER: In this graph, I am just trying to understand, it's number of blocks or number of requests ‑‑
ANDREA CIMA: Sorry, number of IP addresses issued in the thousands, as you can see it's a /16 in total, you see the graph goes up to on the axis to 70,000, and there the top. And we see we have halfway through with the total issued IP addresses for IXP peering LANs. So we have halfway through the block available.
AUDIENCE SPEAKER: And the maximum you can get thousand
ANDREA CIMA: /it 22.
AUDIENCE SPEAKER: It means if there were 30 IXPs who requested last six years and that is ‑‑
ANDREA CIMA: It's the maximum. Some of them have a /24, some of them 23, it depends a little bit on the size of the Internet Exchange point.
AUDIENCE SPEAKER: The only reason I am interested, in APNIC we don't differentiate IXPs, it's just requests coming in and we deal accordingly. And apack ‑‑ there are four currently which ISOC is helping right now. And there is a problem. But the problem I see here is, if you are going to increase the pool again from where you are going to bring in the IP addresses from, and
ANDREA CIMA: They would come from the existing pool.
AUDIENCE SPEAKER: Yes. And you have a waiting list problem again, user is trying to solve so just moving everything to IXPs and forget about it then.
GERT DORING: Maybe I can comment on that. The idea why we have the reserved IXP pool is that whatever you do, you will need ways to interconnect networks and these need before addresses as of today. So, IXPs are indeed special and the Working Group decided to take this into account and really cut off a bit of v4 space that everybody else would like to have because IXPs are needed in the infrastructure. If you can't:not interconnect your networks what it's good for.
AUDIENCE SPEAKER: I totally agree. Giving ‑‑ I know an IXP which is running on 22.000//24. Don't quote me.
GERT DORING: It's not ‑‑
PETER KOCH: I have two points, one on the unforeseen /16, it looks very appealing to use that to lawneder the prefix sizes and maybe this is already the unforeseen circumstance, other than that I would think it needs a bit more like chewing on because we are in the unknown unknowns and maybe the unforeseen circumstance needs a bigger chunk of contiguous address space and then again maybe we can toss that because there will be an endless battle at some point in time for the remaining addresses, it would be more valuable to everybody to burn them,
By handing them out. So there is too many unknowns in there to make a decision at the happening I think. The other one brought me up here, you mentioned first‑come/first‑served and I think there are different ways to read that, in the domain industry, as you probably know, some people believe in waiting lists and some don't, and they are right. And with waiting lists you shift the race to an earlier point in time and without, we have all this dropping catching and so on, so in turn for the addresses the RIPE NCC would be faced with people waiting for the addresses to appear from the IANA reassignment and then hammer on the NCC system to get into the line whereas with waiting list we have all these issues that people pile up, demand that is probably not justified at that point in time and so on and so forth. But just because it is first‑come/first‑served doesn't mean that anybody who goes to a closed restaurant has a right to table it the next day. Thank you.
ANDREA CIMA: Thank you, Peter. I wanted to add one clarification to the /16 for unforeseen circumstances, I just want to add that in how the policy is currently in place, this /16 will disappear once we reach exhaustion of the pool so it will be gone.
GERT DORING: Actually I think my gut feeling tells me that Peter is right on this, that burning up that block just to have more convenient /22s might not be worth it because it's just 6422s so everybody will still be unhappy and if we need to 17 for something it's gone. So maybe not go that way.
Yeah, will to wrap it up, I think what we are certainly not going to is reduce the IXP pool size, so that is off the table. We could increase it, but I would need a volunteer to come up with a proposal and stand the heat. You know who you are, so ‑‑ it should be discussed and see what comes out of it. I hear that you don't want the dust, that's good, so it's a clear statement, and allowing the IXPs to decide on whether you want a to route or not your interconnect network makes sense and if we say we allocate dust or assign dust to IXPs then we have the clause about routing reasons again in the IXP policy which I don't think we'd want doing there, like I want this routed so I get it 24, I don't want this so I get a 27. Maybe not. So ‑‑
ERIK BAIS: Do we want volunteer from the IXP community or to we want somebody that actually has ‑‑
GERT DORING: I pose the question to the room. There is volunteers from the IXP community. If they want this they know where to find us.
ERIK BAIS: Any volunteers? Thanks Nick.
GERT DORING: I was not looking at Nick in particular. You know how the system works. Find more co‑volunteers, so you can share the heat.
NICK HILLIARD: I will co‑opt somebody.
GERT DORING: On the /24 allocation size, what I seem to be hearing from the room is that when we run out this this sounds like a better plan than sticking to 22s but it's a policy change so ‑‑ I was looking at a volunteer.
ERIK BAIS: I think we have found somebody here.
GERT DORING: We have somebody who really understands policy making and volunteers to to it from the other side. Thank you, Sander.
AUDIENCE SPEAKER: This dust we are talking about, where does this come from? Other actually people using this ‑‑ I mean, how could you get something less than ‑‑
ANDREA CIMA: It's left overs dust inseed. We used to also in the past assign PI assignments as you know and these were based on justification or need and there were some people that were able to justify maybe a/25 or even a/26.
AUDIENCE SPEAKER: Or 29
ANDREA CIMA: Yes, up to 29. And those blocks were being issued and ‑‑
AUDIENCE SPEAKER: So you could receive a PI assignment above ‑‑ seem yes, there are. And not many, but that's why we don't have a lot of dust either so we are talking about little bits and pieces, 6,000 IP addresses in total so it's very little and can be shovelled under the carpet as well. If we put the dust under the carpet, I think it must be a conscious decision that you want us to do so.
GERT DORING: On the dust I have been thinking if it might be worth giving to the additional block holder, doubling the size of the next block. I think it might be a quite a lot of other to find out who is holding the other addresses and ask them whether they want another 29
ERIK BAIS: Or need.
GERT DORING: It might not be worth it and you need a policy change for it so it's quite a bit of effort, I am not sure if it's worth ‑‑ it's a housekeeping thing, the dust would be gone so nicely brushing up everything but stale bit of effort.
ERIK BAIS: I don't think it's worth the trouble finding the other holders for adjacent blocks, I don't think that is worth it.
AUDIENCE SPEAKER: Just a quick word about the dust. Since more than ten years we are trying to run a new IXP portal, which is 300 kilometres away from the capital city and until now, we have three members, so a /27 sounds more than enough, so I wonder if that also is happening in other countries with small communities, small networks that could benefit of this dust?
GERT DORING: That was my thought and this is why I really asked Nick to be here at this early morning, to give me feedback from the IXP side of things. So I have heard now you say a/27 would be good and Nick says don't go there. So, IXP people, please make up your mind. This is really something the IXP world needs to decide on what you want the policy to look like, because the rest of us that is not running IXPs, I have been told, in no uncertain terms, last time, has no idea about that. So I'm not going into that land again telling IXPs whether this should be routable or not. I have some ideas but I have heard that the IXPs have different opinions, for good reasons. So, I you make up your mind, you come up with a proposal and we find consensus or not on it.
AUDIENCE SPEAKER: Didn't we have something close to dust in what was called temporary allocations, don't we have to do something about the ‑‑ about this, at some point in time?
ANDREA CIMA: We have/, what is/13, 13 or 15 ‑‑ 13, we have/13 set aside for temporary assignments. One of the ideas need was as well to maybe take the dust and put it in that pool. That could be one idea as well. If it ever gets to the fact that we need the full/13 for the temporary assignments. At the moment, the total amount that we have issued together at the same time out of the temporary pool is less than half of what the pool size is, and we expect this of course to increase once there is no free pool any more. Indeed that could be another idea as well to put the dust in the temporary assignment pool.
AUDIENCE SPEAKER: Not only, do we need to continue with temporary allocations? It's a /13 when we are talking about unforeseen circumstances it's a /16?
ANDREA CIMA: It's a good point. At the moment the maximum we have issued at the same time was half of the pool availability. We get a lot of requests, though, we always get requests for temporary assignments and these are conferences, events, and there are many of them that on a regular basis once or twice per year come to us and ask for block of IP addresses, use it and give it back. So I believe that to have the temporary assignment pool is very important, so I would definitely we will keep it, with regards to the size, yes, that can be discussed, but I expect as well that we will have more people coming to us for temporary assignment once you cannot get address space any other way. But it's a veiled point to discuss.
GERT DORING: Thank you. So, thanks for giving good input. We very much overran the time initially allocated for this but it was a good use of our time. So I was looking at my watching and decided yeah, we just move the next talk to the next session.
ANDREA CIMA: Thank you very much, it's been very useful input and I think we can move on, thanks.
(Applause)
GERT DORING: So, the next official item on the agenda is Ingrid and the country codes in the RIPE DB and that stat files but that needs some educated discussion and ten minutes is not enough. So we moved that to the second time slot. Don't run away, and I have not yet on the agenda list, from Fergal, to inform you about the candidate for the NRO and NC election coming up because the election is starting tomorrow and the NRO time slot on the agenda is on Friday, so that's a bit late to have the candidates introduced.
FERGAL CUNNINGHAM: We have the NRO NC election this week, all attendees should have received an e‑mail yesterday with link to register. But we have two candidates, Omid from Iran and Nurani who should be here and we are going to have them both have a statement. Omid can't be at the meeting today, so I am going to read a prepared statement that he sent us:
"Dear respected audience and attendees, I, Omid Mahdi Ebadati, PhD in computer networks, specialist in network security, faculty member of Kharazmi University and head of ICT centre and director of Kharazmi CERT Centre. First of all, I am very happy that I could not make it and be present in that glorious meeting. What I believe we need, today, is to work and have an accurate action plan, to shape the future of RIPE NCC and that cannot take place with a customer‑orientated point of view. Finding and handling opportunities that we can gain more valuable trust along with revenue clients and their infrastructure to the future points with IPv6, secure infrastructure and expansion of that. This can take place with the ex pension of workshops and related training in the different geographical regions. I want to extend my gratitude to all of you and wishing you the best. Thank you."
And, Nurani, do you want to give...
NURANI NIMPUNO: Good morning again. From Asteroid. I am currently serving on the ASO‑AC and I would, I am asking for your confidence in allowing me to serve for another term. I think ‑‑ I been involved with the RIPE community for the last two decades and also involved with the ICANN community and sort of the larger Internet community globally for the last decade, two decades.
I'd like to serve again because I believe I know this community and understand its needs in the ICANN context. I also think as the ASO is going through this review where we are looking at where do we fit within the ICANN context, what should we to and shouldn't we to, I am hoping to bring that experience with me, but also the fact that I feel that I can speak to all of you and you can come to me with your input and I think that's very important in someone who serves in this role who can kind of pick up the needs of the community and bring them forward. And that is it. Thank you very much.
(Applause)
FERGAL CUNNINGHAM: Thank you. I will send a reminder registration mail, the registration closes tomorrow at 6, I think, yes, 6:00 so please register by then. Thank you.
GERT DORING: Thanks, Fergal, for bringing this to our attention. Thanks Nurani. With that, we are minutes early for coffee break. Something new. Enjoy your coffee and please be back at 11:00.
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
