Skip to main content


Tuesday, 28 October 2008 9:00

Address Policy WG

The session commenced on the 28th October, 2008.

CHAIRMAN: Good morning everybody. Welcome back to the Address Policy Working Group. It's nice to see so many of you at this early morning hour here, especially given that in, well Central Europe time, this is sort of like six o'clock in the morning. So I am really pleased that so many found a way here.

I will, first, sort of recap the agenda for the two time slots we haveed to and then we will go right into the policy discussions.

We have two slotsed to, the first one is right now, 9:00 to 10:30. There will be informal policy proposal about IPv6 resources for the RIPE meeting, which is sort of very mobile network attached to various providers around the world. Them we will go to the end of the IPv4 session, which will then go over to the second time slot. The first big thing in the end of IPv4 session is the transfer proposal permitting IP address blocks to be transferred between cooperating registries when one runs out and the other one still has addresses.

Before actually discussing the proposal, we will have a presentation by Tom about different aspects of transfer proposals and transfer policies from somewhat more academic point of view. We will see  that should give a good background for the actual discussion.

The second time slot we will have two more proposals concerning the, well the end of IPv4 periods, how to handle the last /8 and what to do with old address space. And then we will have two proposals that touch other working groups or taskforces. The certification taskforce and the AS number format change proposal. But more about that later on.

Okay. I am going right away into the presentation discussion. First presentation is from Andre from the RIPE NCC and I don't actually see him  there he is.

SPEAKER: I saw this trick once. Good morning, my name is Andre, I work for the RIPE NCC and well probably the proposal is a big word for what I am going top present, because what we actually asking is for some IPv6 resources for the RIPE meeting network, but let me just explain in a few slides explain some background.

So, well, right now we are running production quality IPv6 meeting network. We are running this for quite a while starting with some experimentation, but now it's at production quality and I hope many people are enjoying IPv6 at the RIPE meetings and we have to set up this network at different locations where a RIPE meeting is happening.

So far, well depending on the occasion, we either used part of our assignment from Serve Net, that's how IPv6 key assigned to the RIPE NCC and the last meeting we borrowed a /32 from Telecity Deutschland and I think for this RIPE meeting, correct me if I am wrong, we are still using this /32. We had an agreement with Telecity Deutschland that we can still use it for a while.

But as you can see, those are just workarounds and there is no policy support for the case where RIPE NCC can actually ask the RIPE NCC for IPv6 assignment for this case.

So here is the policy proposal. IPv6 assignment for RIPE meeting network. It is assigned to a meeting organiser, or currently it is the RIPE NCC. It's used only for RIPE meetings and has to be returned to the RIPE NCC if conditions cease to exist.

We are asking size of the assignment is a /48, we'd like more but I think /48 is enough. And the database status as it was will be registered and the database will be "Assigned meeting."

Well, for the RIPE meeting network we need an independent permanent assignment. The workaround I showed has some drawbacks and downsides. So the network is set up at different locations and we have very limited time to configure tests. So we'd like to have a permanent assignment that we can actually configure, preconfigure before we go to the RIPE meeting.

Very specific purpose: It's a community thing, you would agree. And well, in fact we are asking for /48, it's not /32. So, to maximise  we were asking for /32, but I think 48 is enough. We can debog /TPHAOEUZ this address space and actually maximise connectivity and simplify set up.

Well, that's very simple. Any questions? I would be happy to answer.

CHAIRMAN: Okay. Thanks Andre for well explaining the background.

AUDIENCE SPEAKER: Sorry, Randy Bush. What about other meetings that need space and what about your feeling for the routability of a /48?

SPEAKER: Randy, I apologise, I didn't get your question.

AUDIENCE SPEAKER: There was two questions. What about other meetings? Why is RIPE special? What about SWINEOG and what about the routability of a 48?

SPEAKER: Really RIPE meeting is not special. You probably know that IETF has a dedicated /32 that that he got from APNIC. There is a provision in APNIC policy that allows actually registries as well to get an assignment from APNIC, but on the condition that they operate in Asia Pacific region. I don't think in the foreseeable future that we will operate in the Asia Pacific 

AUDIENCE SPEAKER: I was going the other way. I was saying you are asking for a specific fix and maybe you want to do something a little more general for the region, which is you know, other meetings and so on and so forth who need v6 space in your region.

SPEAKER: Okay. Well if there is specific cases, we can extend this policy, I have a very specific problem on my plate.

AUDIENCE SPEAKER: Oh yes, I bet you do. I know.

SPEAKER: Randy, if you have any specific suggestions, please...

