Address Policy
16 October 2019
9 a.m.:
GERT DORING: Good morning everybody, good morning dear Address Policy Working Group, I am happy you all found the room. I heard there was quite a bit of confusion on where the said room is and it's ‑‑ you enter on the side.
Anyway, this is the Address Policy Working Group, I am your friendry chair, my co‑ chair Erik Bais is sitting over there, but you know us anyway. This is the agenda for the first half of the meeting today, administrative matters, the usual thing, we have a quick show of the candidates for the NRO NC election that is coming up on Thursday, then we will have lots of time for the panel discussions that Erik planned, this is something new for us. So let's have an exciting discussion there, and then as you can see from the lettering, something that wanted to go to slot 2 but since Remco has a different Working Group to run in the second half we do his proposal in the first half. After the break, we to the usual stuff, current policy topics from Marco, feedback from the NCC RS, from Nikolas, discussion of the open policy proposals which will be the other one, then, and AOB and open policy hour.
So, agenda bashing. Anything that needs to be shuffled around because more conflicts? No. So, we do it that way. Minutes, the minutes from the last meeting have been sent to the list about two weeks ago. I admit I haven't read them this time because they were long and very detailed and I just had no time, but I trust you all to have given them a good review, so I haven't seen any comments about something was wrong, so Erik actually read it and said they are good. Okay, I heard at least two voices that said "I have read it and it was okay". So anything that was not correct? Missing? Nothing, so declared final.
NRO NC election. I am already in sum‑up time but this is working out nicely because I am going to hand the microphone to Filiz now anyway. We have one seat on the NRO numbering council which is vacant now, since, well, the NRO is representing us as global policy forum. It's interesting for us as Working Groups so I invited or we sort of of arranged that the candidates can introduce themselves here, the election happens Thursday evening to Friday at noon, or 10:30 electronically you have all received an e‑mail with the details already I think. Steffann cannot be here, but Filiz is here and this is the first on the list anyway.
FILIZ YILMAZ: Thank you. I am standing for elections for another term to represent RIPE region the NRO NC. I believe I have done a good job in the past years, I was on the council when transition happened and moving on, I was as the ASO or NRO NC chair as you know it here, I managed a process having after our regular five year review process, that included, you know, running or managing a community consultation and implementations of the recommendations, as we see them fit. So, I would like to continue driving and managing the impact of these changes and continue representing the community in that capacity at the NRO NC council. Thank you.
(Applause)
GERT DORING: Thank you, Filiz, and thanks for doing this in the past. Now, we have Anthony from the NCC who is going to read the ‑‑ come up here so we can see you, you can do the dance and the thing. For Stefan who cannot be here today.
Anthony: This is from Stefan. Dear community, I am currently working as a senior system network administrator at hell house Bulgaria, but taking a seat at the NRO NC I will be able to assist in the policy development process and gain valuable experience. My strong technical background and knowledge in the community will be a great asset to the council and to the Internet community. Thank you.
GERT DORING: Thank you (Telehouse)
With that, we go to the exciting panel discussion Erik has prepared and I hand over the microphone because I have no idea what this is all about, it's talking about IPv4, I think, that old stuff, stone age. Erik, please.
ERIK BAIS: Morning everybody. This is going to be a fun one. This is going to be a first as well, we are going to do a panel discussion and I would like to ask the panelists to come forward, join us on stage.
So the idea what we have is and Gert put it nicely in the slide, IPv4 is running out again and we wanted too far discussion about a bit of a review what was actually done, where do we get here with the current policies, the transfer policy, did it work out as we planned and also have a look forward, because now we actually hit the end for the inventory for the RIPE NCC and see are we going to see new technologies and Newmarket movements and take it from there. So what I would like to ask is a short introduction. Let's start with Remco.
REMCO VAN MOOK: Are are you sure? Just your name, affiliation, why you are here. (Erik Bais)
REMCO VAN MOOK: Good morning everybody, my day job is running a company called Asteroid and I am also on the RIPE NCC Executive Board and have been doing that for nine‑and‑a‑half years now, and one of the reasons why Erik invited me up on stage is because about 12 years ago I was the main instigator behind something that's now known as a transfer policy and if I had known that I created a billion dollar industry I would have invested earlier.
Gabe Fried.
GABE FRIED: My day job is running a company called hill co‑stream bank. It's biggest sort of subcategory of business is IPv4 global, which is an address brokerage that has been transferring IPv4 space in ARIN, APNIC and RIPE since 2011ish, so we have ‑‑ I think I just bring the market view and a lot of Doring data to the discussion.
SANDER STEFFANN: Good morning, one of the ex co‑chairs of this Working Group, especially around the thyme we introduced all this transfer policy and and all the effects it has. As a day job I am a freelance consultant doing networking, automation, some software development, so pretty diverse. But yeah, for now, this is for about my role as former co‑chair.
STEFANIA FOKAEOS: I am working for the registration service at the RIPE NCC the last four years, I am experience from improving your resource requests until doing the transfers, so for the whole cycle of the resources that we distribute to you and, so Inter‑RIR transfers, normal transfers, whatever it is regarding regarding end number resources.
ERIK BAIS: Thank you very much. So what we will do is, I will ask some of the panelists on specific topics that we started. Let's start with history. Remco. What was the initial intent for the transfer policy, which was not named a transfer policy at that time, if I recall correctly.
REMCO VAN MOOK: No, it only got, started to be called transfer policy later. So, the original intent was that around the 2007 time frame, we started to notice that address space was being shuffled around in different ways than through the RIR system. Think of that what you will, and I mean, I am not one to judge on any commercial aspects of that, but the real problem that we were trying to address initially was to make sure that, irrespective of whatever this was happening outside of the RIR system, we still needed to have an accurate database, an accurate representation of who owns what or who is responsible for what, is maybe a better way of putting it, and so the initial transfer policy which I had to rewrite, I think at least three times, I am looking at Nigel who is there with me, introducing more and more restrictions, was actually really just meant to make sure that this stuff could be done above the table, didn't have to be done in smoke‑filled back rooms, and Wednesday' like that we would have a decent track record of what happened, and that was really the intention of this.
SANDER STEFFAN: So in ‑‑ especially in those days, it was highly controversial, people were like, but this is wrong and if people don't need the resources they should be able to sell them and hand them back to RIPE NCC. At that point it was getting really clear there was going to be a shortage and that means it's worth money. So, there was a big tension in the community between, okay, we don't ‑‑ if we make a policy, we are allowing this, and we don't want to allow this, but if we don't allow this, then we end up with a database that is full of historical data but nothing accurate. And that was a really difficult balance at the time. Aye remember in the early days, people like Gabe wouldn't dare to show their face at a RIPE meeting because people were really against this and only over time people realised this was tally something that was necessary but especially in the beginning it was a completely different mindset than we have now.
ERIK BAIS: Because the initial RIPE run‑out when the initial /8 policy came into place, this was September 2012. You stated this started in 2007 so well ahead, and I remember when I started, you know, coming back into the RIPE policy game in 2010ish, you know, people were got on that we needed to have more accurate database and that this was really necessary. Gabe, from your perspective you also had experience in US part, this is where the company was started, where hill co‑got involved in brokering of address space. How was that in the US, were you already involved when the US and ARIN was in that space? Or did you come later when the policies were there.
GABE FRIED: So we, I am not sure that I have that chronology exactly correct, but we brokered our first transaction at the end of of 2011 and I think at that point in time the transfer policy was already in place. That was ‑‑ I think our first transaction was four or five months after the mic soft acquisition of space from Nortel and Nortel's bankruptcy. We were ‑‑ you know, since then, so going on eight years now, I have been reading the public policy mailing list and the ‑‑ in many regions as I have linguistic fluency and debate has largely not evolved from this issue of, you know, what is registry's role, is it maintaining database accurately? Should it engage in behaviour that is knowingly market influencing, for example? But the evolution of ‑‑ what I think will be interesting, you know, in years to come, is a backwards look at what happens in terms of market activity when you compare the ARIN region which had sort of a cold run‑out to the regions that have had soft landing policies. You know, that is fodder for some economics graduate student's feature research.
AUDIENCE SPEAKER: Can you elaborate, you used cold run‑out.
GABE FRIED: In the ARIN region there was no soft landing policy. There were some, I think there were some restrictions on the block sizes you could receive from the ARIN free pool in the year leading up to run‑out, but the run‑out literally went to zero, I think in September of 2015 or '14, I can't remember. And versus what happened here in the RIPE region, which was, you know, a last ‑‑ a last /8, you know, /22 policy, which is similar to the policy in APNIC. So, in the ARIN region, if you didn't have address space by the time they ran out, you had to go to the market, even if your need was only a /24 or 23 or 22
AUDIENCE SPEAKER: And you call that a cold run‑out, that's the term?
GABE FRIED: Right. That's my term, it's the term of art. A crash, but ‑‑
SANDER STEFFANN: A cold run‑out, a brick wall.
GABE FRIED: A hard landing, not a soft landing.
GERT DORING: As a matter of politeness to the remote attendants, if you ask questions please use the microphones, this is all webcast and people are listening in remotely. I just put a microphone on your table.
ERIK BAIS: So, from the standpoint for Stephanie, for the RIPE NCC has been extremely busy in the last couple of months with the actual run‑out again, we saw this also in 2012, now we saw this again, now there were big backlogs actually, and I think the RIPE NCC is now starting to catch up again. If you look at the initial transfer policy, what we have had now for the past seven, eight years, can you tell about your own experience with the transfer policy and perhaps also a bit about the Inter‑RIR transfer policy process and how this is ‑‑ was this actually a workable solution for, you know, the intent that we had database accuracy and actual, you know, was this working for the customers.
STEFANIA FOKAEOS: So for sure it increased accuracy for the RIPE database, we know who used address space, which is the holder, so that's the good thing, and also it helped people that they had confidence they grew to be able to get more address space from the market because eventually due to the IPv4 policy, every LIR was available ‑‑ was eligible to get only /22 so it helped from that perspective.
Then, so far, it seems to work perfectly fine. Sometimes we need to increase due diligence to ensure that everything goes smoothly and this is with the best intentions of ‑‑ fort resource holder. And we think it works so far, so good, I can say. Sometimes it's difficult for some people to understand that we cannot start evaluating a request if it is an incoming transfer to the RIPE region. If the other RIR has not informed us yet. So this is something that is complicated for some people, that they need to wait for the other require to complete their evaluation, they inform us and we are going to start contacting the parties. So far, so good I would say.
REMCO VAN MOOK: There is one thing I would like to point out about all of this. I mean, so you mentioned a backlog. That is not because the RIPE NCC are a bunch of lazy bums, but that's because the membership and in the community has gone absolutely bonkers and started doing registration and new member requests by the hundreds, and and in a run‑out set‑up where you know that you are going to have to slow down on a certain process, sometime soon, getting more people, hiring more people and training them to do this stuff, and then like, three months later say that was very useful, thank you very much, we didn't think was a very useful of spending the members' money.
Another thing I have to say is, this community's absolutely terrible at naming things, because we are talking about the run‑out, but which one is it? Because as far as I can tell, we have got the run‑out, which was in 2012, then we had the run‑out when RIPE NCC started issuing 22s, now we are at the run‑out run‑out run‑out where we in longer have 22s that we can hand out and basically give people bits and pieces, and after that, we are going to have, I have no idea what to call it, the run‑out run‑out run‑out run‑out, I guess ‑‑
ERIK BAIS: Well, we have a waiting list period.
REMCO VAN MOOK: But, the thing is, and having discussions with a number of people here this week, people don't realise that the run‑out actually doesn't mean there is no more space. And I mean, even why I was a little bit surprised by the volume and I think Nikolas is going to speak about it later, but even after we have completely run out, there is still the matter of you are not going to believe this, people returning address space to the RIPE NCC that will then be handed out again and the projected volume for that is about 1,000 /24s annually, and if you look at the waiting list or run‑out run‑out run‑out policy, that means that there's 1,000 new entities that we can serve per year in getting new address space, so even the run‑out run‑out run‑out run‑out doesn't mean we have actually run out. I hope that makes any sense.
ERIK BAIS: Yes. Let's skip all the run‑outs because the teleprompter with half pages of run‑outs here. Okay. Stefan, question for you, because you actually ‑‑ Sander. Sorry, Sander Steffann. You actually wrote or authored the waiting list policy. Can you tell us a bit about what we are going to have once we are run out. Just one.
SANDER STEFFANN: So basically, this is based on analysis from the RIPE NCC, because they showed that if we ‑‑ well, if we run out of /22s and we keep handing out /22 equivalents, the waiting list size is just going up and to the right in a bad way, so that will definitely not work, but if there's a waiting list and if the size is smaller than the curve is a lot smoother and the size of the waiting list wouldn't grow indefinitely, at least not for the first year or so. So, yeah, that's basically what we said, we need to do something. A, we don't have a policy for a waiting list. Everybody was like RIPE NCC can just do a waiting list and I am sure if we hadn't made a policy, that would have been the sensible thing to do. We thought it was a better too far policy to put that in writing, and yes, the size consideration was just based on the prediction of RIPE NCC on how well a waiting list would work based on different sizes.
ERIK BAIS: Thanks.
David Farmer, University of Minnesota. ARIN AC. First, the run‑out or run‑out is not a discrete event, it's a whole sequence of things. If you think of of it only as a discrete event you end up with Remco's problem of how many run‑outs are there. It's all the same thing, just different stages of it. Then, also with the waiting list policy, we need to think ‑‑ you need to think about what the purpose of the waiting list policy is from a policy perspective, and I would propose that it's not to be an effected means to get resources to users, it's a mechanism to ensure resources don't sit and rot at RIPE or any of the other RIRs. That is its only purpose. If you think of it as an effected means to get your resources, you are going to be sorely disappointed.
SANDER STEFFANN: That's definitely clear. That is a very good point because people said why even do a waiting list, just say IPv4 is over and move on. But then, what would you get? RIPE NCC wouldn't hand out IPv4 addresses any more, they would still receive them from bankrupt companies, people giving them back, so RIPE NCC would then give them back to IANA which would once in a while redistribute them back to RIPE NCC who could return them again. Yeah, that wouldn't be be proper behaviour for an RIR.
GABE FRIED: I wanted to add that the market mechanism of being able to go to a broker or find somebody who is addresses and engage in an arm's length trade to reallocate those addresses from one org to another, is a means of keeping the waiting list from exploding. So there will be some organisations that are willing to wait for, you know, three, four or five months, a year, to get a small small allocation and there are others who won't and they will express their need for speed in the marketplace. So I think the waiting list is going to be ‑‑ the management of the waiting list is going to look like a continual turn of allocations coming back to the various RIRs and new entrants or other organisations who figure they can put themselves on the waiting list in anticipation of of a future need and if the need gets too great before they get too satisfied they go to the market and take themselves off the list.
REMCO VAN MOOK: There is one interesting thing I would like to add to that. So if we end up at this point where you end up on the waiting list and lucky enough to receive a 24, if you look at how much you end up paying for that through the RIPE NCC structure, which is a signup fee and then two annual memberships, that adds up being roughly equivalent to the current going market rate for a /24, so there is no ‑‑ basically, you are ‑‑ you are not any cheaper off with sitting in line waiting patiently for the RIPE NCC to deliver.
AUDIENCE SPEAKER: Mikael Abrahamsson ‑‑ currently employed by NTT but I am speaking as a person and not for my employer. That was part ‑ difference part of these discussions in 2011, whatever it was, when we put this policy in place. The goal there was to allow new entrants into the market to actually get space so they could connect to the Internet. Is this considered a success? Did that actually work or did tend up being people registering tens of LIRs to work the system or is it actual ‑‑ did it end up in end user hands.
REMCO VAN MOOK: I would like to say it hasn't been a failure. I mean, there has certainly been enough people that ‑‑ who were more or less effective in gaming the system. As you might recall, about two, three years ago, I did a policy proposal to basically nail every last corner case in every last option that the final /8 policy allowed for and shut to a point where it became almost ususable but at least it would stop the abuse or at least any form of abuse that we could prevent. But that ended up with a lot of nasty words on the policy mailing list and nasty comparisons and at that point I I decided to drop it. I would like to point it out. It's not for lack of trying, but I think that we had, for final /8 we had one shot at it, we got something accepted but any attempt to fix it later on was doomed to fail.
ERIK BAIS: I would like to hear Stefan I can't first. What is your idea about the question from Michael, about was the ‑‑ getting new market entrants intent of the policy, was that also being recognised in the RS and seeing that yes it actually has served that purpose. So again, the question from Michael was: The final /8 policy, to get a /22 for new entrants in the market or LIRs that didn't have requested their final /22 but if somebody wanted to have a /22 after, you know, 2012, then they could still get at least a 22 for any intent was for new market entrants, new parties that were starting a company, do you think that was actually achieved by the policy.
STEFANIA: Well, I believe so yes because actually many different ‑‑ ‑‑ if I understand your question correctly, compared to what was the unusual ecosystem of RIPE NCC and members it was mostly for ISPs, so throughout the years we have seen that the different ‑‑ different kind of companies, industries, have been started becoming part of this RIR system, governments, banks, start‑up companies, so eventually for all these different industries that they needed to provide services to their customers, it helped to have at least /22 and to ensure that everyone is going to get something, so fairness as well.
ERIK BAIS: Okay. Thanks.
GABE FRIED: So it's an excellent question that I think is actually very hard to answer. One of the dynamics that we have seen evolve over the last eight years is that, and ‑‑ is that when you have an organisation that had historically been getting its IP space from an upstream provider, so from PA space, when the inclusion of IP address started to include a new price or a new charge because the upstream provider was running out of of space and had to go to the market, then the end user organisation often ‑‑ I mean, in many cases would come to the marketplace or to ‑‑ or to the RIPE NCC and say, I would like an allocation of space so that I can be independent and it looks like the creation of a new organisation, it's certainly the creation of a new member, but it doesn't necessarily mean that it ‑‑ that that is new entity that now has access to IP space that might not have been able to get IP space for free from RIPE NCC absent this policy. So it's very difficult to actually know how much of this is creation of new entities and how much of this is just pushing the responsible party organisation for IP space out closer to the end user, just as a matter of shortage. Regardless of whether or not the last /8 policy had been in effect, because we do see that in the ARIN region where there was no soft landing policy but the growth of the number of members is significant in large part because peopling are coming to get their own IP space so they can control their own destiny.
ERIK BAIS: Okay.
SANDER STEFFANN: So looking from the Working Group point of view, it's ‑‑ I think it's a mixed situation. So one thing is, like Gabe said, there was no PI space, for example, any more, so anybody who would get IP space became an LIR which from a community point of view I don't mind because it brings them closer to the rest of us. On the other hand, because we still had those /22s, there was also the opinion from a lot of companies like, oh, yeah, RIPE NCC says they have run out but you can still get addresses so it's not true. And this IPv6 thing, they keep telling us v4 runs out but it keeps being available so we don't see a problem. So, it has sent some messages, it has helped some organisations, so it's very difficult, it's a mix of different things and I think in the time frame when we did this, it was a good idea but I also understand ARIN who came a couple of years later and was like well, let's not go there and go straight to a market situation, and if we had been in the same position we might have done the same as a community. But because we were all the way at the front of what was going to happen, we didn't know what the effects were going to be so we were very careful and I think that has worked.
ERIK BAIS: All right. You touched upon v6 and v6 implementations. You have some experience in that field with transition technologies. So, if we ‑‑ if we are moving forward into the discussion, what are the options, looking at transition technologies that people can implement currently or what are new technologies we can expect? I have heard things about MAP‑E, MAP it.
A. Things like that, you have some experience on that and what is your vision or your view on that (T) and then we will ask the other panelists as well. Specifically on that transition technologies, because this is where we are currently and are the technologies actually usable currently?
SANDER STEFFANN: For the background for the rest of the room, for the last three years I have before doing work for Lee Howard and his company to build translators and tools to help companies do this, so this was one of my consulting jobs. Hi, Lee. So, yes, I do have a lot of experience with that. And what we see at the moment, for example, Zigo in the Netherlands using DS‑Lite where the backbone is all v6, the v4 packets the residential users picked up to NAT box and that's it there. This is kind of expensive technology but it was close to what people already knew and it was deployed first, so it got a big advantage there. And the advantages that the end user still have v4 and 6, they just don't do their own NAT and port forwarding themselves, there is a big central NAT box somewhere in the provider network. So that has been deployed really widely because it was the first technology that did this. I don't think it's the best technology because it requires a massive NAT box at the ISP and of course, that's a big ‑‑ a single point of failure, it's expensive, so MAP‑E and T are technologies where they did it differently. They said in the ISP network we are not doing any NAT, what we are doing is, because we want to use the IPv4 addresses more efficiently, split up the IPv4 address based on the port numbers, so you could say, Erik gets an IP address port number 1,000 to 2000 and Gert gets 2000 to 3,000, I am simplifying a bit, you can hand out ranges of ports. And the network at that point can be stateless because they need to know which customer has which ports. Just like before which customer had which IP address and the customer device can do their own NAT and port forwarding on their little set of ports. So I think it's both for the customer and for the ISP, it's a better way forward. The downside is it's very hard to find equipment that does this, especially the home equipment.
And then on the mobile market we see a different technology because there was a big thing with the cost of running dual stack on a mobile network and a lot of mobile networks have decided to go single stack IPv6 so the thank just does v6 and they have a NAT 64 and DNS 64 set up that translates back to v4 at the edge, but for the mobile phones point of view, the whole world has already migrated to v6 and Android has 464 XLAT to cope with that. Apple told the developers this is the new world, deal with it. Which resulted in a much cleaner solution but a bit more work on the developers. So in the mobile world and more wi‑fi networks, usually guest Wi‑Fis, you see this is an upcoming technology and people use that. So mobile and wi‑fi hotspots, NAT 64, and I hope in the future for the residential user we will see more MAP, and whether MAP E or C, that's a protocol difference, but not a functional difference for the user.
REMCO VAN MOOK: Given this is a panel and this is the first session on a Wednesday morning I am going to say something controversial. IPv4 and IPv6 are as alike as IPX and IPv4 and I don't know if any of you have been around in the era when enterprise networks were running on IPX and all of a sudden you had lovely disasters where people were carrying IP packets inside of IPX as some sort of gateway that would magically export it to some UUCP box whatever, I see people cringing right now. But to me, that is the exact same thing as any transition technology between v4 and 6. They are two different networks and two different technologies, deal with it. And I think ‑‑ I mean, what Sander said, the mobile operators in their meddling ways actually got it mostly right this time, because ‑‑ and that's a mindset thing, because mobile operators have never thought that your traffic was actually yours to begin with, and they've always been in the business of taking your packets and hopefully optimising the content of your traffic, whether that's through video optimisation or helpful proxies that inserted their kind of advertisements on your web page or stuff like that. So, for them, rolling a different protocol to handsets which then translates into something else, is second nature to them, and I think that if you are going to end up in a situation ‑‑ so, right now, where you have v4 and v6, there is never going to be a smooth transition. They are two different networks. If you want to be connected to the v4 network you need to have v4 addresses, and anything else is a hack and you are relying on state and sensibility somewhere else.
SANDER STEFFANN: You said you were going to say something controversial, I just heard common sense up to now.
REMCO VAN MOOK: You will be shocked how common sense is controversial, these days.
ERIK BAIS: All right. So, okay, on the part for, you know, stretching this thing out as long as we can, on the economic side, v4 space markets pricing, lease options I have heard, people doing call options on IP space, contracts, I have heard, and we have done that as well with our company, buy and lease back options so basically we buy a whole lot of IP space and then leasing out to what the actual requirement is and leasing to other customers what was left, things like that. Can you tell us a bit about that and what do you see with moving forward?
GABE FRIED: So the first thing I ‑‑ before I answer that question, so I think that Sander made the point in discussing translation technologies that like the push is to use your v4 space efficiently, right, because it's scarce, it has a market price now so you either are using it efficiently or you are wasting it, which gets to this ‑‑ to the issue of what is the long tail of the v4 market look like.
So, I don't have a crystal ball. Given the large volume of transaction where the average transaction size is shrinking over time because there are fewer class As to buy and we are going to run out of class Bs at some point and we are starting to see the penetration of registrations for IPv4 address space around the globe get into the hands of smaller and smaller organisations. In terms of what that means on the sort of economic and financial side of the market, so as the price goes up, which it has been going up more or less unabated for the last six years, we start to see more companies looking to engage in some kind of a hedge, so, it could be under the sale lease back arrangement, this idea that I would like to maximise the value that I get for my IP space today and then maybe for tax or budgeting reasons engage in a lease back for the space that I need because I anticipate needing less and less space over time but I don't want to, you know, take my class B and start selling off /20s and class Cs along the way as I go. It's too much of a Spain. We are also seeing (pain) we are seeing demand for leasing, we are seeing companies that have address space that they are currently not using, looking to lease it out because they are not completely sure that they are not going to need it at some point in the future, so there are a lot of entities that we work with who are actively working on v6 deployment, but they actually don't know what that's going to mean for their v4 need going forward. Some of that is holding some back because maybe we want to grow it into a new market and want to acquire somebody who doesn't have their own space or we need to support some kind of integration where when we get inside the office of our new acquired partner, turns out we are all using the same private IP space. So, we need something in reserve. So there are a whole bunch of permutations.
There were a lot of forward looking option contracts that we worked on in the early years of the marketplace before ARIN ran out, in anticipating run‑out. We don't see as many of those now. It's much more of a can I structure my payment over time, or can you lease my space while I still hold on to it? And this is one of the areas in which I think the registries should be aware of the fact that these are happening and should think about how that impacts the way they record responsible party information in their respective databases. I don't have a problem in that regard looking for particular solution but this does sort of change the nature of address utilisation and where you go to look up who the responsible parties are, and I think, in a way, that the doom sayers in various regions who are thinking about their own evolving Address Policy will say this is something that is really horrible that needs to be avoided but I think there are reasonable practical solutions to these problems. But the financing, the biggest, as a final remark, the biggest challenge with financing is that one of the elements that exists in commercial finance is the ability to have a lean against a particular as tote say I am going to lend you 800,000 dollars and my security interest is your class B and if you don't pay it back then I get to take control over it. That opens up a whole legal can of worms which is not supported at the moment in any of the registries as far as I know. But should there be a way of actually getting to the point where you could record lien, that would actually solve lots of these alternate financing arrangements in the marketplace I think on a much cleaner basis.
STEFANIA: You could solve that problem by registering sub allocation assignments in any database when it comes to registration and accuracy and eventually you increase as well the quality of the solution, if you don't want to transfer away space
ERIK BAIS: I will come to you in a second. There is actually in the current policy, the transfer policy, there is the option to do temporary transfers. There is one catch from what I have understood, is that there is a fixed date when it returns and you cannot renew the date to extend the contract. So first it knees to go back and then you can just do ‑‑ redo the same transfer, and it's not ‑‑ I believe you probably know that better than I ‑‑ it is into the very common practice to actually do temporary transfers.
STEFANIA: The average of temporary transfers we receive per year are around three, four, transfers. The biggest number, the highest number was nine transfers, temporary transfers, like three, four years ago, but only that was the biggest number.
ERIK BAIS: Am I correct that the actual end date is a fixed date.
STEFANIA: It's a fixed day. You define the transfer date when you want to return back to free pool.
ERIK BAIS: No, I understand why it's not so commonly used.
STEFANIA: In the transfer agreement you define whether it's temporary or permanent transfer in case of temporary you define the case that it's going to return back to the offering party ‑‑ to the original holder, and yeah, at that moment if the offering party is stale member of the RIPE NCC, for example, since we are talking about that region, we are going to give it back, if they want to submit again a temporary transfer they are more than eligible to do so.
ERIK BAIS: I have a question and let's think about this and after that I will go to Jordi. Would it actually make sense to have an update option in that temporary transfer so that once contracts renewed or, you know, extended, that they can also do that with the temporary transfer? Think about that. Jordi.
JORDI PALET MARTINEZ: Actually, my controversial question is all around this topic. I am not really sure is the same a temporary transfer than a list, it may be a different perspective for everyone, and my question to Gabe is: Do we really have lis support from the policy perspective, not just from this ‑‑
GABE FRIED: Support for leasing. This is outside my technical area of expertise with the way registries are currently dealing with this (lease). You can, through a letter of authorisation, allow someone to use space which is registered in your name and announce it on a different AS, and the big question is, you know, is that sufficient from the perspective of the transacting parties, their own level of comfort, in terms of what their representative rights and obligations are, and what is the role of a registry.
JORDI PALET MARTINEZ: The point here is, there is a difference if you are leasing to your own customer or to someone in another network. That's not a justified, in my opinion, in policies right now.
GABE FRIED: I think the question is whether or not, and maybe ‑‑ I mean, you can ask the question in the following way, which is: If the policies were originally written to support the sub allocations to your own customers, then do they need to be re‑thought to support a broader asortment of reallocation of resources, so not your own customers which would be in a purely, in a financial customer sense, not in a network services company sense.
REMCO VAN MOOK: Back when I wrote the initial transfer policy and hindsight is always 2020 I tried to accommodate for most of the commercial models that I can think of. I had never in my defence, I never thought of taking a loan against a piece of IP address space. Maybe we should have had that discussion 15 years ago. But, the intention of the policy as written and I wasn't even aware that in the implementation side there isn't hard data that can't be changed, and now, I am wishing I dedicated more language to this in the original policy, is the transfer was either permanent or temporary. And I mean, that's roughly as much language as was in the original policy; how that then gets interpreted and whether that needs fixing up in order to get ‑‑ actually, still from a database accuracy perspective, get a better view of what the world actually looks like, might not be a bad idea.
GERT DORING: Gert speaking as long‑term ISP and user of the policy. There has never ban requirement that you have your customers that you lease addresses to are using your network for connectivity. So while most local registries are ISPs that serve their transit customers, the situation has always been more complicated than that. So, the policies I think are perfectly fine for, I have this block of addresses and I have a written contract with a company that wants to use a smaller block out of that, we registered this as a sub allocation or as an assignment in the RIPE database and they can then go out and route it through whoever they want and if the commercial contract expires, I, as the address holder of the super blocks can go to the RIPE database and delete the registration and the ROA, delete the sub certificate for the ROA, whatever and everything is fine, so we don't need a transfer policy, temporary transfers, anything for that, that is just basic sub allocation or assignment. So I think that part is fine as it is.
ERIK BAIS: Michael.
MIKAEL ABRAHAMSSON: I don't think if this is on topic for this Working Group but this whole connection with the routing system so people use these to communicate on the default free zone. Before 20 years ago it was said RIPE doesn't care about routing. Now we are doing RAOs and so on and what is in the database actively in almost realtime influences the behaviour of the routing system. I would like to hear your opinions going forward on where do you think the RIRs are going to be in relationship to the global routing in the next five to ten years, is that a topic for this Working Group or somewhere else? Because you mentioned contracting, this is part of the enforcement of making sure that it was actually ‑‑ is out there in the wild, is ‑‑ has something to do with the database.
ERIK BAIS: So I will leave it up to the panel if they want to answer on it. You are correct that the NCC is not the routing enforcement police. The ROAs are created by the holder of the space, and if they want to, you know, create RAOs or not, or create route objects or not, that's up for them to decide. And how they deal with that in their contracts, if they lease that space, is, you know, one experience might be better than another. So, yes, this will be something that companies that are leasing out space will need to sort out and need to find a process on how to work that. And some will do that better than others.
REMCO VAN MOOK: So my initial response to your question would be to run off stage screaming. There is ‑‑ there is no denying that implementation of RAOs and more recently origin validation using RAOs, especially by Tier1s, has led to the RIRs now being in the ‑ of the global routing table, with all best intentions and great ideas in mind, I don't think the RIRs were designed to be in, yet here we are. I think there's tremendous amount of work that needs to be done by the RIRs and the community to figure out how we are going to deal with this new reality.
MIKAEL ABRAHAMSSON: Because originally, handing out the /27, which was fine from RIPE point of view, was useful in the D and C because you couldn't use that for everything, so the thought process of saying RIPE doesn't do routing, is a point of view that was never true from a practical point of view. And I think that the run‑out here with the increase of cost of space, I don't think we can run away from this question. It needs to be handled somehow.
REMCO VAN MOOK: I don't disagree with you, I think that size of assignments and visibility in the global routing table, there has always been a practical aspect to that. I do want to point this out, and I have been pointing this out for many years, is that global uniqueness is sufficient reason for handing out address space and global routability has never been actually in scope for that. It's always been about global uniqueness and a /27 is perfectly fine with that, as we will be discussing in the text topic actually.
ERIK BAIS: Nice bridge there.
DAVID FARMER: I want to highlight a distinction that Erik be made about what RAOs are. They are not the ‑‑ are not the RIRs saying something. The only thing that RIRs are doing is notarizing the statement that the owner is making.
ERIK BAIS: Yes. It's up to them to decide if they want to create a ROA or not.
DAVID FARMER: And the RIRs are just simply saying, yes, that person is properly authorised to do this and it was a proper statement and blah‑blah‑blah.
STEFANIA: It's actually an extra service we provide our members.
ERIK BAIS: Yes and a very helpful one.
AUDIENCE SPEAKER: I wanted to ask a question about the temporary transfers, the ‑‑ I didn't understand exactly do they fall under the 24 months' restriction or not?
STEFANIA: Yes, in order to transfer space even temporary they should be out of the 24 months of restriction period so if you get it today, if you request ‑‑ well, if you requested yesterday an IPv4 allocation and you got it today, in 24 months you can request either a temporary or permanent transfer at another legal entity.
AUDIENCE SPEAKER: And when I get it back and retransfer it, that's more than 24 months ‑‑
STEFANIA: 24 months will not apply. After it's gone back to the original holder so after the expiration date, lets call it expiration date, then, no, the 24 months will not restart.
AUDIENCE SPEAKER: In my opinion this is not really clearly stated in the current policy.
ERIK BAIS: Let me rephrase that for you. I actually wrote the policy, the transfer policy which is currently in place, and it actually says that it's 24 months after allocation by the ‑‑ so when the RIPE NCC allocates the space to you, the resource, 24 months after that, so if you have a transfer you transfer ‑ dash temporary transfer, you transfer it out to somebody else, and it returns, it is still ‑‑ you know, when did you get the original transfer date. Or the allocation date. So, but it is a bit unclear on where the ‑‑ what the lines are, and from what I understood from the NCC itself was that it's not a re‑set for the 24 months, so it's not that you have to wait 24 months again.
AUDIENCE SPEAKER: Right. Okay. And then on another topic, the assignments, I don't know if it's the correct Working Group, but if I get a transfer of a /22, let's say, and I want to assign the entire /22 to one of my customers I can't do that, I have to split it up into /23s
STEFANIA: It's a RIPE database business rule does not allow you to create an assignment that equals the size of your allocation, what you need to do is answer two /23 assignments.
AUDIENCE SPEAKER: In my opinion in this transfer market it will lead to a huge rise in the database because now bits and pieces are being transferred or allocated, even, right now by RIPE, and you can't assign the whole allocation.
ERIK BAIS: That's something you need to go to database for. Because it's a database business model, it's not an Address Policy thing.
GABE FRIED: Just to make sure that everyone is clear, sub‑assignments can't start until 24 months after you have received the allocation.
ERIK BAIS: Yes, they can.
STEFANIA FOKAEOS: What do you mean by sub‑assignments?
ERIK BAIS: You can start immediately, if you do an assignment ‑‑
GABE FRIED: Only transfers have a two‑year hold?
ERIK BAIS: Yes.
STEFANIA: Correct.
ERIK BAIS: We have ten minutes. Any questions from the audience? Any topics that we missed?
GABE FRIED: So you asked about pricing earlier, which I didn't get to.
ERIK BAIS: Let's do pricing.
GABE FRIED: Is pricing is going up. The big question is, when does it peak, and the answer is, nobody knows. But what we are seeing is the ‑‑ and I think that ‑‑ and I have seen some work by Geoff Huston on this in the past, that of the 4.3 billion IPv4 addresses that, you know, in terms of potential, the number that are ‑‑ the percent that are being announced continues to grow, right, so these allocated and unannounced resources are continually being harvested and then deployed into the ‑‑ through the transfer market to organisations that are actually announcing them. What we are not seeing as a broker is a tremendous amount of renumbering activity to free up IPv4 space to bring it to market. We do see some, but it's not at the level yet where I think we are going to start to see maybe in the long tale a steady state recycling and repurposing of IPv4 space that had been allocated and now being ‑‑ is being renumbered into more efficient use because the values are so high and remainder is being returned to the market. I think that sort of the next phase. My guess is 20 or 25 dollars in address is not motivation enough for large organisations to take a /16 and, you know, reduce their actual consumption down to something closer to a/, you know, 18 or 19 and free up the rest. So I think there is some ‑‑ there is some headroom in pricing still to go.
ERIK BAIS: You said about, between 20 and €25 dollars current pricing which is what we see in the market. What ‑‑ I have asked customers, you know, so are you actually charging out as, you know, to your end customers, access providers, connectivity providers, are you actually for IP space? So, I have heard customers saying, yes, we are, and then if I can ask, so how much do you charge your customers for the IP space per month and they say, oh, we are actually a bit expensive, some say we have two or two, three, US dollars and I have actually heard one last month that said yeah, we charge about €6 per IP per month and for typical usage they need a 29, per month. So, if we take that economic and then take ‑‑ so let's see, for a 12‑month contract, €6 per IP per month times 12, there is some headroom in the pricing, if I see this, and still have a business case.
GABE FRIED: There is a tremendous amount.
ERIK BAIS: And it still doesn't hurt.
GABE FRIED: So what this gets ‑‑ this goes back to the issue of the growth in the number of members in the various RIRs. So ‑‑ if you are an organisation that has a you know, a monthly, let's call it connectivity services bill of 3, 4 or €5,000 a month and this allocation of that bill for you renting of the IP space is fairly small because you are buying lot of bandwidth and power consumption and whatever it is else that you are buying, this doesn't move your needle and the person who is paying the bill or the person who is handling the contract likely has no awareness of the fact that they can buy themselves out of that obligation by coming to us or another broker and getting a /24. So, there is an awareness in the ‑‑ there is a lack of awareness in the ‑‑ across the globe about this option, and so, it means that the price is not high enough to sort of cause people to wake up and say do something. It doesn't hurt much. When we moved offices several years ago we were quoted a price of 15 dollars month for a dedicated IP address I mean, it was insane. But we had ‑‑ part of that is the lack of competition in the marketplace for connectivity services and that creates huge market.
SANDER STEFFANN: It's actually interesting, so on the more positive note, Pete Stevens does IPv6 only hosting and charges extra for the v4 address, and he actually had ‑‑ because he explicitly puts it as item on the bill, he had accounting departments going back to their IT department going, why are we paying for this IPv4 thing, can we remove that? So putting it on the bill does create some intensive to let go of IPv4.
STEFANIA: Yesterday I hear funny story, for me it was funny because eventually holder of IPv4 PI space asked for IPv6 prefix for connectivity and the price that the ISP wanted to charge was €10, so it was per month. Per prefix, yes. So it was like seriously, why? It's not PI, it's nothing, it's part of your allocation so it was quite weird.
REMCO VAN MOOK: I think there is a very easy answer to that. I mean, this is ‑‑ the example that Gabe just gave and you just gave, that has absolutely nothing to do with the IP market, that is just extracting rent from running a monopoly and nothing else.
ERIK BAIS: Well put, well put. Last question. Or two questions.
JORDI PALET MARTINEZ: Okay. Going back to the controversy, I think I disagreed with Gert regarding that sub allocations are not for downstream.customers because in RIPE 730, which is our IPv4 policy, mentions things like sub allocation to multiple downstream network operators or, for example, sub allocations from part of LIRs ‑ address space such an LIR might want to ensure address space is not retained by a downstream network. So always he is talking about downstream.
ERIK BAIS: Let's take that up in open policy hour.
GERT DORING: As addresses trickle, not in correctivity ‑‑
JORDI PALET MARTINEZ: In the next sentence talks about if not longer connected.
AUDIENCE SPEAKER: Sandra Browne IPv4 market group. I wanted to comment on the pricing aspect just because we have had some interesting observations so ‑‑ I am talking generally here, we have been at approximately 20 dollars an IP for several mid‑size allocations, so I am talking about /22s to, say, /17s, so we hit that price in March and we are still roughly at that price. So, my observation would be that, yes, prices increased stead three march but we have seen some flattening in the market so whether 20 is some kind of psych almost threshold or budget reap threshold, maybe just in this year, I don't know, but I am going to be interested to see once companies gets their new buckets when weather prices start to go up again so we deftly hit a plateau. I would like to thank the panelists, thank you very much for insight and we will do a short proposal from Remco, so you can stay on the stage.
(Applause)
ERIK BAIS: As the other policy was Remco was approved, there was some discussion about the actual assignment size the initial assignment size for the IXPs, why should it be a 24 and in order to get the other policy through, Remco decided, well, I will offer to do the new wording in ‑‑ and we have all the time after we basically have the 16 available in the pool because we didn't want it to lose out on us. So, that having said...
REMCO VAN MOOK: So, as Erik said, for my sins ‑‑ I haven't even started yet, why are you at the microphone? So for my sins and this is my sin, in trying to get the previous policy proposal through, which was to expand the pool size for IXP allocations, some discussion came up about, well, that's all very nice there is a default allocation or assignment size for IXPs of a 24 but shouldn't that change? Which was actually sort of out of scope of what we were trying to do but in order address that, say, well, if we get this through, you know what, I will personally commit to writing a policy proposal to discuss this. So, this is what I said in early September and then last week Marco sent around this e‑mail. So, that was me done for. And here I am.
Really, really short. I mean, the policy proposal itself is fairly minimal, it changes only one bullet‑point of, I think, paragraph 6.4 of the RIPE 730 document that Jordi just mentioned, where, right now, the policy reads that you get a 24 and if you want larger, you can get up to a 21. The proposal is now to say, okay, let's go back to the olden days of needs based allocation for IXPs, and say okay, we are going to start at the 27 because less than that is actually not practical to be used by any size of IX and if you want anything larger than that it's going to be needed based with a two‑year window. Arguments in favour, this could drastically reduce the consumption rate of the IXP pool, because all of a sudden you are only using like one‑eighth of your allocations at a time. And research done by somebody who works for DE‑CIX actually points out more than 50% of the IXPs would never need more than /27 anyway; here is the graph that came out of that. So, from a purely IXP perspective, there shouldn't be anything wrong with this. There is also some arguments against that these blocks still live on the Internet even though they shouldn't be in the global routing table. But getting something smaller than a 24 is likely to be filtered, including all well known communities such as no export, which brings a whole bunch of risks in terms of leaks and black holes within IXP networks to get access to that internet exchange.
I'd like to very ‑‑ I have to stress that I don't have much of an opinion either way, I just committed to writing this down as a policy proposal, so we can have a discussion in the community. And with that, I would like to open it for suggestions.
WOLFGANG TREMMEL: Can you put up the slide again on the policy. This one. That looks fine. I only have a bit of an issue with the wording here, how it is formulated and it says: "If you get anything larger than a /24 you have to return something ,"but initially you don't have anything, what should you rush if you initially can prove you need a/26 or/25?
REMCO VAN MOOK: I might be a little bit thick but I don't ‑‑ I don't get your problem. What's the problem you have with the text?
WOLFGANG TREMMEL: "If an IXP requires a larger assignment they must return their current assignment if they have one or existing PI space used as IXP peering LAN." If they don't have one?
REMCO VAN MOOK: They don't return it because you can't return something you don't have.
WOLFGANG TREMMEL: If they have something at another exchange do they have to return it?
REMCO VAN MOOK: That's a different exchange, right. And these are assignments on a per IXP basis not per organisation that happens to run internet exchanges basically.
GERT DORING: But still that one might, if we do a Version 2 of that proposal it might get some clarification?
REMCO VAN MOOK: Sure
NICK HILLIARD: INEX. Once we were very small and when we started out we had a /27, and then we grew and we had a /26 and then we got a bit bigger and then we had a /25 and now we will a little bit bigger and have a /23 on our primary peering LAN, and each time there has been renumbering it has been a gigantic headache, a monumental headache; it has been a real pain to renumber an IXP ‑‑ and I say this because I have done this four times at this stage on one of our particular LANs. There is no particular reason at this point to think that having an assignment size of less than a /24 is going to make the remaining pool of /15 last very ‑‑ last much longer. If you look at the numbers, the RIPE NCC service region is, what, 73 countriesish. There are a couple of 100 IXPs in that region. If you have a /24 that is 512 assignments. If we hand out /24s per IXP that is okay and that is going to last us, as far as I can tell, indefinitely. And given the amount of headache and hassle and grief that it causes, not just IXPs but also all of the organisations connected to IXPs, which is to say most of the carriers in ISPs and content service providers in this room and elsewhere, there isn't a compelling reason to actually drop the minimum assignment size to a /27 and I would like to suggest that we actually just drop this proposal. It doesn't fix anything.
REMCO VAN MOOK: Thank you very much for that feedback, Nick.
ERIK BAIS: Nick, can you also make sure you post this on the mailing list. Yes. Thank you.
Freddie: I have done a number of renumberings in my career. It's always a pain. And if this proposal would go through, at least with ‑‑ I suggest that the remaining /24 of the 27, which is assigned to new IXP, must be reserved for that particular IXP unless there is the /15 is used up. So, at least that there is no renumbering from the /27 up to the ‑‑ to a /24 and only the subnet mask should be adjusted because when you renumber, and I have done that, as I said, several times, you always lose a bunch of peers, which is a pain, which is sad, but in general, I support what Nick said.
ERIK BAIS: Thank you.
REMCO VAN MOOK: Thanks for that. Since we are going back to the olden days of needs‑based allocation here, you might remember a thing called sparse allocation where, instead of sequentially handing out blocks, you hand them out in such a way that there is maximum growth potential around those blocks for people who get them, that's ‑‑ I didn't write that down in this policy because I was assuming that is an automatic because that's the way RIPE NCC was doing needs based allocation when that was still a thing.
GERT DORING: So three last comments, the light is already yellow and we do not want to keep you from coffee.
Chris wood field: So, in the ‑‑ in the ARIN region, one of the proposals that fell out of the waiting list controversy that came up earlier this year was that ‑‑ is that reclaimed address space would be put into the IPv6 transition pool instead of being allocated out by ‑‑ via the waiting list. That was seen as impractical simply because the rate of addresses coming ‑‑ being far outweighed ‑‑ in the RIPE region, I am wondering if that rate ‑‑ if there might be a better matched rate of reclaim of space that RIPE reclaims and the rate of consumption of space by the IXP pool, and if that's the case, food for thought, that might be a mechanism by which there may not be a need to dramatically reduce the size of IXP allocations.
REMCO VAN MOOK: That's much appreciated. At the same time, the IXP just got their hands on a freshly minted /16 so there is no immediate issue there. On top of that, I mean, and I am looking at trying to come up with the actual numbers, if you look at the rate of return of address space to the RIPE NCC that's ‑‑ that's ‑‑ something along the lines of a thousand /24s a year. The IXP was would most gratefully accept 1,000 a year but I think that's a little bit excessive.
ERIK BAIS: Very short. We are already over time.
MIKAEL ABRAHAMSSON: I agree with Nick, if we are going to be needs based there should be a tiered approach when you bump up so you are very unlikely going to have to renumber again.
JORDI PALET MARTINEZ: Yes, I also agree with Nick, and I think I have an solution, is instead of two year window, mid‑base, maybe four years, that could be be in the middle solution instead of dropping the policy.
REMCO VAN MOOK: I will comment on that very shortly. Having a two‑year prediction is already a bit of pulp fiction, making that four years is not going to make it any better.
GERT DORING: So let's wrap this up. Good feedback from the room. As always, please send the feedback to the list, so it's official. To Remco, if you could use the next time slot to tell the IXP people that there is something they might be interested in commenting on, might be a good exercise, and otherwise, thanks for taking up this and, yeah, well, thank you.
(Applause)
ERIK BAIS: Before we go for coffee, I would like to get some feedback from the people in the room that can be over e‑mail or while we are having coffee, on how you thought about the panel this time, we would like to see some feedback on that, thanks. And go for coffee.
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
