Archives

Address Policy Working Group
25 May 2016
11 a.m.

GERT DOERING: Welcome back. We are still the Address Policy Working Group. If you want to, as Remco so nicely said, hide behind your lap cop in the connect Working Group, it's in the other room.

First thing now on the agenda is a talk about market concentration in the transfers of IPv4 space, which is presented by Alan end user and. It's a joint work with Gabe freed, but Gabe couldn't be here. And a bit of a background, Alan is working for ICANN research, that's the people that think about numbers, and he found this interesting so he brought up the topic and welcome.

ALAIN DURAND: Good morning. I hope you can hear me okay. So, I work for ICANN, I work in the office of the CTO, so that's a part of the organisation for which IP is not intellectual property, and we do research. The one thing we do not do is policy. So we're not going to go there by any stretch of the manges, but we like to look at publish statistics and look at them and see if there is anything of interest.

So, one of the many things we looked at was statistics on transfers as I remembers, so we looked at the period from 2014 to 2015 and it's ARIN, APNIC and RIPE, in that period LACNIC did not have yet transfer policy, at least not one in AfriNIC. So that's what we're going to look at.

So, when we went into this, we had a couple of questions. We wanted to look at health, whatever health means, of this market, and trying to see where there is a concentration on this market, meaning is this dominated by a few players? And if that is the case do we see a shift in the industry of what type of organisations those players are. We wanted to see if there was some regional differences, that would be rough noting and direction in the transfers, what are the size of the transfers that we are seeing most commonly and how things are evolving.

There have been a number of discussions in many other places about routing table size and the question was: Is there an impact on transfers, of transfers on the routing table size, or potential impact? And some discussions with the accuracy of this entire thing? As somebody pointed out in the previous session, accuracy of statistics is a really important topic.

The first couple of slides are looking at the global picture, the entire address space as distributed by the five RIRs and trying to see for each registry the top ten players, how much of a total address space are all in together. If we look at for example, the ARIN region, there's a total of 1.7 billion addresses allocated by the ARIN region as of January of this year, and the top ten players, the largest organisation by organisation ID, control about 32% of those resources. Now, there is a little caveat here. This is done by organisation ID. I know that some companies have multiple organisation IDs, and I don't necessarily catch this here so the numbers may be actually a little different. If we look at companies and not organisation ID.

In the APNIC region there is a somewhat similar story. 800 million IP addresses total in the region, 863 million to be more specific, and the top ten is about also 32%.

In the RIPE recently, also 8 hundred million addresses, the top ten is about 20%, so there is more distribution there.

Let's compare that with the other RIRs. So in LACNIC, the 180 million addresses. Top ten is about 44%. AfriNIC, similar picture, 87 million addresses, the top ten is about 44%.

So, it's clear that we don't have one player in any of threes layses that control everything, or a small set of players that control everything.

Now let's look not at the global picture but only at the transfers. So, again, I looked at ARIN, APNIC and RIPE. And in the ARIN region, ARIN reports on transfers as of today, only showing the blocks and the date. So, I can tabulate all of this and have a total number of IP addresses that I transferred by simply looking at this I have no idea about who transferred to whom, I cannot try to assess how many organisation levels resources, or transfers, and what is a percentage of the top ten.

In APNIC, they publish more complete statistics, and the total is about 10 million. The total in ARIN was about 39 million. And the top ten in the APNIC region was about 60%.

In the RIPE region, they also do not publish fully the statistics because they don't publish statistics related to transfer of legacy resources. It skewed the picture, I don't know how much, but it does skew it. The total registered transfers was 18 million addresses and the top ten was about 40%.

So I tried to dig a little further, and go through the extended delegated files from ARIN and try to see day after day what was changing and try to reconstruct the picture about who was transferring what for. So it's a bit of a difficult exercise because there are false positives, for example, an organisation with two org ID would transfer things from one place to another, it's an internal therefore, it should not really count as a transfer. And I found a case of a very well known company that had 4 million IP addresses that were moved from one account to another account, and out of 38 million that's 10%, and that's skewed my numbers. So, I did a little bit of social engineering, talking to people, trying to figure out what was what, and after validating the numbers, essentially we look at the top 10 of the transferees, the organisations who received the addresses, counting for about 83% of a total amount of transfer within the ARIN region.

I have not reversed engineer the same way to try to figure out the legacy transfer within the RIPE region, it's an even more complex thing to do, I might want to do that at a later stage.

So in region versus out of region: The size of the diagram are not exactly proportional but just to give an idea. ARIN, again, 39 million, APNIC 10, RIPE 18. What's interesting is to see that in the RIPE region, the transfer, the Inter‑RIR transfer started only in November, November 23rd, and in the space of about a month, seven days, you have about 2 million addresses, 2.2 million addresses that moves from ARIN to RIPE.

In APNIC, the transfers had been starting much earlier and there was a total of 4.6 million.

Reverse transfers, there was some from APNIC to ARIN, but none from RIPE to ARIN. And during that period, I didn't see any recorded transfer in between APNIC and RIPE.

What was interesting to me about the data published by APNIC is that there was a date of the origin of a previous allocation of the same block, so I could go back in history and try to look at all the data, all the addresses that were coming from ARIN to APNIC and see how old these addresses were.

So in this diagram, the green ones are addresses that were allocated before the existence of ARIN, but were still all in the ARIN region, but allocated prior to the creation of ARIN, they were about 79% of them. So these are legacy blocks. In red those were addresses that were allocated under the ARIN region, so starting 1998 to about now, and 17% of them. So, sometimes people tell me oh we transfer only legacy or transfers are something, it's actually a number that shows, the majority is legacy but the rest of the portion of it was legacy. 17%.

Also another 4%, which was somewhat interesting, is addresses that have been actually transferred as legacy from one participant to another participant within the ARIN region and then transferred back to the APNIC region. And it was actually a large company, a multinational based in the US, that acquired a number of resources and then transferred some of them to one of the subsidiary in Singapore.

I was trying to look here if addresses were being somehow flipped, some are transferred once, twice and then a third time. It doesn't really seem to be the case, except for this case, a specific example I gave, about the blues ones in here.

So this is the size of the blocks being transferred. So the average size of it. So in grey you will see ARIN. In orange you will see APNIC and in blue you will see RIPE. So it seems clear in the ARIN region we see larger blocks being transferred. In the RIPE region we see smaller blocks being transferred.

This is simply the number of addresses of over time. This is one of those stupid graphs to the right. It's not really interesting here.

What's more interesting is this. I looked at the growth of the table of statistics published by three RIRs, those three RIRs on a daily basis, so this was a delegated extended files for each of the three RIRs. And what we see is total over the last four years that increase the number of lines in the database, increased by 40%. So, what was the relationship between that and the routing table size?

Well, the total number of entries in the delegated file is about 150,000. The total number of routing entries in the global routing table is 600,000. So four times bigger. Why? Well maybe there's traffic engineering, peering policy, more specifics and all of that. But essentially, there seems to be a between the size of the delegated extended file and the size of the routing table size. Not that the delegated extended file that removed anything that was IPv6, anything that was just reserved and just talk about stuff that was allocated. So if we see a growth of 40% over the last four years here, in this table, that probably indicate also a growth on the routing table. And when we see transfers coming from large blocks being chopped off into smaller blocks, that's another party of deaggregation that is going to be reflected into the routing table. So next step for me is going to track more the effect of this deaggregation on the RIR tables and see there's an actual match in the routing table. So that's for future work.