AUDIENCE SPEAKER: I am embarrassed to say I have not looked at the wording of the APNIC policy that's being used, considering that I am the chair of the APNIC Policy Committee. But it's before I got stuck with the job. But you know, maybe steam from it or something. It allowed for general conditions is all I am saying. If you have the problem, other people are going to have the problem. Rather than an exception, this is the policy working group not the exception working group.

SPEAKER: Okay. Just to address this specific issue, I think it's worth looking at APNIC policy, their scope. I saw this policy proposal as more a way to document this particular assignment.

AUDIENCE SPEAKER: Just to be clear, I am not opposed to T I am just suggesting generalising it.

CHAIRMAN: Okay. Thanks Randy. Anybody else? I see Rob coming up.

AUDIENCE SPEAKER: I want to repeat Randy's  I am Rob becomes I'll. I want to repeat Randy's second question, the routability of a /48.

SPEAKER: Well, we have to see. We have a lot of clueful people who are interested in routability of this particular /48, so we hope we can solve this problem. But, if RIPE committee is generous enough to give us /32...

AUDIENCE SPEAKER: So, I think we have two issues here: One is a practical problem for RIPE meetings and one is a feeling that we might not be the only ones who have such a requirement. So, maybe we can find a way to quickly solve your actual problem and think about a more general policy.

AUDIENCE SPEAKER: Cathy Ernstein, adviser Council. Isn't this just a more specific case of the PI policy that we talked about yesterday?

SPEAKER: Well it could be, there is no PI policy and 

AUDIENCE SPEAKER: And are the people who are against the PI policy then against this? I mean it seems like  well anyway...

CHAIRMAN: Thanks castey for actually bringing this up, because, well I have been wandering why nobody is suggesting this. Well, the specific problem for RIPE meetings is that we don't have a PI policy yet so cannot use PI space. But from the discussion yesterday, I think we are likely to have a PI policy soon. So assuming we had a PI policy, do you think that would do for RIPE meetings or do you think there is a benefit to have a special earmarked prefix?

SPEAKER: Well, I don't  well, as I said, I would repeat, would I see this as a way of documenting the specific assignment is not RIPE NCC assigned some address space to ourselves. I think we can, in principle, use PI policy though the contractual relationship may complicate the setup. It's like we'll have to pay something, make a contract with some of the LIRs which makes a contract back to the RIPE NCC. Well, I am not sure we have to see. In principle, yes. I personally don't see any  I wouldn't call this a PI policy. I would say, well it's just a way to document the specific assignment.

AUDIENCE SPEAKER: I have a question: Doesn't your PI policy though allow for direct assignments from the NCC to PI recipients? I mean, you don't have to have a contract with an LIR, do you?

CHAIRMAN: It's okay to have a contract with the NCC but the NCC being the NCC is sort of then sort of, it would be necessary to have a contract with itself, so I'm not exactly sure.

AUDIENCE SPEAKER: I just meant in the more generalised PI policy, not in this specific instance but in the more generalised one, the NCC would actually give PI blocks, right? Okay, so  okay...

CHAIRMAN: Well the more general PI policy is tying the contracts to the 200701 proposal which says that you either have to have a contract with an LIR that the PI is going through, or if you don't like all the LIRs in your region, you can have a direct contract with the NCC. But it doesn't really take the NCC itself into account. So, maybe we might need to actually work on that a bit.

SPEAKER: Yeah, it would be a bit obscure I think if RIPE NCC make a contract to the RIPE NCC.

CHAIRMAN: They could found a company to do all the nice meeting stuff for them. I see that this is  well, I think everybody agrees that it's useful for you to have a stable prefix, but the mechanics need a bit of working out. So I think we should just take it to the list and try to 

SPEAKER: What we can do. There is no formal proposal. We can quickly inject I think a formal proposal. If you think that's the way forward. And then have some discussion on the mailing list and then see where we go from there.

CHAIRMAN: Okay. Let's have a sort of quick poll on how to proceed. One approach would be to go for the PI policy and figure out how to fit that in. The other approach would be to do sort of a special case exception thing. I see Rob coming up again. Maybe some words from you.

AUDIENCE SPEAKER: I think in my personal view, it's total overkill to do a whole policy development process for this exceptional case. It's a different matter if we develop something for the general case of meeting organisers, but for the specific case of the RIPE NCC, I think we should find a simple technical solution and if the RIPE NCC, and I think we all understand it, tells us that having a dedicated /48 or /32, whichever is easier and better to organise these meetings, we should quickly say yeah, good idea and sort out the paperwork later.

CHAIRMAN: Okay. So I seem to be hearing we take it to the list but keep it informal and try to just find a way to solve it, right?

AUDIENCE SPEAKER: Sorry, to drag us back on this discussion, when we are mercifully almost done. I just wanted to disagree with what Rob was saying there. I think if there is someone with a specific problem that all because it's the RIPE NCC doesn't mean that we should all of a sudden say we are going to sort it out and handle the paperwork later. Because nobody else in the world has that luxury. The RIPE NCC of all people should be forced to go through the pain and suffering of trying to get a policy changed. So, that's all.

AUDIENCE SPEAKER: So, to be still very practical, we need a solution before May next year because that's the next RIPE meeting. And let's see whether we can have a little bit more general policy covering this specific item in place before May P

CHAIRMAN: So we take it to the list, discuss it and then formalise something for general from it. Okay.

SPEAKER: Yeah, that's actually one of the reasons I wouldn't go for a more general policy, because it may take longer. It may not be in time for May. And then I think when those more general policies appear, there is a need for those general policies, we can integrate this policy into them later.

CHAIRMAN: We could just try it that way. I think right now we sort of need to look at the options and see what the current policies permit and 

SPEAKER: So, I should we create a PEP or PDP process 

CHAIRMAN: I would say we go to the lists first for a more informal discussion to figure out which way to go and then decide on whether we  how the policy proposal is going to be written and if we need a formal proposal at all.

SPEAKER: Fair enough. Thank you.

CHAIRMAN: Thanks for coming up and describing the need.

Okay, now we are here in the agenda, we are leaving the PI special case and going to the end of IPv4. I see Tom Best coming up and let's see whether foreign laptops will work with this.

SPEAKER: Okay. Thanks very much. My name is Tom Best. I am as many of you know, I am an external consultant to the RIPE NCC science group. I have been around the community for about ten years, first as an operator for about half that time with AOL Time Warner in Europe the Americas and in Asia. And since then, with a variety of the technical coordinating institutions. And I am going to be talking about  actually, we thank the Address Policy Working Group for giving me a chance to review a paper, an academic paper that I collaborated with with an academic and another member of the community of the IETF community. And that's going to be a subject of my presentation today. So the paper is called "Running on empty: Challenges of mappinging IP acrosses." So it's actually available on line at URL and the coauthors were William /HRAOER and Elliott Lear who probably many of you know is with CISCO and is a long time IETF contractor.

Here is my disclosure. Of course this is a very controversial topic and to the extent that any of this reflects my own contributions to the paper, they are my own opinions and in no way reflect any policy or opinions of RIPE staff or members.

So, the paper itself was precipitated by a workshop which was organised and sponsored by Dave Myers of CISCO, back in the fall of last year, to discuss issues of IP address arising from the exhaustion of the unallocated IPv4 pool. This was a twoday event brought together a lot of academics and developers and what some people would call vendors as well as operator with the idea that crossfertilisation of prospectives would be useful begin the very dramatic changes that this might portend. And the presentations at the twoday workshop were quite varied. It would be hard to characterise anything in the way of actually conclusions other than the fact that it seemed to be useful to solicit the perspectives of people who do not normally participate in address policy deliberative functions like this, and that that trying to solicit more of those might be useful. And to that end, it was decided that some kind of structured thematic document should come out of the event itself. The first goal was the idea was to put together something like a reportorial report, but rather than being strictly minutes, to make it more structured and more thematic so that it would be a little more digestible by potential audiences.

Bill, the MIT Professor, is actually on the programme chair for arguably the most prominent academic telecommunications policy conversation in the world, it's called TPRC the Telecom Policy Research Policy, it happens once a year in the Washington and DC area. He suggested rather than doing this as an internal document T would better he be serve the goal that was identified by trying to turn it into a kind of paper which could be presented at the TPRC conference. And that's what we did and coincidentally, the paper was accepted by the programme committee. In fact we did present it. That was a few months ago. So here are the coauthors and again we are a diverse mix of people. Bill is quite prominent economists based at MIT. He is a director of the communications project, or something like that at MIT and is a frequent contributor on issues like this, not only in the Internet sector but in other high technology sectors. Of course Elliott has authored or coauthored a lot of RFCs and his most relevant claim to fame in this context was his participation in the PR working group which was maybe before many people's time is back in the mid90s, PR standing for pricing for Internet addressing and routing announcements and I don't know what that guy is at the bottom.