Now, what's interesting is to look at the contribution of each of the RIR to this deaggregation, or at least to the augmentation of the size of the delegated extended table. So I have two graphs here. One is relate relative contribution and one which is the absolute because some registries are much larger than others because it's important to look it it in terms absolute terms. What was interesting to me was to see that that picture changed year after year. I'm not exactly sure as of why it changed, and maybe it has to do with the time of a runout in each actual registries or some of the policies put in place, but it was not a constant picture.

So, this slide is a part where Gabe was supposed to bring some of his own statistics of running an address block, sore if there's any address blockers in the room I would very much like invite them to participate here.

What we see here are data as reported by the registries on transfer. Transfers happen according to the policies by the RIR and if there is inbeats policy that have been put in place to respond to the demand from the different communities, it was important, and those policies have an impact on the size of a block that is being transferred, because cannot transfer a large block, you have to transfer only what is considered as a need. There are some parties who don't necessarily like that and have gone into private contracts where they are not transferred, they are private contracts. Sometimes they take the shape of letters of authorisation, sometimes they take the shapes of options. There are connected to evidences on the size of those, the market of private contract compared to the size of your actual transfer. But the evidence is not backed by any numbers but are published simply because they say contracts are not recorded publicly. First it's impossible to actually go and really measure them and report about them. So cannot evaluate with any concentration of those transfers or even the size of those transfers ‑‑ I should not call them it was ‑‑ the size of those contracts in this derivative market.

And to finish with the presentation is a note about collecting statistics. The three RIR, ARIN, RIPE and APNIC, who have been reported on statistics on transfers, report different things. And this is a table here which summarises whats about been reported by each of the RIRs. The fact it's not the same data, it's more or less data in some places, does not make this analysis very easy. The good news is I have talked to a number of staff in those different regions and we have come together to try to harmonise this, so I'm really looking forward to have more data to do some further analysis on this.

And I think that's the last slide in my talk.

SANDER STEFFANN: I don't know who was first?

AUDIENCE SPEAKER: Alan, if you could go back to your third slide ‑‑ Sandra Brown, IPv4 market group ‑‑ it's the one with the allocation of the top ten. So, what you're showing on this slide, if I'm correct, is that the top ten transfers in ARIN and APNIC represent 32% of the market but in RIPE region only 20% of the market.

ALAIN DURAND: That's not correct. This is the totalcation done in that region. The one about the transfer per se is actually this one here.

SANDRA BROWN: Does this show that in the RIPE region where there's no needs justification, that the percentage transfer to the top ten is less concentrated than in the regions where there is needs justification?

ALAIN DURAND: First off my understanding is there is a needs‑based justification in the RIPE region.

SANDRA BROWN: Not for internal transfers.

ALAIN DURAND: Well I will let the people from RIPE comment on that one. The second one is this data shows the recorded transfers as reported by the RIPE RIR.

AUDIENCE SPEAKER: Andrea Cima, I confirm there is no needs justification needed in the RIPE region for transfers. We're talking within the region.

SANDRA BROWN: So what I want to know is where there is no needs justification, is the transfer outcome less concentrated because if that is true, what it indicates to me is that needs justification in the other two regions is not having the result of preventing hoarding, the hoarding is more concentrated in the top ten in the regions that do have needs justification, according to your data. Do you see that.

ALAIN DURAND: I present the data. We're not going to draw any conclusion, the objective of this is to bring the data to the different bodies so that different ‑‑ policy setting bodies so they can use the data to draw their own conclusion.

SANDRA BROWN: I understand that. But I am wondering do you see that conclusion because that's what I'm seeing. I don't have an opinion on needs justification at this time, but I'm seeing that conclusion from your data.

ALAIN DURAND: I cannot comment.

RANDY BUSH: Could you go back two slides? One of the conclusions you didn't draw was you showed this slide of the top ten holders, and you said that this showed that no one holder... I don't see that.

ALAIN DURAND: I'm sorry, Randy, I'm not following.

RANDY BUSH: You showed that the share of the address space by the top ten holders was this. And then the conclusion, and you don't draw any conclusions, was that no one holder held an unusual amount. And how did you reach that non conclusion?

ALAIN DURAND: I guess I didn't reach a conclusion.

RANDY BUSH: I am wearing sandals, please have some mercy.

ALAIN DURAND: Next question...

AUDIENCE SPEAKER: This is a question really towards the RIPE NCC. I think if you go forward two slides please, you mention that RIPE NCC doesn't report on legacy transfers. I am wondering, what the obstacle or perceived obstacle to reporting might be.

GERT DOERING: I think we never asked.

AUDIENCE SPEAKER: Andrea Cima, Gert gave the answer, they never asked. First of all it's not in the legacy policy. And the fact is that the RIPE NCC is not involved, is not part of the process when a transfer happens between a legacy holder and another organisation. Legacy holders they can update the object in the database to reflect, for example, a new holder or any other organisation. And without informing the RIPE NCC. As we are not part of this process, it's also very difficult or would be impossible to, at the moment, to get our statistics about this.

SANDER STEFFANN: I see somebody shaking his finger at the back microphone.

AUDIENCE SPEAKER: Erik Bais. I am sorry I'm skipping line here, I want to make a remark on Andrea. The RIPE NCC is actually involved in legacy transfers because we are actually required for every transfer in order to update the RIPE registry, that is the back end database of the database, the internal database for RIPE, to fill out a contract that is not a contract, but it's a transfer agreement, sort of, between the old legacy holder and the new legacy holder, so you are aware, by paperwork, what the actual transfer is because the legacy space holder cannot delete the top level INETNUM because cannot split it up as a legacy space holder, so, in order to be able to do that, we need to file a ticket, and every transfer is, by that definition, known to the NCC. So the question now is: Why can you not do this, basis with this information.

ANDREA CIMA: You are partially correct in the sense that for some legacy transfers we are involved that there is a change of resource holder. This is when the organisations contact us, they want the RIPE NCC to update their internal files, as the holder of the legacy resources, in this case we are contacted and we update our internal files. But this is not always the case because as mentioned before if you just want to change the registration data within an INETNUM object, the legacy holder can do this themselves without the need to contact the RIPE NCC, so I agree Erik with you that we have part of the data, part of the information, even though we don't really know what is happening between those two parties in the sense that we know there is a change happening and we are registering this change. Yes, you are right in the sense that we have a part of the data.

SANDER STEFFANN: So basically, it matters if the whole block is transferred, they can just update information. If the block is split up, you need some paperwork. Okay.

ERIK BAIS: Even for the actual update of the internal registry, you need to provide documentation to the RIPE in order to provide chain of custody. If somebody wants to move that it's their block they need to update their info to RIPE. So from that perspective, yeah, RIPE is involved and RIPE knows.

ANDREA CIMA: Yes, but not everyone does that and there is no obligation towards the legacy holder to contact the RIPE NCC and to inform the RIPE NCC about it.