The paper itself is quite long. It started off with background, technical basics en routing and addressing for the nonengineering audience that we were trying to approach. We developed the kind of a taxonomy of way of looking at allocation mechanisms which would be the substance of my talked to. And we then there was a very long couple of sections on prospective advantages and disadvantages of marketbased approaches to IP address allocation. I am not going to go into those at all in this talk. The paper is quite long and in point of fact, the authors themselves did not achieve consensus on the relative weight of risks or benefit to properly attach to most of these. So, rather than going through the contentious things I'll leave those for them who want to look at the paper itself and of course we also talked about looming developments which would have a largely unknowable impact on these questions and the resource certification was something we mentioned in this context, but didn't explore it in any great depth.

So, as I said, the paper itself was really more of an exploration between three people with quite different experience bases and world views. And absolutely not a consensus document.

Once again, I am only going to focus in the next few minutes on the very earliest part of the paper which I would have characterised as sort of a met logical as a way of frame the issue which might be of interest in this discussion about how to manage the end of current set of arrangements that we have been party to.

So, what will change in resource transfer environment and/or the exhaustion of the current unallocated address pool? Well, transfer prefixes will one source of expansion address resources for existing established service providers, they also be the only source of IPv4 you know nonsubstitutable IPv4 resources for either new network enterprises or aspiring new router service providers in the future.

So that's one significant change. And so what will come from that particular change? Now, so I broke these down into the technical and economic issues. First, how will we handle the rate of demand or the growth of demand on finite routing system capacity? Of course the current arrangement, the routing system capacity management arrangement is in two parts. One is the basically the RIR system itself which manges the top level of deaggregation, the eligibility criteria for you know basically firsttime allocations or AS numbers or PI address space which basically sets the maximum upper limit that CIDR can operate at. Then below that CIDR, we have technology which permits routing to be, routing capacity to be conserved up to that level.

And so, clearly in the future, those two mechanisms will either work differently or not at all.

How to sustain addressing uniqueness? In the current system of course we have a monolithic address delegator and the registration database more or less shares fate, physically shares fate with that monolithic distribution mechanism. The maintenance of uniqueness over time is accomplished through mostly basically incentivebased mechanisms. The primary one being, once again the monolithic control over the pool from which subsequently allocations can come. But also like things like meetings like this, annual renewals, there is all kind of passive mechanisms which help to facilitate the preservation of the uniqueness of address resources over time.

Now, economic issues: How to approach IP addressing availability. Of course this is really the substance of the transfer market issues. In the current system, of course addresses aren't available to anybody who wants them at any time. LIRs apply conservation policies which may not, the results may not always satisfy customers, but it the community is collectively determined that that's the most efficient way to distribute resources. If conservation policies are the result of that are remember peeved sob too onerous by customers, they have the option of becoming LIRs themselves by satisfying the eligibility criteria to to step up and become a top level participant, so to speak. In the system. And when existing resources in play have been used as as far as conservation permits, given actual needs, then of course there is always this recourse pool to return to.

So, those things are obviously going to change. How to handle industry hopeness? This may seem like a fuzzy issue to people, but because it's not a part of the explicit goals that are spelled out for the RIRs, it's not you know an explicit thing. But it has been a byproduct of mechanism that we established with a more specific technical purpose of preserving uniqueness and conserving address spaces and routing system capacity.

So, that's an economic issue.

So, now, having identified those issues, doesn't necessarily mean that they need to be addressed. You know, there is several different ways of thinking about whether you want to include those factors in your consideration about what to do at this point in the lifetime of IPv4. You could choose, some people may feel that it's appropriate to simply not address them at all. That basically that the end of v4 proposals are really just the goal is to effectively to legalise the inevitable and in effect, they are only proper subject matter is the winding down of services that currently existed to and any consideration of you know, what comes here after should be properly taken up elsewhere. Or, as been undertaken in some contexts, you could try to address them exclusively by launching a particular kind of market.

So the idea here is to define some goals you think which should be preserved, uniqueness or availability of resources, whatever you think is important, but try to create some market and just launch it in the right direction so that those goals will be selfexecuting, selfrealising. It's begs the question of which goals are, which would fit that description? But anyway in more challenging approach is to do the full on market design. And so, this assumes that you have identified some goals that you would wish to pursue, but which are not in fact purely selfexecuting in a completely decentralised context and then the challenge is to figure out the tradeoffs between the ambitiousness of the goals and the costs of the collateral reinforcing mechanisms that would be necessary in order for those goals to be realistic.

So, this is the taxonomy that we used in the paper. This was the sort of the genesis. When you think about the vertical dimension, the sort of the goals you might have. Again, if you think  if you believe that there is quite a large number of goals that should be pursued, you are up on that scale. If you or no goals, then you are heading down. If you believe that the rules reinforcing structures would be necessary to achieve the goals are going to be substantial, that's moving you to the left. If you think they are more selfexecuting that basically is putting you to the right. Again if you look to the right. It's sort of synthesising everything. Down here on the right in effect,  this basically sort of formalises it a little bit more, basically down here on the righthand side  I will try not to turn that way actually.