AUDIENCE SPEAKER: I'm Carlos Martinez, I am from LACNIC representing the engineering cord nation group for the RIRs. Can you please go back to your last slide. We are in the process of actually understanding how the transfers will be reported and in terms which fields each RIR will be publishing, there are some policy restrictions that are different in every RIR, so not all transfers will have the same fields but there will be a common core of fields that will, in my opinion, make in the future, this information much easier to be analysed. It's worth bearing in mind that these transfers are relatively new so this was going to be expected, and for example, although LACNIC is not included there and we don't have a policy for Inter‑RIR transfers, we do have a policy for intraregional transfers and we plan to use the same format and the same field, so, hopefully this will make this information much more analysis friendly. Thank you.

ALAIN DURAND: Thank you very much. Thinking that you guys can do to increase the transparency to this would be greatly appreciated by all of us that are looking at the data.

AUDIENCE SPEAKER: Geoff Huston, APNIC. I think the shoe should be on the other foot. This policy community has the responsibility and onus to give directions to the secretary it's an and registry operators as to how to operate this registry. And to (secretariats) and to make good policy you need good information, which means your registry has to deliver you not just who has what, but how things are changing. The why, is up to the players. But what happened and is happening is important. So, looking back at the engineering group going you give us the answer is kind of backwards to me. I would actually like these communities to say we would like to see transfers recorded. We would like to understand what happened and with whom. We would like to understand that if an address bounces across five different entities in three days, that registries show that. So, you tell us, and we'll all be a lot happier here because having us at the back end engine trying to invent what we think you need is never going to get it right and you get this kind of partial coverage. At APNIC we have tried hard to actually record as much as we can as it happened. Because our registry is a snapshot and this is, if you will, a trust anchors log of the individual events that built today's snapshot and I in encourage you to look at that and look at what the RIPE NCC is recording, what look at what makes is helpful to you to have this kind of analysis performed as a regular way of inputting into your policy process, so that you end up creating and maintaining policies that are relevant to you and your needs, rather than just relevant to the secretariats. So, I like what you have done Alan, that table is very informative, but I encourage all of you to think about this and think about what data we should be providing to you to help you do your job better. Thank you.

SANDER STEFFANN: Thanks. I saw Randy ‑‑

RANDY BUSH: Just a quick one. Geoff, in this region, there's a separation between Address Policy and NCC Services.

GEOFF HUSTON: It's a subtle distinction. But good policy needs this data so somehow we cross the bridges between RIPE and the NCC etc. If you want the data to help you do your policy I think you have got to say so clearly.

GERT DOERING: Looking at this table it seems that this region isn't doing so badly.

GEOFF HUSTON: I have had to work through your data. It's okay. The dates are a problem. The Jason format is a bit interesting. The country work is kind of a bit dull and sort of hard to extract. I would encourage you to fill in those fields and see if you could fill in more.

ALAIN DURAND: Specifically I would like to draw your attention to the previous registration date. This is something that's really useful, and the graph that ‑‑ this graph here, where we can go back and see how the old addresses before being transferred.

AUDIENCE SPEAKER: I have been standing here for about ten minutes.

SANDER STEFFANN: My apologies.

AUDIENCE SPEAKER: There is another side of the room over here. This is Milton Mueller, I am at ARIN, I am a professor at Georgia tech and I have done several studies of v4 transfer markets several years before it was fashionable. I'm trying to get a better sense of what you are trying to measure, Alan, and maybe we can take some of the details off line, but when you talk about concentration, you are spanning.......you are taking an economic concept and you are doing a lot of technical measurements and I'm not sure you are actually identifying what concentration means and what its relevance is. So, your pie charts are showing the top ten recipients of transfers, right, so you're not measuring market concentration and you're not measuring actual holdings of the overall address space, this is just the transferred space and you want to see how those are distributed across the actual recipients that can be documented, is that correct?

ALAIN DURAND: That is correct.

AUDIENCE SPEAKER: And why do you think that particular measurement is relevant?

ALAIN DURAND: So, here only shows from a sanitised version of the graph without the names of the people participating in it. In a further study, I was looking at what type of entities are receiving addresses for transfer as opposed to entities receiving addresses via the previous regime of of allocation by the RIR. And there seemed to be an interesting shift where addresses used to go to large service provider and now they seem to go to large Cloud provider. So that was an interesting shift that we observed. Now, we'll be very much willing to work with you to look more at the economic aspect of this and try to refine the study to look at really more the market and the active concentration of things and any further work that could be derived from this.

AUDIENCE SPEAKER: The other missing piece of data here in addition to the legacy in the RIPE is of course the price, which is a rather significant factor in terms of what these transactions are going for, and when ‑‑ I actually proposed that RIPE start documenting the transfers several years ago. Everybody informed me that the price could not be included as a data point.

ALAIN DURAND: You are correct. Price is one of the things that is missing. The other part that is missing is all the private contracts that are happening as options, and this is a bit of a ‑‑ well we have no idea how to size this option derivative market.

ELVIS VELEA: Could you do to slide A 3. Now, I see you did this for ARIN. Why ‑‑ I mean, I have got a question. Could you do this also for APNIC? Especially because they do provide older data from the last ‑‑

ALAIN DURAND: This is for addresses that were transferred from ARIN to APNIC, and I was able to do that because APNIC reports on the previous registration date. That's the only place where I have a full information to do that. I would be very happy to do that for everything both Inter‑RIR and intraRIR transfer but I just don't have the data.

ELVIS VELEA: Oh you don't have the data of the old registration from ARIN.

ALAIN DURAND: Not just from ARIN, from RIPE or ‑‑

ELVIS VELEA: Okay. Now, the second question is, and I'm following up on what Geoff said. Is, what should we do to require or ask nicely, if possible, all the RIRs to fill in all the missing dots on the last chart?

GERT DOERING: This one is actually on me I think. I'm going to nicely ask the NCC people, I don't think we are leaking anything if we add these fields because it's in the stats files already, it's just more painful to take the JSON, go back to the stats files from ten years ago and figure out what allocations. So, do you think there would be a problem, or would it be possible to add country of original nation and destination and previous registration date?

ANDREA CIMA: Two things. First one, Alan, when you mentioned there was no original date of the original block available. We have this data, and it's in the extended delegated stats file so it's not in the specific transfers statistics, but it is available on our website.

GERT DOERING: But going to the stats files is cumbersome.

ANDREA CIMA: I understand. And the point that we list in our statistics at the moment are the ones that are listed in policy. Policy requires us to publish this. Of course policy doesn't say that cannot add data to this. As you were just mentioning. And I think that Carlos from LACNIC answered this like a few minutes ago by saying that the RIRs are working together to harmonise a little bit of statistics that they provide, and by harmonising this it means that we will look at the set of data that is available and see how we can make sure that all the RIRs provide very similar or the same type of data. I hope this answers your question.

GERT DOERING: I think you have heard the request from the room and we have our answer. Thank you.

SANDER STEFFANN: If there's anything that you think would require a policy change, either from us or from NCC Services, please bring it forward if you run into it.

AUDIENCE SPEAKER: Thank you very much Mr. Chairman. Just I wanted to say that although we are working hard on harmonising how this is going to be published, I word of question for all analysts out there is you need to be prepared to take into account some policy differences between the regions because that's actually to be expected. Thanks.