Anyway, this is just again putting this into the /WOBGS which you will find in the paper if you happen to read it. And it's just basically framing out the whole thing and again, once again, if the numbered approaches are right there on the right.

So, would the RIRs fit in in this context, as I die find here, certainly the individual staff functions at the registries you know is at administrative and centralised. Of course we have multiple registries now and if you think of them in that larger context, there is some distribution of functions. Of course, we  the RIRs do currently administer a kind of eligibilitybased criteria for distribution address resources. Eligibility is a kind of competition, it certainly does exclude some people from access to those resources. But it's not you know competitive in the same sense that a market is. Except for to the degree you think of the liberty process that we undertake here in like the Address Policy Working Group. So there is definitely a competition of ideas and ultimately the ideas that the best ideas in that competition win, and they are made in policy for the whole community. So there is a competitive element.

To make this a little bit more concrete. Again, we actually have precedent for thinking about like the most extreme form of a concentrated eligibility on entered distribution mechanism would look like, we have a picture that most people are familiar with. And it is not the same thing as a first come first served mechanism. It's definitely a sharp contrast in the way way there is between a market. Op the righthand side we think of the  if the world, if we had a world full of John Postells, then there would be perhaps no need for other mechanisms or reinforcement mechanisms, maybe everyone would know the rules and interpret the rules and accept whatever rules or goals that might exist and always perform in accordance with them. So, if you  it would be nice if the world were that way perhaps.

On the competitive side, a marketplace with lots of rules, you know, they are element /TRAOEPLly  that would be a mandatory monolithic auction house all the way down on the, in the other extreme is pure lazy fair with you know no particular rules or expectations about outcomes, just a generalised competition.

So the options for thinking about how to design or construct or execute on a transfer market or any other end of IPv4 policy sort of most of them occupy this kind of space here on the right.

Another thing that we considered in the paper actually was a contrasting set of proposals which have emerged in the last few months. Which I just am generally calling the final reservation proposals. As you see down in the lower lefthand corner they are actually some version of that in all of the, almost all of the RIR communities at the moment and they represent some kind of, the creation of some kind of allocation space where the transfers would not apply. So, they can be arranged here on the same thing.

So, I am not going to go into great detail about the details of the, of either kind of proposals that are on the table now. Phylis presented a comparison grid yesterday, this is largely taken from that, it's slightly updated with a new ARIN proposal.

I am going to point out that the parameters which have been spelled out, basically most of them are not selfexecuting in the sense that I described in the, with the taxonomy, and I leave it as exercising the minds of how the factors or the changes would apply in this context. Again, in this  I did the same thing for the reservation proposals, a bit of a comparison. And if you actually begin to try to apply this taxonomy to the existing proposals, it's again it's subject to some question, you know, of differing opinions, but it would look probably approximately like this. As Phylis noted yesterday, the first transfer proposal that was considered by the ARIN community was abandoned officially a few days ago. Most people regard that proposal as one which was quite endowed with many rules and expectations, requirements and restrictions on both buyers and sellers and timing of transactions, things like that. It was quite an extensive set of structures. Now, there were good reasons for the authors of the proposals to consider those and in fact they aspired to preserve or to pursue quite a few goals in the in the period following the runout of the conventional address space and they sought to make those goals into their market transfer proposal. The only problem that I personally think, and I believe it played some role in the, in its ultimate demise is the absence of any mechanisms to  that were included in the proposal to make those goals especially realistic. I think this contrast is quite, is usually illustrated by the case Internet route registries, right. So Internet route registries are widely perceived to be full of inaccurate data. They are not used very widely, certainly not pervasively and all these things, basically they seem to be somewhat less useful than expected in their original design intend. Now, if everyone, every operator independently was very diligent and populating route registries with only timely data, only accurate data and did that on a very consistently all the time, route registries might be the single most useful technology who have been developed for the community in the last ten years or so. The fact that they, most people do not perceive them to be that way, may in fact be a fact related to this kind of taxonomy, that in fact they, in order for them to function in the current context, it really requires a world full of individuals that will selfexecute.

So, I really don't have anything else more of substance to provide in this talk, other than to put up a quote that actually emerged from the discussions back about ten years ago from /SKWRA*BG off rector. I will leave it at that time. Hopefully this telecommunications on me will be of some use for members to think about what would be the proper scope of consideration for transfer proposals or reservation proposals. If anybody thinks it is useful, I think that my colleagues in the science group would be happy to continue working on these lines and to provide updates or take input for where you think that different proposals on the table should be araid on the taxonomy. Again, if there is something useful, please let us know, and we'll keep developing it and with that, I will take questions.

Okay. Thanks.

CHAIRMAN: Thank you Tom. And now the transfer policy proposal

SPEAKER: Morning everybody. Now the moment you have all been waiting for and it's good to see so many of of you here this morning. So, this is the moment we have all been waiting for. I am not going to go too deeply into the details of the proposal. The people who are here right now have probably read it at some point and the people watching the webcast in western Europe right now must have read it because they have /O got out of bed at 6.

So, this might look remarkably similar to the presentation I gave in Berlin. It is has been updated and there is some additional stuff that I think is relevant for the discussion. It's attached to this presentation.

So, if you are looking for the second presentation, it's part of the first presentation, if you look it up at ROSIE.

Well, here we are. It's not, this graph is not as pretty as the one Tom just used. This also must be familiar. So where do we stand and where are we going to? This is what  well, the highlights of the original proposal, so it's only about allocated space. That's unused. You can only move it in between LIRs within one RIR. The moving of that space is either temporary or permanent. NCC to function as a clearing house. It doesn't get involved in conditions. It doesn't regulate.

Well, /THAET set off a whole lot of discussions obviously. So, we are now up to version 3 of the proposal. The text has again much improved. Thank you again Phylis for that. There is the moratorium has been suggested by Cathy earn son. The relationship with the current certification efforts is now and version 3 has demonstrated needs to the RIR in it. In other words, if you want to have out paragraph you still need to demonstrate need for that transfer space to the RIR. I would have put it in blinking, but I thought the better of that.

And this might be appropriate as well. We don't call it liquidity for nothing. If you go to the capital markets, you will see that if you have got too much money you have got a problem. If you have got no money at all you have got a problem, which is remarkably similar to the situation that we have got here in IPv4 right now.

Now, onto the good stuff. What I'm going to talk to you abouted to is the current market in IPv4 addresses. The picture is, well, it's a trader who is apparently not too happy judging from the graphs in the background. We are not too happy either. We thought it was important for, to show you guys what's actually going on behind the screens of, well, what's going on outside of these meetings.

Disclaimers: No address space was harmed, transferred, delegated, hijacked or otherwise utilised in a way that would not be conforming to current RIR community policy in the creation of this presentation, by us. It might have been harmed by somebody items but we can't accept responsibility for that.

The documented conversation was initiated by the broker. So, there are brokers for address space already. You didn't know that. I didn't know that. The discussion was entertained only to document what was going on. No NDAs or legal agreements were being broken. An NDA was never signed.

So, I hope this is readable. I'll read it out to you.

This is an actual email. This is a real email that Martin Hannigan received in November of last year. Martin has been around the block for quite a few years, especially before we had the RIRs and this is the email he got.

"Hello Martin. Through a colleague I have come to under is that you have you /PHAOUF access to unused or under use lighted IP blocks.

I represent a prospective buyer who is in the market to acquire several blocks. Class B /16 would be preferred, but we are willing to consider whatever assets might available.

Please let me know if you can assist us in identifying relevant opportunities."

Names have been left out to protect the guilty.

And this is basically what happened after that email. We entertained a discussion, legal services were to be provided by the broker and paid for by the broker. They would buy as many legacy /16s as possible. It's interesting to see that brokers are mostly interested in legacy space right now. They are not in a position yet to touch RIR space or try to stay away from it. But, legacy space is what it's all about right now. They don't worry about ICANN, IANA, IETF or the RIRs. These people were never been to our meetings. They are not concerned with filtering. They don't care about registration agreements. They don't care about routability or reachability. It is a verifiable company. It's a verifiable individual. So it wasn't a scam and I can say that the company, the actual broker is a company that's better known as a domain name broker. It was a simple process, typically completed in lest than two months from the first contact and /RAOEUR of the money. How much money you ask? I'll get to that a bit later.

What does that process look like for transferring that space? Well, execute the NDA. We set up a new holder company. You initiate a transfer request, so within your LIR, you say okay, I have got this address space, I have got this new entity that I want to move the address space to. The RIR starts requesting questions. Do you start answering them to whatever point that makes them accept your answer. You complete the transfer of that space and then you sell off the holding company. And then you change the point of contact to the new owner and that's it.

So, that's the way it's currently being done.

Now, how does that break down? Here is the price of an IP address, ladies and gentlemen. The base cost for whatever is on offer for /16 was 175,000 dollars or 137395. I don't know what the exchange is now: Legal fees, 35 percent market for the broker. 5 percent referral commission for whoever brought the deal to the table. We have got cost of capital. Just over quarter of a million dollars or 4 dollars and 23 cents per IP address or I think by now 3 and a half euros.