ALAIN DURAND: Thank you very much.

GERT DOERING: Alan, thank you for bringing this up. Thank you for bringing this up and giving us something to think about and digest. That you know for your input. It was more input than I expected, so we need to be a bit more quick on the next one. This is the traditional feedback from the NCC registration services department, which we always do, because whatever policy we do, they get to see the results, whether it's working or not, whether it makes life hard with members.

ANDREA CIMA: Good morning everyone, I am part of the registration services team at the RIPE NCC.

As Gert just introduced, what is the aim of this update? The aim of this update is to report back to you. This report back to you the feedback that we receive from many of you from our LIRs during our daily jobs. The feedback that we received, but also the concerns that we receive by them. Also, we may spot some potential problems regarding policy and we want to bring those back to you as well. So, we want to provide some input for your discussions, but also to ask for some feedback on how to process, on how to proceed in certain matters.

Now, we have five agenda points for today. But, I will start with maybe what is the most complex one. And this is comes from an action point from the last RIPE meeting and mainly handling allocated PI and allocated unspecified. Now just to do a brief introduction what we're talking about here.

You know that the RIPE NCC has some allocated PI blocks. From those allocations, the RIPE NCC makes some provider independent assignment, or made in the past, some provider independent assignments to end users, now those end users would be able to keep those resources with them when they were changing upstream provider or when they were changing sponsoring LIR. Those end users would enter into a contractual agreement either with the RIPE NCC or with the sponsoring LIR, and the address space would be returned to the RIPE NCC when they were registered.

Until here everything is clear and straightforward. But over time, there have been some other blocks with statuses that are causing issues nowadays. So, there are LIRs who have allocated unspecified blocks or allocated PI themselves. They issue address space to end users. This address space often has a status of assigned PI. Meaning, that we would expect these end users to be able to bring those addresses to the sponsoring LIR they wish, but often this is not the case. So, what we have is that the LIR often remains in control of the address space. They have their maintainer on the PI assignment. So it's not really provider independent in the end. For the more, there is no contractual ‑‑ no contract in place according to RIPE policy, and we do not really know what contractual basis there is between the LIR and the end user.

We have also noticed that new PI assignments are being made from those allocations even though the policy does not provision any more for making new PI assignments. And often, there is a problem with the data quality in the registry in the sense that many of those old PI assignments are abandoned in the database, and nobody really knows if someone is still using them.

So, we were asked to provide a small timeline. Now, we could talk about this thing for a whole day, and I will maybe over simplify a little bit of history, but please approach me after this session if you want some more details and I see also there are a number of people in this room who were part of those events and they will have much better knowledge than I have.

Just to tell awe bit about how did we come to the situation. In 1992 it was defined how the RIPE NCC would define address space. Now the request for resourceses was sent to the RIPE NCC who would evaluate and would then either issue the address space directly or give a mandate to a last resort registry to issue the address space on the RIPE NCC's behalf the in 1994, the last resort registries and LIRs were defined and it was defined that if an organisation had already an option provider and wanted to connect their network to the Internet, they should ask for address space from their local Internet registry, which would be their up a stream provider. If they were not going to connect their network to the Internet or if they had not chosen an upstream provider yet, they could request resources from the last resort registries. In the same year allocation and assignment were defined, meaning that there was a hierarchy set in place which would show that the allocation block was belonging to the local Internet registry, and the assignment to the end user.

Now, a year later in 1995, more statuses were defined such as the allocated PI, and the assigned PI because there were organisations that were in need of having some independent resources from their LIR. So, still in knife, other contributors meeting it was decided that the last resort registries could either become a local Internet registry and contribute to the need for the RIPE NCC, or they could transfer their resources to an existing local Internet registry.

Many of last resort registries also handed over the address space to the RIPE NCC for the administration.

Now, also last point, from 1996 until 2003, the RIPE NCC should some allocated PI blocks to a number of LIRs. Those were LIRs who were requesting a lot of PI assignments on behalf of their customers, and in order to stream line the the process, the RIPE NCC gave them blocks for making those assignments.

Now, what are the numbers that we are talking about here? We see here 30 LIRs, 38 hires, 95 allocations, the issue doesn't seem to be so big. If we dig a bit deeper we see if we ignore the assigned PA blocks, which are not an issue, we can still see that we have about 4,000 organisations, or 4,000 PI assignments here which are impacted. So, 4,000 potential organisations are impacted by the fact that we have those ‑‑ this situation in place.

Now from the last RIPE meeting, the RIPE NCC gave the mandate to bring those people, those LIRs into a room and try to figure a bit out what are the feelings about this, how do they look at this. Now we contacted all those LIRs, and I want to thank them for their availability. We managed to speak with some of them via e‑mail, some via phone, we have met about 10 or 12 here at the RIPE meeting over the last couple of days and actually in some straightforward cases 15 LIRs, 37 allocated unspecified blocks, they asked us to convert everything to allocated PA. So those cases have been solved. Those were the easy ones because there was no PI assignments below it but there was still some cleanup done.

Here some numbers. When asking those LIRs, we asked those LIRs some questions, and what we could see is that 70% of them said, yes, we try to do what we can to keep the records up to date in the RIPE database, which is good for data quality. 80% of the ones that had allocated, even allocated unspecified to allocated PI, they would be willing to convert those resources to allocated PA.

We asked if all of them, if they were still in contact with the organisations that were holding PI addresses. And actually it's quite interesting to see that the majority are not in contact with them any more. They don't really know what happens to those resources, or to those organisations and again, we're talking about 15 years of history, and more.

Then an additional point was to check, okay, do they keep their maintainer, the LIRs maintainer in the PI assignment, are they keeping control over the PI assignments and 50% of them said yes, we do. We maintain control over this block.

And it's also quite interesting to see that a fourth of the LIRs holding PI address space they are still making new PI assignments out of the PI allocation that is they have.

So, summarising these results. We noticed that there is a bit of a misunderstanding for a number of LIRs. They believe that the end users need the assigned PI status in order to be able to route the address space however they want with whatever upstream provider they want. So, they see the provider independent from a routing perspective, but not from an administrative perspective. Because they still feel administratively responsible for those resources, and they believe that those resources belong to them.

Many LIRs are not in contact with the former customers any more, with the PI holders. And that there are organisations still making PA assignments, even though RIPE policy does not provision for making new PI assignments at the moment.

So what now? (PI) this is a plex situation. Every case is slightly different. There are many options available, we just listed a few of them. But we would like to see, with your support, how we should go further with this.

Our option resource. We can keep things as they are, this is something we have heard this morning also in other discussions. We could cooperate with the LIRs to transform what they believe is actually not PI but is actually PA into PA, and help them with that even though that would require a lot of work as we have seen that for thousands of PI objects. We could even accept the PI as PI and split the blocks for the end users whenever they come and ask us. So there is many different options and whatever option we take, not everyone will be happy. So, that is the only certainty that we have after this exercise. So, we need your guidance on how to proceed further.

GERT DOERING: Since you have quite a number of points, I think it makes sense to give quick feedback on each individual one. Thank you for taking this on and thank you to the LIRs for actually helping with this, because with without your help it doesn't work at all.