So what's the point? There is a market in v4 addresses. Whether it's legal or not, whether we like it or not.

Legacy blocks are being transferred out from underneath our feet and we need policy that reflects what's going on right now. We are not talking about the future any more. Money is in/TAOED changing hands as a result. And we need to improve our view of what's going on underneath our feet, so we need to improve transfer statistics.

These are the questions you should ask your local RIR:
What is the amount of transfer requests that you received?
How many are completed and how many are abandoned?

This reference material, this is the slightly anonimised headers of the email I have just shown new case you want to do any digging. Google might be able to confirm that this is an actual email. We have got the awe then particular headers, but we weren't willing to present this on  well, on the screen.

This is the graph that ARIN compiled for us last week. This is the number of transfers and the number of transfers that get completed. (Transfers) it is interesting to see how many transfers as a result get abandoned or aren't worked through. So it is apparently  it seems to be not entirely trivial to mislead the RIRs, which is I think of use.

So, that's one side of the story. So we have got these buyers of address space and I received a picture from an anonymous source this morning of this one with offering v4 space for sale. Let me tell you that this is a very toned down formality of this presentation. And we have chosen to just show you a few things and that we have ourselves sources, rather than go out and list name names and name IP blocks, because we could. It's out there. So better start doing something about it.

That's really it.

CHAIRMAN: Thank you.

AUDIENCE SPEAKER: Randy Bush: I am not disagreeing with you at all Remco, but I think what you are trying to do is take the blindfold off and say this is happening. But you know, we are currently driving the train into the brick wall. We are running out of the integers to tell. Whether we have blindfold on when we hit that brick wall or blindfold off, big deal.

SPEAKER: Interestingly I would rather take off the blindfold and see if we can avoid hitting the brick wall.

AUDIENCE SPEAKER: You can't avoid hitting the brick wall. We are running out of IPv4 free pool. We are. Believe it. I also like taking the blindfold off, but I don't think this is a critical issue to argue. Right. There are people in denial about T they are people who realise it. And argument doesn't seem to make much progress. I wish it did. But /TKPS

SPEAKER: Same here. This is I think the third RIPE meeting I am standing up here with essentially the same proposal and taking down objections one at a time. And I hope this will  this will convince the people that are selfassured that there is no market currently, we'll start to see otherwise.

AUDIENCE SPEAKER: Rob: Remco, could you put the slide labelled I think process back up. So, this has been an example to show that we better all take off our blindfolds and stop discussing whether we allow a market or not. There is a market. Whether it's good or bad, I don't know, but I find this very interesting that in this particular example, the transfer has been done in a little bit of a complicated way in order to get the registry in order. In order to get the transfer reflected in the registration database. So, apparently people still think it is useful to have an accurate registration database of the IPv4 space.

SPEAKER: It is also in the buyers and sellers interest that there is an accurate database of assets, if you are going to call it assets because duplicating an IP address is extremely simple. You just start typing. So, you create  you can create IP addresses, as many as you like but you better know for sure that whatever you are buying particularly, is actually what somebody else is owning right now.

AUDIENCE SPEAKER: So, I think for  it is for the good of the Internet to keep the database accurate.

SPEAKER: Very much so, yes.

AUDIENCE SPEAKER: So, I think we can stop all discussions of whether we allow or disallow or regulate or not regulate a market, because we don't have any tools to create or disallow a market. As a community of regional registry, we register the use of the address space, that's becoming more and more important if address space changes and is being used by different parties in these kinds of processes. So, I think we should start thinking about the registration policy, not so much a transfer policy.

SPEAKER: I completely agree with you there Rob. At the same time, well, we have been working on the transfer policy for a yearandahalf now because that is the maximum that we are going to get consensus on at this moment.

AUDIENCE SPEAKER: Randy again. What's interesting about this is what you are seeing is a complicated thing to get around the fact that the registry is not simply meeting its customers' needs. What's even more amusing on this one is there is a case where there have been in New Zealand, /24s traded where they qualified to get it from APNIC and it just wasn't worth the effort, it was easier to buy it. And that's just horrifying. I mean, that means I am not serving my customer base, as it were.

AUDIENCE SPEAKER: Was it the fact that it was easier or the perception that it was easier?

It doesn't matter.

SPEAKER: Perception is fact at some point.

AUDIENCE SPEAKER: Sorry, Daniel: This, let's compare this to the second slide you had about the policy, the one with the red blinking part, and before I do that I would actually like thank you you for being persistent and as you say, trying to take one objection after the other away until finally achieving things. I realise very well that you personally could just throw up your hands and discuss it and walk away. You didn't and I think you deserve a round of applause for that.