I don't have an official opinion on any of this, so let's hear the room.

ELVIS VELEA: I think PI is PI. Whether it was allocated ‑‑ or assigned by the RIPE NCC or assigned by an LIR, it has always been PI. If it has been actually registered, that's PI by the LIR to the end user. Now, the fact that the NCC changed the policy ‑‑ well the community changed the policy and required signed contracts with the assigned PIs from the RIPE NCC, I also believe this should also happen with the PI that are part of an allocated PI. I also think that the customers that do have Anna signed PI should still have the same liberty to move from an LIR to another with their assigned PI.

AUDIENCE SPEAKER: I represent an LIR which has been ‑‑ which became an LIR like two years ago, and they hold a number of PI assignments in an unspecified allocated state from the nineties, and I reached out to the other LIRs which hold the covering aggregate, and nobody knew how to deal with the situation. I was told by the RIPE NCC there will be no operational impact. My statement would be, whatever comes out of this, this should be solved, as there is these blocks that can be not handled in any way. Cannot move them. Cannot ‑‑ I mean, nobody knows what to do with this, so I would be very grateful if this can be resolved in some way, so maintain status quo would be the worst option I think.

AUDIENCE SPEAKER: One of the LIRs involved in this process. I think you have to point out that, well you are saying that the assignments today have this status, but they didn't always have. If they were assigned like in 1992, they didn't have any status at all. So to say that they have this, whatever status today, doesn't really ‑‑ status can be changed. For example we had blocks which were allocated PI and assigned PI and changed to legacy because they were legacy. And I think after the meeting we had yesterday, that it's the best to look for the sort of case to case solution, because all these are not the same. So, find a solution for each LIR is my proposal.

GERT DOERING: Reconsidering, do I actually have an opinion, but I'm not sure if it's doable. I think I said that last time that I do think from the wording of 2007‑01 that it does apply to these assigned PI blocks, to formally, the policy says where we should go. On the other hand, I can see the problem finding many thousand resource holders that have no formal contract about the status of their, whatever it is, network, with contacts that do not exist. I think that might be even worse than the 2007‑01 cleanup you had to do because these are many older objects, and totally unclear contact data. So I don't know what to ask for.

SANDER STEFFANN: If you thought you were almost done with 2007‑01 I think we have just added something to the pile again.

ANDREA CIMA: We gained a lot of experience with that.

GERT DOERING: For registry accuracy of course it would be desirable to clarify the status of every individual INET NUM and make sure it's either real PI with contract or it's sort of like put back into the LIR and formally changed into PA. I know from experience that no contract exists and nobody really knows what it is. So all we have it's as status, PI, and the holder claims it was assigned as such but no contract exists, so this is complicated. I could say I just trust you to get it done but that is not exactly ‑‑

SANDER STEFFANN: Init was mentioned before the break, the main goal is to keep the database as accurate as possible, so, I think that's what we should focus on whatever we can.

GERT DOERING: Right.

ANDREA CIMA: So, from what I understand ‑‑ I see Erik at the microphone.

ERIK BAIS: To give an indication on the huge amount of work that needs to be done here, and I'm talking about the allocated unspecified. We're talking about 22 entries in the database. What are we talking about here?

ANDREA CIMA: Sorry?

ERIK BAIS: We're talking about 22 entries in the database if we're talking about allocated unspecified. That's what I see.

ANDREA CIMA: We have 68 allocated unspecified. The point is not so much the 68 allocated unspecified blocks. Those numbers are not really high as I said before. I think the issue is mostly with what lies underneath it. When we look at 915 PI assignments, we are looking at 915 potential networks that may be impacted by this. And there may be disagreement between the holder, the LIR that holds and maintains and manages the larger block, the allocation, and the organisation that has the space before that, on what this actually is. Is it PI? Is it not PI? The question here is: Who is the actual holder of the address space? Is it the LIR that maintains the allocation, or is it the end user that has the PI assignments below it? I think that is the key question.

ERIK BAIS: But still, we have had this question coming up I think the last RIPE meeting, I think, it was Ingrid on the stage at this time, and I see you know the difference in the numbers. But you know, the majority of the companies that actually have, if I look here, the companies that have the allocated unspecified allocations, they are an LIR, everyone of them, and as the NCC you need to address to them first and they need to sort it out with their customers.

ANDREA CIMA: I think that that is, we approached the LIRs and we talked to them and I think actually what you are saying here is a potential way for us to act, meaning we put it back towards the LIR and their customer to discuss and figure out with each of them is it PI or not. That is a possibility.

ERIK BAIS: Isn't this something that comes up in the art?

ANDREA CIMA: Not for these kind of situations.

ERIK BAIS: Why not. Isn't that what they are for, they are actually audits. This is where you actually have once every two years, year, contact with the LIRs, what are the hell are you still doing with these entries and why are you not fixing them? I know I get those questions.

ANDREA CIMA: With regard to those allocated unspecified and allocated PIs, there was no clear ‑‑ there is a clear mandate from the RIPE NCC on what actually to take to them. As we have seen here in the room, there is a really difficult ‑‑ different perspective on it. And this is a complicated matter. If the RIPE NCC goes to them, to those LIRs and says okay, this is the action that you will take, hell will break loose because those resources have a difficult and a complex history. It is not straightforward. And that is why we are here. We are asking you tell us how to handle that, and if you say, as a room, as a community, okay, we want you to handle it in this way, we will go and we will do what you say, we will contact the LIRs and we will tell them exactly what you say, please sort this out.

ERIK BAIS: Okay, let's go back to the initial of your phrase when you started toen a. You ask us what the mandate is for the NCC. The mandate is accurate database.

SANDER STEFFANN: And I think this is also something that's in the ‑‑

ERIK BAIS: This falls within your, the work that we trust you to do. That is exactly. So, if you ask, you know, should it fall within our scope of work? I think the whole room would stand up and applaud and say yes this falls within your ‑‑ this is within the scope. Because this is why you are there.

ANDREA CIMA: One point. The main question is who is the holder of the address space? That is our question. It's not ‑‑

GERT DOERING: I think I see a way forward actually. I think the mandate from the community on database accuracy is definitely a given. There is no clear mandate on how the status field should be twiddled, but I don't think this is actually needed. So, what I would do from here is, the NCC talks to the LIRs in question and asks them to sort out their documentation. Which puts the onus totally on them. But if they take responsibility for maintaining the object and claiming it's not real PI, then it's their possibility to ensure documentation. And if they say, no this is real PI, then you make it real PI with a contract with a resource holder and normal standard PI anden owe will be happy. Because he is there and he wants to sign a contract and cannot do today. Of course it's going to take a long time and it will be lots of work for the LIRs, and they will not be happy with me for putting it so bluntly, it's their responsibility, but it is. They made the database entries and keep the maintainers, so, they get to maintain it.

AUDIENCE SPEAKER: Anna Wilson, HEAnet. I have a lot of hats here. I should mention my employer holds one of the allocated unspecified. We are mercifully in a position where it's pretty clean and I think we know what we're going to do with that and I'm happy with that. That out of the way, I am one of the people who keeps banging the drum about database accuracy. As a member of this community, at the same time, when it comes to the policies that RIPE, the RIPE community set, I strongly believe that. I do recognise that as a RIPE NCC member, who then has to pay for the RIPE NCC to go and clean up after ourselves, that can't be a blank cheque. The bit I don't understand in this, before we send the NCC away to do certain things, is precisely what problem that is solving, and if there is a problem that can be solved and is worth the money it will cost solve it, very well. But I haven't really understood that yet.

ANDREA CIMA: The problem we're trying to solve. We have been contacted, we have been confronted with concerns by users, organisations that hold these PI assignments, and they were not free, as the gentleman there explained before, they were not free to move their PI assignments to do with their assignment what you are supposed to do with a PI assignment. So they were telling us what is seems officially to be PI is in practice not. So how are we going to handle the situation? And here the problem is, as I mentioned before, who is the actual holder? The LIR that has the allocated PI blocks or the allocated unspecified or is it the organisation that then receives the resources? That was the problem statement. It's like who is the legitimate holder of those resources.

ANNA WILSON: So is teams what can the RIPE NCC do to clean up the data and the policy do currently what is allowed to do but think they should be. Is that fair.

ANDREA CIMA: It could be a policy change or it could be, I suppose, an action from the RIPE community on how to handle those kind of situations, how to interpret, how to handle this.

AUDIENCE SPEAKER: Okay. Thank you.

AUDIENCE SPEAKER: En owe again actually, for historical reasons, as Andrea pointed out, complex situations. I can only state in the cases where I was involved, both parties, both the LIR holding the larger block, the allocation, and the at the time the not LIR but now LIR holding the PI assignments, both agreed, they had a solution like, we would be happy to do something, but we couldn't policy wise. So, for that, I would be happy if the RIPE NCC could, in those cases, when both parties agree what to do, whatever that might be, but if there's an agreement between those two parties, decide on a case by case basis, get it done. Not least in the interests of database accuracy.

ANDREA CIMA: Yes, I agree with that. That's what also has been done in the past if there's an agreement between the two parties. The problem is when there is an disagreement between the parties. When there is an agreement I agree with you, we should help clean this up.

HANS PETTER HOLEN: If this was one of the last resort registries, they were kind of acting to help the load of the RIPE NCC, so they were simply acting as a proxy for the RIPE NCC and it should be Teredo as prettied as any other PI unless there's some indicator other written agreement in place. That's the first thing here, does there exist anything in writing regarding this? Now, this is complicated and your question is the key question and without a clear answer to that you can't resolve this conflict, so this is not about how much resources to spend on this or how to do it. If we as a community can't answer that key question, so I think we need to do that in writing so everybody understands it before we draw two lines under that, because otherwise one or the other party will get angry, and if it's sort of vague when it was decided, that's not so good.

SANDER STEFFANN: Hans Petter, if I understand you correctly what you are saying is if it's registered in the database as PI, treat it as PI unless proven otherwise? Or at least suggest that?

HANS PETTER HOLEN: If it happened within the time when this was the last resort registry or the inheritance of that, but then you are going into the grey area, right. I would say it's pretty clear to me when it was the last resort registry, some of them handed that back to the RIPE NCC and it's PI as any other PI. It's those who kept it afterwards, what's the ‑‑ is there such a clear answer for what happened after that date when they kept it? And I don't have a clear answer to that.

AUDIENCE SPEAKER: It's not only those that kept it, some actual LIRs received allocated PI from which to make assigned PI from the RIPE NCC, the actual LIRs ‑‑

HANS PETTER HOLEN: What was the contract, agreement or policy when that was done?

ELVIS VELEA: I wanted to say something about what you said, but before saying that, I would like to actually raise another thing. The NCC, looking at these blocks right now, should somehow block the possibility of creating more PI assignments from those allocated PI blocks, or allocated unspecified. There is no more PI policy. And to me, it looks like if someone would like to circumvent policy, they could actually go to one of these registries holding an allocated PI and get a PI assignment. So, first things first, I think the RIPE NCC should block the possibility of creating more PI assignments under the blocks that we're talking about.

Secondly, I agree with the idea that if there is an agreement, then by all means, transform it to PA, transfer it to another LIR as long as there is an agreement between the two parties, that's perfect. However, we are now in a situation, in a time when IP addresses are considered by some, assets, so the question is who holds that asset? And when it was originally assigned by an LIR to a customer, it was assigned as assigned PI, just like if it would have come from the RIPE ‑‑ because even the RIPE NCC was making PI assignments at that moment. So the LIR acted as a proxy because the RIPE NCC said here you go, there's a big chunk, every time you need a PI assignment, come to me for an approval, I'll approve it and then you make it from this block. So, maybe they gave those allocations as some way of aggregating PIs in a country, or I don't know why the NCC actually made PI allocations. It was before my time in this industry even. But, as far as I can see it, when someone requested a PI from an LIR, the LIR had the option to give it from the block that was begin to them by the RIPE NCC, or to ask another block from the NCC. If they gave it from a block directly from the NCC, there's no problem, because we have done 2007‑01 and that worked. But if it's from the block that was delegated by the NCC to the LIR to make PI assignments, then that's a problem and I think there should not be a problem. This should be treated as assigned PI. Period.

GERT DOERING: I tend to agree with Elvis on the allocated PI blocks. I think these are fairly easy policy wise. The allocated unspecified are the ones that are bothering me because it's not clear historically what is what.

SANDER STEFFANN: And about forbidding any new assignments from allocated space, I don't think we should go there. It's allocated space. It's been allocated to an LIR. Let's not go mess with that. And if we do something with that, it would need a very strong proposal.

GERT DOERING: Well, no, actually not. It was given out to be assigned according to RIPE policy, and if RIPE policy says there is no more PI ‑‑ you had awed allow a signed PA but do not allow new creation of new assigned PI.

GERT DOERING: This is what the current policy says, we don't have assigned IPv4 policy. So indeed LIRs should not be making. Are these in active use the allocated PI LIRs, or...

ANDREA CIMA: There is nine LIRs that we spoke to that are making some PI assignments or planning to make PI assignments in the coming future.

GERT DOERING: I don't think the policy permits that. Well, it depends on what contract the allocated PI was given to them, but I'm pretty sure it says according to RIPE policies and if the policy doesn't permit PI assignments any more, they shouldn't be doing it.

ANDREA CIMA: Okay.

GERT DOERING: I'm now totally unpopular. I can live with that.

We have totally used up our discussion time I think because you have four more points to bring feedback. And I have actually one on the Open Policy forum. So, I think we should just briefly report on the things, and not discuss them long, because otherwise you will all not get lunch.

ANDREA CIMA: We can bring them up at the next RIPE meeting either.

GERT DOERING: I think it's good to have it here. Maybe I'll ask for questions if something is unclear, but no discussion because we just used up our discussion time. Apologies for that again.

ANDREA CIMA: I knew this was a complicated matter but I didn't expect it to be like this.

Okay. The next points that we wanted to bring up. The first one is the transfer of legacy resource after an Inter‑RIR transfer. What happens is there is a region, especially the ARIN region, where there is a need basis in place for transfers. Now, our own Inter‑RIR transfer policy says that when there are regions that require the receiving region to have needs based policies, the recipient must supply a plan to the RIPE NCC for using 50% of the address space within five years.