SPEAKER: Thank you.

AUDIENCE SPEAKER: So, in that vain, taking my question: I am not that tongue in cheek. The red blinking part, where does it fit into the process thing? My question really is: If we take as read that the process is really about the commercial transaction, isn't it likely that the commercial transaction will be agreed before this is started?

SPEAKER: Actually, in a reply to the renewed add node position on this proposal, which by the way, ETNO says that they are now supporting this which pleases me to no end. I have shortly described what I feel that that process should look like, and what it basically comes down to is that people looking for address space, just fill in the form as they have always done where  so you file your request with the NCC, and then instead of getting address space allocated by the NCC which can't happen because they don't have it, you get put on a prequalified list and that this should probably be public and so, then you have a list that will eventually hold all of the active LIRs as far as I can see that are prequalified to acquire address space which is an interesting list for people who are interesting in selling that address space.

AUDIENCE SPEAKER: So, it gets in front of the commercial process really?


AUDIENCE SPEAKER: So you try to get in front of the commercial process and that's a requirement, right. Otherwise it's not credible. That's an answer I take it  the thing that worries me about it is that something like that which was even more involved, but this is an essential element was just thrown out in the ARIN region and I don't quite understand  my concern is about the realistic, whether this is realistic, whether we can actually get in front of the commercial process or whether we will be at the process slide again where people will work around this and the NCC is basically an instrument and it being misled and it's all, we lose credibility. That's my worry. But I think your solution is a viable one if we can agree that it's actually A (in that we will  that it's likely that people will play by this rule and that, it's likely that people will play by this rule.

SPEAKER: Okay. Well I agree that any hurdle we set is probably going to chase a few people away from our process. At the same time, we need to have a process that everybody here agrees on.

AUDIENCE SPEAKER: I I am still strongly convinced that in the long run, it's  that it's crucial that we focus on the accuracy of the database. We should realise that whatever constructs you make trying to steer the, let's call it market, will be circumvented in men cases, but don't lose your focal point, the accuracy of the database. That should be, I think, number one on many list.

SPEAKER: I think keeping the database accurate is one thing do it for the webcast viewers I experienced an unusual accident on my righthand side.

Okay. There is basically two concerns here. One is that we keep our database accurate and the other one is that we don't have any competing databases springing to life.

AUDIENCE SPEAKER: To comment on something Daniel said, we haven't thrown out demonstrated need in the ARIN region. It's one of the things that our community feels incredibly strongly about, so...

The other question I had for you though is what we are grappling with is just trying to figure out to to move forward and get consensus, I wonder what your ideas on that would be in your region?

SPEAKER: I think we have, there is no market out of the way, we are pretty close I think but that's up to the chairs to comment on.

AUDIENCE SPEAKER: I got a question from max. On Jabber, who says why do people decide to buy the space instead of asking for an allocation which is still cheaper and possible now?

SPEAKER: Ask the people buying. I don't know. But they are.

AUDIENCE SPEAKER: Leslie. I just want to add a comment: Even if RIPE or the RIRs recognise that there isn't the possibility for them to regulate a market, I think that it's important to keep in mind that somebody might, entities might. And while it certainly needs to not distract from your processes, I think that you need to keep in mind that while focusing on keeping the registry information accurate, keeping the database accurate, you also want to be careful how you line up with entities that might think they can regulate such a market. So, that goes specifically to the question of whether, you know, you throw up your hands and say in policies, there will be markets and we will support them or whether you just say we are focused on keeping our database up to date. And I think that's fairly important terminology.

SPEAKER: Yeah, absolutely.

AUDIENCE SPEAKER: Rob: I want to make it clear that I fully support this proposal. I don't want to stop processing this and start thinking about a registration policy. Let's implement  let's accept and implement this as soon as possible and then start thinking about slightly longer term, registration policies which might or might not then obsolete this. I don't know. Peak

SPEAKER: And I'll be happy to work on that registration policy.

AUDIENCE SPEAKER: I thought it would be nice since I was one of the people who stood up and observed to this originally to just say at that time current, the changes that you have made have been very helpful and that I am supportive of it as well.

SPEAKER: Thank you very much, Mark.

CHAIRMAN: It seems we have no more comments on this proposal. You have been working on it for a long time now and all the objections seem to disappear one by one. So 

And I think if there are no more questions for this, then we can have an early coffee break.

(Coffee break)

CHAIRMAN: Please be back at 11 and we have more work to do. Now enjoy your coffee.

(Coffee break)