In order to allow the resources to come from ARIN, we also apply this question to legacy resources as the policy mentions that legacy resources can be transferred in spite of there not being a specific transfer policy for legacy. So what however happens is that even if we receive a plan, by the recipient, for using the address space, the legacy space within five years, once the legacy space enters the RIPE region, the legacy policy applies to, it our own RIPE legacy policy applies to it, means there is no transfer limitations for this address space, and this means that the receiving party of the legacy resources can retransfer the same resources the day after in spite of them having provided a five year plan.

Now, we haven't seen many cases like this so that, it's very limited, we can count them on a few fingers, and this is policy compliant. But our question and some concerns that we had received was is it really also really according to the spirit of this policy that sets 50% utilisation within five years, so that was one point.

The second point was IP prefixes and AS number requests. For the past 15 years the RIPE NCC has been asked what prefixes will be announced when an organisation requests an a new AS number. There are traces of it in 2001, so it's been for a long time.

Erik Bais: I was actually one of the people doing this () ‑‑ and I actually did this. However, my motivation in this was we are actually splitting up the prefix as soon as it lands into the RIPE region. And selling part of the prefix actually, to my view, is actually consistent with having the resource in use. Now, if you argue otherwise, because we actually make sure that unused resources are actually being used, and that is according to the policy. So, although it is legacy, maybe a bit stretching, but we actually, you know, are not selling space just to stockpile them.

ANDREA CIMA: Yes, and exactly as I mentioned, this is according to policy. It is within the policy framework, it's policy compliant. We received some concerns, whether this was actually according to the spirit and we just wanted to bring this out, to let you know that this is happening for full transparency, so what is the case here.

AUDIENCE SPEAKER: Sandra Brown. The only comment I would have is when a company transfers the IPs into RIPE region and it's related company transfer, that might make a difference. I have never participated in a case like Erik is describing, that sounds to me a little bit speculative, but I think when it's within a company such as a subsidiary to a parent in Europe or something like that, that seems perfectly fine to me, but to transfer for the speculative purposes from unrelated companies, that sounds a bit speculative to sell.

AUDIENCE SPEAKER: Hereby a.m. Ray haem. A remote question: His comment, Yours sincerely from William white from hubs, and he says; the conditions on recipient outside of the ARIN region will be defined by the policies of the receiving RIR. From what I can tell, ARIN does not require needs‑based policies on the receiving LIR

GERT DÖRING: We could go on and have a really cool discussion on that right now, but I'm sorry we don't have time. So I have to really cut the discussion here. Take it to the list. Apologies for not having a full day for discussing this. Please go on.

ANDREA CIMA: So, the next point, I wanted to bring up, as I mentioned before for the past 15 years RIPE NCC has been asked which prefix is going to be announced when an AS number is requested. We got asked why are you asking this prefix. It does not specifically mention it in the policy documents for requesting AS numbers. And actually, that is correct. The policy doesn't specifically mention it. And we have been doing for 15 years so we revised a bit why have we been doing this. What we see we want to make sure that assignments are adjusted prop he were and now we talk about security, we want to make sure that the request of the AS numbers are actually authorised to announce the address space that they mention, or that they are authorised to announce some address space.

As well, we want to ensure that AS numbers are not stock piled because if you don't have a prefix to announce you could request many AS numbers and put them on the side. And we want to make sure that AS numbers are issued directly to the end users that need the AS number. Otherwise they could be issued to an LIR who could then keep them for themselves and issue them as PA numbers. This is the reason why we do that. Of course that doesn't mean that we have to do things in this way. We have done things for 15 years but it's not a reason for continuing doing things. This is also something that we would like to request some feedback on next time.

IXP assignments for IPv4. Now, very quickly we have a /16 reserved for IXPs. These are the only IPv4 PI assignments still issued by the RIPE NCC. The policy is quite strict and it says that IXPs that return this space, the address space will go back to the pool. 67 assignments are made so far under this policy.

Now, one thing we see is that the policy text is very, very strict. Policy text says that any other use of this space other than running an IXP peering LAN are forbidden. And these are the words of the policy. We have seen 10% of the IXPs that hold space from this pool has been, this address space was visible in the routing tables. When we contacted them to ask why this was the case, because we would regularly not expect that from an IXP peering LAN, they told us they were using the space also for other purposes. The policy is quite strict about it and says that it's forbidden, so, our question is okay, how strict do you want us to to be with this? In those cases people stopped announcing it and they stopped using it for those other services but how far should we go with pushing them, should we have a register eventually in case they refuse to do so.

The final point was IPv4 ‑‑ IPv6, the potential policy bug that was reported to us.

Now, when an end site requires more than a /48 or multiple /48s, they have to send in a request for a valuation and approval. We received a question about this. So, whether if an end user receives multiple /48s from different LIRs, from different allocations, whether that would also count towards a need for a valuation. And our perspective at the moment, our interpretation of the policy is that in this case, this is not needed. Now, as the policy text is not really clear about this, this may result, if someone wishes to adapt this policy text to make it really clear, or maybe our interpretation of it here, maybe that could be enough. It depends a bit on that.

Sorry for rushing through those but I think we are already in lunch time so I'll pass back to Gert.

GERT DOERING: Thank you for bringing up these issues for consideration. And sorry for my bad time planning. We have one more item on the agenda, so, we need a bit more on that.

First an applause for you. It's not always easy to bring stuff here. And I would ask you to split these five into five e‑mails and bring it to the list so we can have an appropriate discussion on it, not rushing things just because people are hungry.

I have one ‑‑ I have been approached by max. Which will hem about one annoyance in our IPv6 PI policy which perfectly fits into the Open Policy hour. It's not a policy proposal yet. It's just an itch, where ‑‑ our existing policy is getting in the way. It was just uploaded a half an hour ago.

SPEAKER: While waiting for the slides, I am max. William, I'm from Germany, Fry function, that's the hat I'm wearing currently, we devent lied organisations in Germany providing public Wi‑Fi services so it would be interesting to have IPv6 PI space so that the communities that are be distributed in Germany can get transit from our IS and get some ‑‑ to the Internet. We stumbled on a problem there.

So, RIPE 637 states that sub‑assignments from a PI space are not allowed. And the RIPE NCC has a rather strict interpretation of that, so even if I put a /64 network on a public Wi‑Fi, they say if a user on his end device uses one IP from that it's a suballocation and therefore we didn't get any PI assignment. I consider that's a problem with this policy as I think it would be a fair use case and would I like to open a discussion on that topic, so where we could draw the line to decline suballocations.

Maybe, we draw the line at allocating a /64 to some end users or some other institutions, or maybe we add a statement that the RIPE NCC knows how to interpret the policy so it is usable as a concept.

SANDER STEFFANN: I think it's important to realise that what you're saying at B is exactly the reason why the policy is written as it is. Because, in IPv4, it was very common that somebody could give one IP address to a customer and then the customer would NAT and if we would allow this from PI space, that we would basically create people would go like we can become an LIR, this is expensive, but if we just get some PI space, we just give everybody one IPv6 address and they can NAT again and since that was not the intention of at the time, it was specifically said that this loophole that was in v4 that you were allowed to give one address and it wasn't considered an assignment had to be removed from v6, so, the current situation was created intentionally, so I think this is a bit of important background information for this discussion. Dear Dear while it was created intentionally, it was not created with folks like you in mind. It was big telcos that wanted to continue their single IP address do not practice.

It's your lunch time, so if you want to discuss, I am here. Let's keep this quick, two, three, comments, and I think then we go back to the list and see. We knew what we wanted back then, but maybe we don't know what we want today.

ELVIS VELEA: First and foremost, it was not only with one IP address in IPv4. The NCC would accept a /30 to be considered a point to point connection, a /39 to be considered a point to point connection as with the VR IP, so, several IP addresses could be considered a point to point connection. Now, that was point number one.

Point number two is, we did try at some point to change the IPv6 policy, and it was considered to be way too complicated, but this would have been solved by that. However, since that didn't fly, I think that we should maybe change the PI policy, or maybe just the RIPE procedure, I don't know if it's policy that needs to be changed, but I think making a /64, which is considered one sub‑net, one thing is a gooded in. Doing 128 assignments out of IPv6 from my point of view is a really really bad idea. So, I would say, that the PI holders are already doing it. The fact that they cannot register it in the RIPE database or the fact that they cannot tell anybody about it, doesn't mean it doesn't happen.

So I would think that we should find ways to allow /64s to be given out from PI assignments and I think it would be even a much better idea if those could be even registered for consistency of the registry and stuff.

GERT DOERING: Actually we do want to encourage ISPs to give their customers a 56, so, opening, you can give 64s from your PI to third‑parties is sending the wrong signal. Because, we want them to give 56s. Now they are not giving customers prefixes, they just private infrastructure so customers can connect their laptop. So the question is whether this is giving ‑‑ whether this is making an assignment which is a different angle of the same discussion. It's not so clearly cut black and white.

ELVIS VELEA: Allowing the connection of the customer to your network is not making really an assignment. It's just connecting your customer to you. So using a /64 for that is enough. Allowing the customer after that to receive a / /56, that is making an assignment and that should not be possible with IPv6, I think.

SPEAKER: Which should be forbidden by the current policy?

ERIK BAIS: So, if you're providing services to third parties, that is not why PI was intended for. So, the NCC was actually correct in denying you the PI space. If you're actually providing services to third parties and where you want to discuss on this is not an allocation or not an assignment, that's semantics. So if you are a service provider, you need to become an LIR. If it's your own infrastructure and it's for your own company usage, then you know, use it for public Wi‑Fi in your office, those kinds of things, it's your infrastructure. It's not the reason why you have the PI space is for your infrastructure and it's not to sell it or to give it out as a service. You know, obviously you'll have some of it. But, if ‑‑ that is where the definition is. And I don't think it's going to be a good idea to change on that definition, because we don't want the same you know, let's get cheap PI things in the v6 policy. Let's not go that route.

SPEAKER: What I should have mentioned is that we are totally non‑commercial, we don't get any money. We don't have any money.

ERIK BAIS: I am very sympathetic for you. If you need an LIR that holds v6 prefix, so that you can actually do this properly, let me know, I have blocks to spare, you know, and kudos to organisations that actually want to provide v6 connectivity, but getting it on v6 PI space is not the right way. So I'll be more than happy to talk to you about you know getting you PA space that you can use and route wherever you like it, but not on PI.

SANDER STEFFANN: Erik, just for clarification, you are talking about sub allocated PA space from a different LIR?

ERIK BAIS: Yes.

AUDIENCE SPEAKER: Peter Koch, professionalsly confused. So, when I opened my laptop I received an address and that might have been an assignment. I hope I won't end up in the database for that. That's the one thing. I guess we had that discussion that end user assignments would never show up in the database for data protection reasons and everything. So I'm not really sure I understand the model. Also, we had a similar discussion years ago I think about like hosting providers, whether or not the infrastructure that they rent out or sell or something to their customers, while the gear remains in their racks, so what's the difference there? Don't we have enough precedent to just follow this through? And why actually ‑‑ and by the way what you didn't say is that would you consider the, and this is a trick question of course ‑‑ would you consider the people participating in this as members of your initiative?

SPEAKER: My users. I'm not sure I follow.

PETER KOCH: The people that you, like ‑‑ I am hesitant to say ‑‑ provide the service to, the people that joined your non incorporated club. Do you see that I tried to avoid the third‑party option here?

AUDIENCE SPEAKER: Well, while I do agree that the best thing for you would be to become an LIR, I do not agree with Erik's point of view. The question would be a difference between somebody providing Wi‑Fi in their office and somebody providing Wi‑Fi in the street, which is the difference at the end of the day? They are both providing Wi‑Fi to one, let's say one device per customer, so, from this point of view, a PI block should be okay for you the same Yours sincerely okay for a company which offers Wi‑Fi to their employee. (It is) on the other hand, globally, it would be probably better for you to become an LIR, have some form of legal which can become an LIR, non‑profit, whatever, it doesn't matter, to become an LIR, and do these things the way everybody expects things to be done.

SPEAKER: Which does not work in reality. But that's another topic.

AUDIENCE SPEAKER: Scott Leibrand, I pulled out my laptop, looked up my IPv6 address on this Wi‑Fi and did a WHOIS on it. The block that it comes from is a /48 that signs assigned PI. RIPE is doing this. RIPE NCC is doing what is apparently illegal. Perhaps we should be making a distinction between things like self assigned addresses on a LAN using slack versus actual like DHCP D assignments and allocations, they seem a little bit different to me.

AUDIENCE SPEAKER: Hereby a.m., RIPE NCC staff. Presenting on behalf of a remote participant. Sebastian Visinger, speaking for himself. The definition matches what the RIR does, perhaps there needs to be some sort of non‑profit LIR which would be something for the GM I think. Although I'm aware this would open a can of worms, oh, and I forgot the non‑profit LIR would of course have to pay a lot less fees to make this work.

SANDER STEFFANN: We don't do fees here, so let's not get into that for now.

GERT DOERING: But it might actually be worth bringing an input to the GM, consider it.

ERIK BAIS: Interesting remark on that regards. There are actually local N O Gs, network operator groups, in various countries, and that might be a very good option to actually see if you can get additional space or space you know from a sponsoring LIR in that regard, as most of the time they are very open and willing to participate in these kind of things. And as I said, if you really have an issue, and cannot do this, talk to me off line, I'll be more than happy to allocate space for you for your requirements.

SPEAKER: Thank you.

SANDER STEFFANN: I have, to reply to Erik, I have done the same for a German non‑profit organisation and I just sub allocated a bit of my space for them so they could run their non‑profit. So it has happened before.

GERT DOERING: Well, thanks for your feedback. Thanks for bringing this up. I am afraid you are not much more happy now. But you at least got some answers. Take it to the list maybe.

Go to the AGM today, and see whether the idea for non profits, there are could get traction. I could see that it makes sense, but I could see a huge nest of rat holes like what is a non‑profit in 30 different countries? How to check it.

With that, I thank you all for being here. I leave you to your lunch now. Thanks for providing feedback. Enjoy your lunch and see you at the next RIPE meeting.