These are unedited transcripts and may contain errors.
Address Policy session at 11 a.m. on 2nd of November, 2011:
GERT DORING: So, welcome back everybody. Please take a seat. Welcome to the second session of the Address Policy Working Group. Still the same faces up here. This morning, we try to show you a video about the PDP, which didn't work out due to, well, technical difficulties, as it is always if you try to show a video on stage, it is not going to work, but Ops assured me that it's working now. I just have to press space bar. So we try to show the video now.
(Video playing)
(Applause)
GERT DORING: The magic of the moving pictures. I haven't seen this before but I am kind of impressed, it sort of summarises everything very nicely and much better than I could do. So well thanks to the NCC for producing this. It should help explaining how the PDP works.
So, now we try it again. So we have discussions to do. That is the agenda for now, the video is not on it because that was planned for the morning. First thing we do is discussion of the open policy proposal about the exchange points, and then some presentations and invitation for discussion and feedback, and we start right away with 2011 05, that is the proposal from Andy Davidson and actually backed by the EIX Working Group, Andy is here to sort of, like, wrap it up briefly and then take your questions.
ANDY DAVIDSON: Thank you so much, and thank you everybody for the opportunity to present the proposal that is being discussed right now.
As well as working for the EIX Working Group, I also represent Hurricane Electric so this is probably quite a special moment, this is someone talking about IPv4 and that is not going to happen very often.
Now, the reason that I have written an IPv4 proposal in the dying days of IPv4 availability, is because, really, even though IPv4 completion affects businesses of every kind and every size it actually, if it's allowed to affect the development of new Internet Exchange points in parts of the RIPE service region where there are no text today or it needs to grow, that will affect the quality of the development of the Internet in general, and much of the work that we want to do in the EIX Working Group is encourage communities to come together and self organise and build Internet Exchange points where one does not exist today and this proposal aims to preserve a /16 from the final /8 that the RIPE NCC will allocate from, exclusively for Internet Exchange point peering LANs.
The policy displayed on the screen right now, you can view this on the RIPE website or Address Policy Working Group, but the policy is completely open and there has been discussion on the mailing list, a large amount of support on the mailing list for this proposal. The mechanics of the proposal really are just as I have described, a moment ago; an Internet Exchange point will be able to request IPv4 for their own peering LAN use only, so that they can build an Internet Exchange point arranges ex I think change point that runs out of space because they have exceeded can get extra space by handing back their existing peering space so the pool is refreshed for future Internet Exchange points as well.
We conducted in the EIX Working Group a discussion at the last meeting where we looked at whether there are technical measures we could use to avoid having to do this policy which was using RFC 1918 space or some other unannounced space or v4 prefix exchange over v6 transport, which wouldn't work so this has had a rigorous technical appraisal and is now receiving a rigorous policy appraisal. The policy, as you can read on the list or the website and if there are any questions or anybody wishes to support or vehement Leo pose the proposal, now is a good time to raise the questions. Does anybody have any comments or feedback? It's quiet, which is either really good news or really bad news.
AUDIENCE SPEAKER: Which will half grave, I am an Internet Exchange point operator, and I support this proposal. We need this space safeguarded for Internet Exchanges and for the future development of the Internet. Thank you.
AUDIENCE SPEAKER: Max, Amsterdam IX. Less than one year we did migration from /23 to /22, for peering networking and now we see that we already allocated near 80 addresses from, so we support this idea.
ANDY DAVIDSON: Great. Well, it's been discussed in other Working Groups and it's been discussed and we have been receiving support on the mailing list right now so the normal policy process is in action and if there are no further comments but you wish to make one privately you can always find me at lunchtime.
GERT DORING: What we have seen on the mailing list is an amazing number of people supporting this, which is something I am happy to see, and we have some feedback about the wording to be more explicit about things that are sort of obvious to an exchange point operator but might not be obvious to an IPRA, having never seen an exchange point yet, so there will be text actual changes, but since I don't see anybody here jump be up and down shaking their heads, screaming at the microphone I think we have sort of clear guidance on the mailing list, there was really strong support. Wording changes and then we go ahead.
ANDY DAVIDSON: OK. Thanks, everyone.
GERT DORING: Thanks for coming up here.
(Applause)
So, we are actually way ahead of schedule, so you are in for an early lunch today. (You are in). Brought something to my attention in, all the other regions, the topic of transfer policy seems to be very, very hot, and in this region, nobody seems to care or maybe we don't have a problem here, and to be able to understand whether we are just missing the boat or whether we just have no problem, I ask Dave to sort of report what is going on on a global level on transfers and he volunteered to do that.
DAVE WILSON: I am Dave Wilson, you may recognise me from such committees as the ASO Address Council this. Isn't an Address Council matter as such because it's not global policy, but Gert asked if I could give a summary of the status of transfers in other regions, so I enlisted their help in getting data together for this and I am very grateful for that help.
Like Gert said, most RIRs do now have a transfer policy in their regions, and there are some variations between them as befits the region in question. And attention has started to turn to policies which allow transfers of address space between RIRs or really between the members of each RIR. And this kind of thing I think doesn't necessarily actually need a global policy. Strictly speaking a global policy is one which impacts the IANA procedures and this doesn't, it's a decision for each to decide itself whether it allows address space to be transferred to an organisation outside it's service region, we could take that unilaterally. I am going to put two matters on the table now, what the other RIRs are actually doing and that discussion has taken place and I will cover this over the next few slides but the second is a discussion, what should we be doing, if anything. These aren't global policies like I said but some of them are globally coordinated which is a buzz word that means it's a policy that is dependent in some way on the policies in other regions. It doesn't hit the IANA and go through the whole formal process but some regions allow transfers out of the region if and only if the destination has a similarly equivalent policy. So this could impact us and we should probably be aware of what these characteristics of these policies are.
So let's start with ARIN. ARIN already has a transfer policy which applied it in its own region, much like ours, it is needs based and when I say that, I am using it as shorthand for to transfer addresses it still requires some analysis by the RIR itself, you can't hand it over to someone in exchange for cash or beans or something without some sort of oversight.
So there is also a new policy under discussion in ARIN at the minute which would allow transfers outside of the ARIN regions. Now, this has a restriction and I will quote that; "inter regional transfers may take only only via RIRs who agree to the transfer and share compatible needs based policies."
This comes from originally it was a proposition 119 in ARIN, which is a globally coordinated policy proposal. That is something that doesn't touch IANA so doesn't need to go on to the ICANN conveyor belt it does in principle fend on other RIRs and the thinking here obviously is assuming the policy is adopted, they are willing to have transfers outside the region providing it's not going into some new policy framework that is very, very different.
So that is ARIN.
Next up I have APNIC. APNIC has also a transfer policy in place and it does allow transfers to other regional registries. It's a very interesting construction, actually; it's worth reading. It uses APNIC's own policies for the local part of the transfer process and it explicitly mentions counterpart RIR policies for the remote part and that one has already been adopted. That doesn't actually enforce a needs based requirement. There is a policy there internally which I understand or needs based policy, which I believe is due to expire once the final /8 is reached in the region, which I think it already has, so the change for that is there is another proposal on the table which had consensus declared ton last night, as it happens, which will maintain that needs based requirement on an ongoing basis and that, I think, is one of the reasons why that was brought up, was because of the ARIN policy, they decided I think it was worth considering being compatible in some way with that.
Third one: AfriNIC. I couldn't find any adopted transfer policies in AfriNIC, I don't think they are there yet. Thereof been two of them under discussion this year. Both of them, as it happens, address transfers outside other region and one of them was quite limited in scope and required some oversight and that has already been withdrawn. The other, as far as I could see, was still technically in discussion, and is much, much more liberal. It is still in a draft stage; now, I think it's due for the next round of discussion at the meeting later this month.
And of the four other RIRs, let's have a look at LACNIC. LACNIC does a transfer policy, it doesn't cover Inter RIR transfers but they have been talking about in in some detail and there was a panel at the LACNIC 16 last month which is very interesting; I wasn't there myself but I one of my colleagues on the ASO was kind enough to summarise in some detail what went on. There were three interesting points at that; one of the things that came up on the panel, there seems to be a feeling that transfers are going to happen, whether we like it or not, and it is very important in, that context, to keep the registry accurate, so of course this means if the regional has policy that stops the database from being kept up to date, perhaps we will see private registries filling that point. Fears were expressed about the LACNIC region itself being prejudiced by big blocks of IP addresses transferred out of the region and there was an interesting response to that: The IP address per person count in the LACNIC region is quite low compared to other RIRs, .4 addresses peruser, which means if someone tried to transfer addresses out of the region, there isn't a lot of give to do that. Address space inside the region has very high strategic value, and one panelist noted there seemed to be more out of region blocks announced inside the LACNIC region than the other way around and that was a point of view I hadn't thought of before myself.
The third thing is fears were expressed as we see in every region, about the formation of an IPv4 market for the highest bidder and interesting and perhaps troublesome because the economic power in each region is different. The response to that, there should not be a free market but there should be a regulated market.
So in conclusion, I said there were two interesting matters here; one is what the other RIRs are doing. The other is, now, I am open to having discussion on this, what should we do about this, if anything: We have one region that allows transfers as long as the target registry, regional registry, has a needs based transfer policy, and we have another region that, to my eyes, anyway, appears to be adopting a needs based transfer policy imminently, it looks like it's quite close, partly because of that. Our own transfer policy, and I haven't gone and asked for a judgement from other regions for this but to my eyes, it has a needs based element to it so it probably doesn't need to be changed. I do wonder if anyone feels constrained by that, if we should make sure that doesn't go away for this reason or any other.
Second thing: Do we need to do anything special inside our region to accept space from our RIRs? That is actually not clear to me. The APNIC policy has a very interesting construction that builds around this.
The third question I want to pose and I am not going any particular answer here: Should we be thinking about transfers ourselves? Is there wisdom in allowing RIPE Internet registries to transfer space out of the RIPE region? With that, I am back to the Chairs, thank you.
GERT DORING: Thanks for summarising this and maybe I think we should touch the questions one by one. Could you start with the first question again. You are not going to get away from there any time soon.
DAVE WILSON: So, the first one I raised here is our own transfer policy, has a needs based element to it, and I did wonder if the way transfer policies are going in other regions, if anyone feels now constrained by that or if we should make sure not to take any changes to that or any reaction like that?
Remco: Address Policy
GERT DORING: And the one that brought us the transfer policy, thanks for that.
Remco: Brought you transfer policy. It would be good to reiterate the limitations, the quite explicit limitation we have in our current transfer policy which basically only allow you to transfer unused allocated address space from one LIR to another, so and that wall, that wasn't initially in the policy proposals but that is what we ended up getting consensus on. It might be worthwhile revisiting those regardless of whether we are going to be transferring to other RIR regions. So, I think it would be good to have a look again at where we are right now and see if we some of the some if we currently have in place could be lifted. So it's not just Inter RIR, that is not possible right now. There are a whole other bunch of other figures that are not possible right now.
ROB BLOKZIJL: Private individual. I always have had problems with any kind of restrictions on transfers. I have the strong feeling that once we ran out of IPv4 address space and we entered the period where there is still a demand, maybe even a growing demand, for IPv4 space and when there are bits and pieces available in the private hands of people, transfers will happen are whatever rules and regulations we make. If we make it very complicated then people will just lie to you or not inform you, even, and if you make it very lightweight, people will find specialists who can phrase their request in such a way that they get what they want, and I think, as a community, we have only one very strong requirement on transfers, that it is reflected in the registry, we want to keep track of where addresses are, and not how they came there, because in the IPv4 world, we have a rather interesting, complicated history of how addresses have been distributed over the whole lifetime of IPv4, and I think once the distribution basically is over, with a few exceptions like for very special purposes of the very small last block, once that is over, we should think about we enter a new world, and that is the world where keeping track of what is being used is more important than trying to impose rules where you know they will be broken. But I won't take away too much time from my presentation, which comes after.
GERT DORING: We have 15 minutes more time for this, actually, since Andy was so quick.
ROB BLOKZIJL: So to summarise, I urgently call for a sense of realism in this area.
SANDER STEFFANN: So, but if I understand Rob correctly, if you go in the direction of removing those restrictions that would mean that we cannot receive address space from the ARIN region, so we /TKEURPBG we have to consider that. That is a new restriction that they are imposing then.
ROB BLOKZIJL: Yes, that is why we have five regional registries and have local flavours of how we do policy, and I think it's not necessarily the case that we are obliged to follow policy which we think is not realistic. Yes, if, then, certain moves of address space, I think it will happen anyhow, from the ARIN region so our region if there is a real need and people will find a way to get around the ARIN rules.
SANDER STEFFANN: Then we are going into interesting situation where we are registering blocks that ARIN is still registering because they are not not transferring. I can see some problems here, but let's let's discuss that later.
ROB BLOKZIJL: These are very detailed individual cases, I think we should not make general rules based on hypothetical concerns.
AUDIENCE SPEAKER: I would like to remind this room, you may or may not have seen it, but a sizable block of legacy address space was transferred in the Netherlands last week, I think it was about a million IP addresses, which is technically outside of the transfer policy that we have today, and I don't know exactly how the men an /EUBGS work behind that transfer, it must have been very interesting, but I think, in general, we consider this to be a good thing because it's legacy space moving into our system of addresses that we can then move around. So, again, I am not going to argue pro or con needs based, but there are we should be thinking about lifting the other restrictions that are in transfer policy.
AUDIENCE SPEAKER: I am Paul Wilson, head of APNIC and I will make a few comments. I can't speak for our policy development process so these are really personal observations, having watched this process for some time, so thanks for the report. You did state very well what has happened at APNIC which is the change, the recent change of our policy which was went through the final consensus stage last night and was approved, which reapplies the standard needs based requirements on the recipient of a transfer, and that was done in my view, in my observation, precisely because the situation in ARIN; anyone in our region who is looking at the prospects for transfers is looking for transfers from other parts of the world because obviously we have got very little address space slack in the region and the ability to get those addresses from other parts of the world is obviously the question.
I think APNIC was being unnamed but blamed for a kind of the impasse in the ARIN policy process and we have done ARIN a great favour by allowing the ARIN policy discussion to continue on the issue itself rather than on the sort of roadblock about the unnamed RIRs not compliant with needs based so there is now much more active discussion on PPML about the pros and cons and whether or not the ARIN community actually wants to go ahead in their own right without the kind of the excuse of this other factor.
So, I mean, there is no doubt about it, for Rob's benefit that the policy change that we made, I think was made precisely in recognition of what was happening in other regions.
As for this idea of that was the first point. As for this idea that a needs based allocation requirement on the recipient will sort of constrain the market or push it into push things into the black market, I don't buy it at all. The needs based system that we are applying is exactly the same as the one that we were applying to normal allocations, and that we have done that for years and years. We have always acknowledged that there is a cost to the needs based demonstrated needs requirements but the cost is reasonable and I think our members have dedicated have demonstrated that consistently, that they are quite happy, they have been quite happy to demonstrate their need and to go through the process and get the addresses that way so if that was really such a roadblock, then we would have seen evidence already that the black market was happening as a result of the prior demonstrated need requirements, you know, we didn't have that evidence that we were pushing a whole lot of people into doing off the book transfers because of the burden of this demonstrated need, and so I don't think anything has changed between last year and this year in that respect. That is in the short term at least. We don't know what is going to happen down the track, if a v4 transfer system or market becomes very active, the v4 address space becomes very fragmented and we get a hell of a lot of new transactions and who knows what. In the long term things might change but at least in the short term in terms of the pragmatics of being able to actually receive addresses, as I said from the ARIN region, that change was made and I also don't think from, a personal perspective, that there is any demonstrated risk in pushing things into a black market because of having made that concession. Thanks.
GERT DORING: OK, I am you and then I am cutting the queue on the first question because we have two more.
ROB BLOKZIJL: I just want to make a short remark to Paul Wilson's remark about how happily people followed the needs based requirements in allocation. Well, that is quite easy because you were the only one who had the bucket of address space and either they followed your rules or they didn't get stuff, but we are now talking about the situation where a party A and a party B might reach agreement of shifting address space and then suddenly a third party says no we have this funny requirement. I think it is slightly different but we can take this off line.
GERT DORING: I would appreciate if we could take that specific bit off line, either among you or on the mailing list.
AUDIENCE SPEAKER: I am speaking as an individual. I would like to know and understand the role of ROAs in these transfers?
GERT DORING: Well, certificates are an interesting subject. Basically, the idea is that if we implement it here, the certificate and subsequently the ROA would reflect the status of the registration in the database, so if you haven't registered in the RIPE database, you get a certificate and with the certificate you can give yourself a ROA, so if you don't register it, no ROA for it.
AUDIENCE SPEAKER: So it would be easier to track down where the prefix are?
GERT DORING: Yes. To wrap up the first question, I think we should indeed revisit the transfer policy and with whatever comes out of it. I would welcome a volume tier to work with that. I am not sure if Remco wants to do it again. He is coming to the microphone but he still has scars from the last time. So if somebody else volume tiers, I think Remco wouldn't mind.
Remco: I have pills that make me sleep at night. I think that before anyone starts to write up a new policy proposal, whether that is me or somebody else, I am dodging that subject very intentionally, we should get some guidance from the community on which restrictions they feel are there unnecessarily and what we should look at lifting, before we write up a policy proposal or have that go around in an endless circles, which is something I remember from back in 2007.
GERT DORING: That would be sort of start with the discussion and then write the text, yes.
AUDIENCE SPEAKER: Just James Blessing from Limelight. Just on the topic of proposals, do we actually need an inbound transfer something to cope with transfers coming into the region as Dave mentioned? I defer that.
Alex Le Heux: Tricky question. The only truly correct answer is it probably depends, but there have been various projects between the RIRs in the past to transfer the legacy space between them, and depending on the details of how this is going to be implemented, it might work under something similar like that, but then again, it might not.
AUDIENCE SPEAKER: So actually to the answer to the question is yes we do need a policy proposal to deal with inbound because there isn't a definitive answer? There wasn't a definitive answer, yes it's all sorted out?
Alex: I think it depends on how the transfer is going to be implemented on the other side as well but there have been transfers of legacy address space inbound without a policy, and so if it could fit under these principles, then we wouldn't need a policy but I can imagine there could be a situation where we would.
DAVE WILSON: The way I would like to state that is, is anything broken? Before we decide if we need need to fix it. I am not sure anything is but my eyes miss these things.
GERT DORING: I think that was James brought up your second question again. Do. We need an inbound policy and I would, since this is the answer was not so perfectly clear, actually, I would like to put an action on the NCC to see whether you are happy with what you have or whether it would help you to have sort of written down something that the community agrees on. My gut feeling is that since we are not giving anything away, just taking and documenting, we might not actually need something, but this should be checked more closely. Thenar up to the last question, do we want to have a transfer away policy? And, yes, any words on that? I think we can spend five minutes. So a few comments on do we want to spend discussion cycles and everything on a transfer away from the RIPE NCC region policy? There might come up indeed the need, like European company having a daughter company in the APNIC region and deciding to transfer and properly document addresses to their daughter company, so even if we think it might be unlikely, company relations do exist so, it might happen, so James?
James Blessing: If we are going to have a transfer policy, it should have an international between IRRs option between we have divested ourselves of another company and so potentially we would have moved some address space outside of the region, so it's a useful policy if transfers exist
DAVE WILSON: Thing in some way the situation of a holder of aaddress space changing hands or part of a holder of address space changing hands, I almost see that as a corner case. It's something that is clear and we can probably all agree on the right thing to happen there. The business of the substantive base bis of a transfer policy as I see it, is where you have two unrelated entities one wants to sell space and one wants to buy it, and I think we have to think hard about this one, and I think if we come up with any conclusion that is not yes, just let them, then we have to think very hard, can we stop it? What is the RIPE NCC selling that is so compelling that people won't do an end run around it?
GERT DORING: Well said, thank you.
ROB BLOKZIJL: I think the only thing the RIPE NCC, this community, is selling, is a properly maintained registry which is being used and will be used more and more in the future to take routing decisions, to take all sorts of decisions, and we should make the threshold to get into that system, as low as possible, and so, I think we are exactly on the same level here. It's in everybody's interest, as we keep track of the address space, and any obstacle we construct in having complicated transfer policies, A, people will not keep to it; and B, we have no instruments to enforce it; and C, our registry becomes less and less valuable.
GERT DORING: I think I see a clear need for more discussion on the mailing list and then, based on that, come up with a proposal to both do the local transfers and the off RIR transfers, or maybe not, depending on what the discussion brings up. So, thanks, Dave, for that. Thank you for your input. And actually, it's now Rob again with slightly different topic.
(Applause)
ROB BLOKZIJL: Good afternoon. I have no slides, so nothing can go wrong there. I will be very short because I have almost no voice left. What I have been doing, together with some people from the registration services department of the RIPE NCC and with assistance of one of the technical writers of the RIPE NCC in the last couple of months, is basically try and transplant ourselves in time, let's say, one year or two years, forward, so in two years from now, all IPv4 allocation policies are historical because there is nothing to allocate any more. There might be a little bit left, which we have reserved for very special purposes, but the bulk of our current IPv4 policies deal with allocation from the free pool. That is no longer relevant in two years from now.
What is relevant are these small exceptional special purpose policies for new start up ISPs, for starting or growing Internet Exchange points, maybe for people with green eyes, I don't know what we can think of further, but what we are left with is a few remnants of IPv4 policies hidden in this big bulk of allocation policies and the registry.
So I thought, wouldn't it be nice if we have one single document that describes the IPv4 registry and the remaining few policies which are still in place. Policies like, as I mentioned, special allocations from specially reserved blocks, transfers and maybe a few others.
While developing this idea, going through all the existing policies and just cutting and pasting anything we thought might be relevant still in two years from now, that was an interesting exercise because, one, not much of our current policies is still are still relevant in two years from now because they refer to allocation from a free pool, which is over.
Secondly, we have always been very careful in phrasing our policies, but all our policies have been developed in splendid isolation, so when you take the pieces of text and try to incorporate them in one document, you find textual problems like same words have different meanings in different policies. Some very small details of different policies contradict each other. You can imagine it is not one fluent flow of text which can be easily understood. So hence, we asked the RIPE NCC for the good services of one of their technical writers to go after we had done the collection of what we thought should be still valid in two years from now, to make one consistent document of that. Very interesting; at many times in the recent past, we thought, OK, now we are there, we have collected everything and ready for a first round of wider publicity, then plop, a new detailed policy appeared, so we thought, oh, we will wait a few months and then we can incorporate that as well.
Well, I think we are now at a stage where, like next week we will go once more through the document to see what has been reflected this week in the discussions, see whether we can, as good as possible, incorporate that, and then I will publish it on the policy Working Group mailing list. It will not be published as a policy proposal; we want to do one round earlier, we want to have your input, A, do you think it's a worthwhile exercise; B, go through the text and say, ah, you missed one obscure policy which we adopted 27 years ago, and/or C, yeah, but you changed policies, which shows that you would be an atentative reader, because we had to introduce new, well I find policy always a very difficult word; procedures, because nowhere, basically, have we formulated the role of the registry. We have sentences in various policies that says that, and this should be reflected in the Whois database, which is defined nowhere, or this must be registered. How? Where? Not specified. So we spent quite some effort in trying to give a more formal definition of what the IPv4 address registry is, which automatically would also apply to IPv6 and AS numbers.
So that is new and please, read that with attention.
Another thing that is new, by focusing on the central role of the registry in IPv4 address usage two years from now, it became less and less clear where our current transfer policy is an aid or an obstacle in keeping the registry in order, so I took the liberty of slightly rewriting that and most of the reasons and the discussion took part five minutes ago here, but when you read this document, keep in mind this is not the defining document for a transfer policy; this is the defining document for the maintenance of the IPv4 space. You will also see that it makes basically no longer any difference in principle between IPv4 address space allocated from the RIPE NCC free pool, be it PA or PI, and there is no special role for legacy space because I will tell you in five years from now, you will have a great difficult job explaining to newcomers in this field, ah, this IPv4 address may look like very much that address, but this is a green one and this is a blue one, and next week, I will explain the yellow ones (one). At the end of the day we have one network and we have which runs on address space, and on the level of the network, it's all the same. How you received it, that has been changing over the 25 or so years when it has been in use, but that should not reflect itself for the next generation in simple administrative tools like a registry. There is one address space that should be administered in one uniform way, that makes life a lot easier for you, for the administrators, the RIPE NCC who is spending, I think, an undue amount of resources in keeping all this fine tuning in place, whereas an address is an address and it should be treated in the same way.
So, I am coming to the end of my message. My message is: Keep on eye on the mailing list. By the end of next week, you will see a first version of what of the result of what I tried to explain here, and read it very carefully, but don't read it with saying, I am the great specialist in PI space and that is not treated fairly here. You are all should put up your new set of reading glasses, which is the v4 part of the Internet two years from now, five years from now, and forget about things which are extremely important and current today and ask yourself: Is it still really crucial and important in two years or five years from now? And but, I would very much like to say yes, that we come up with one document describing the full spectrum of issues related to IPv4 space. Thank you. Questions? Remco.
Remco: What a surprise. I strongly support your effort here. I think to add a bit more: We all have heard of old regulations from centuries gone by that, for some reason, still stayed on the books, so in some places in the world you can still get arrested for holding hands in public, wearing a white shirt on Tuesdays, or taking a donkey into the town square after midnight, which are all completely insane at this point in time, but it had a valid point at some point in the past. IPv4 allocation policy will be the same thing a few years down the line, and I would strongly encourage us to clean it up and get most of the old stuff out of the books as soon as we don't need it any more.
ROB BLOKZIJL: Thank you.
AUDIENCE SPEAKER: Rob's idea that we should not make very much difficult rules for the transfer policy, I mean if you want to get use of the IP address only real thing you need is country of the RIPE NCC basically so if the company has no intention to make a new registry go to the registry when they can simply just use IP themselves so there is no reason for them to do that, so simple thing is, we need to make them have their intention to register their information in the database because the last thing we want is, when the database is really mess up is oh, use for information that the registry become valueless with IPv4. So making the transfer policy as easy as possible so every company, when the IP change hands, every company have intention to register their information in the database will be extremely important for everybody here. Thank you.
ROB BLOKZIJL: Thank you.
GERT DORING: Any other questions on that? So, Rob, thanks for undertaking the enormous work of sorting through all these different bits and pieces of text.
ROB BLOKZIJL: And thank you to the NCC as well.
GERT DORING: And thank the NCC for helping Rob with that, because it's an enormous work.
(Applause)
For you, stay tuned, the next will be on the mailing list. I have seen it already but, yes, as I just heard, new bits are missing since we keep changing the policy behind Rob's back. So much for that. And now, we move back to IPv6 land, or forward, or whatever.
The IPv6 Working Group had a discussion on renumbering yesterday, and do we see Shane somewhere here? He is hiding somewhere in the back. I asked the IPv6 Working Group chairs to sort of bring back the results and so we could do a more educated policy depending on how renumbering is, and I have the fear that this will be a short item.
SHANE KERR: This won't be too long of an item. We had a brief discussion yesterday at the IPv6 Working Group, I presented some of the work that is going on in the IETF and we had some discussions about how that relates to both technology recommendations as well as policy recommendations. At this point, there is no output from IPv6 Working Group. There is no specific recommendations. What we are going to do is go to the list and have the discussion there about both of those issues, about what technology recommendation we can make for network operators to make renumbering easier and things like that, and to kind of try to future proof their networks as well as some of the issues and maybe also identify external resources, apparently there has been a great deal of work in other regions for this issue, but then we are also going to try to make some specific policy recommendations, so, for example, under which circumstances saying that renumbering is painful for you, maybe are worthwhile justification for IPv6 PI and which circumstances it doesn't make sense. We don't have those recommendations now but the idea is we will have this discussion on the IPv6 Working Group mailing list and hopefully be able to provide those. I don't know what the time frame is, but hopefully by the next RIPE meeting we will at least have something more specific to say as advice to this body. Any questions?
GERT DORING: Yes, thanks for giving us an update on the current state of affairs. I might have been a bit quick on why I think this is important because in all the PI discussions we have had, one side of the room always said, we must use PI and the other side says you can just renumber when you change providers. And the just renumber bit is, well, depends very much on who you are and how your network looks like, so having a bit more factual background on how hard it really is, should help us have less heated policy discussions and more based on experience, so I certainly welcome the effort that you are taking and I well, of course, all of you are free to join the IPv6 Working Group mailing list and help drive this forward. So thanks.
That was indeed quick, so you will have an early lunch today. Next one, handing over to Sander.
SANDER STEFFANN: Yes, so we want to summarise a bit and show you what happened to proposal 2008 08. This has been a very interesting one. At some point in time, the community wanted to do something with the certification stuff, so the Certification Task Force was started, had many discussions, the NCC got a budget on their activity plan to start developing stuff with this so we could get experience and see how it worked. All the discussions took a long time, as you can see from the number of proposals, started in 2008, and the end result was that we almost had consensus, we were in the final days of the last call, when concerns were raised about do we actually want this certification, what are the consequences, what are the possibly dangers? So, what then happened is that we are now in a situation where the proposal was withdrawn because we could not reach consensus. The NCC already has developed a big system showing how it works, people have been using it, so the situation is a bit unclear now. We had an initial policy on how to start with the certification, it got withdrawn. The NCC AGM is discussing this later today, to see if they still want to continue spending budget on this, so we are now in a situation where there is there is a system, the AGM might decide to continue or not to continue, and it's actually very unclear what the community wants because we don't have any proposal on it. Looking at the numbers, there were actually quite I think the last number I had was 700, so 700 organisations actually using the system developed by the NCC to try it out, to test it out. While at the mailing list the discussion was very quiet. We heard people who were (out) afraid of consequences. We didn't hear anybody speaking up for the certification system. So, yes, I just want to make this a situation clear to you: The RIPE community has no policy on certification, the NCC is voting on it in the AGM later to see how they want to spend their money, and that is the current situation where we end up now and I am really curious about how people feel about this. Don't we care what the NCC is doing? Are there people who say yes, it's a difficult subject and haven't spoken up but I really want the system? We have already seen people who had some opposition to it, so I am curious what you think, what should be done now. Can we, just as Working Group leave it rest?
ROB BLOKZIJL: For clarification, one of your sentences said in the RIPE NCC is doing something but we don't have policy. That sounds like there is a bit of anarchy in the NCC office. Absolutely not the case. This whole certification thing is an IETF standard very soon, and part of the standards is that you produce something which is called certification practice statement, which, in great detail, describes basically your policy. So, actually, we didn't need this whole story because we have a document describing much more detailed what the policy for issuing certificates is. That is published on the RIPE website under ripe.net/certification. You can look at certification or practice statement and it is there.
SANDER STEFFANN: This policy explicitly said which resources are being certified. That practice statement is being followed, etc. Yes.
RUEDIGER VOLK: Deutsche Telecom and only few people will be surprised to hear me from me, I want RPKI, I want it for all resources as soon as, as soon as the relationship to the holders can be certain and I would like to I would like all operators that see a need for having this, queue up and say "yes, we want it."
(Applause)
The additional remark is that, well, kind of a part of the outcome of the Icelandic saga is that, well, OK, kind of the community manoeuvred itself into a situation where creating detailed influence on how things are handled, got somewhat lost and that is really a bad thing, and we will have to figure out how to cure that again.
SANDER STEFFANN: So can I see this as as you volunteering to take up the policy proposal for this? Just asking.
RUEDIGER VOLK: If need be, yes.
SANDER STEFFANN: Thank you. If needed.
ROB BLOKZIJL: Again, for clarification, you don't need a RIPE document saying certification policy. It's in the CPS. It's there, documented.
SANDER STEFFANN: OK.
AUDIENCE SPEAKER: Personally, I think that the RPKI system is techically not in a way that we should roll out right now, but, still, the efforts in building so the general direction is not that bad, so the idea to build a system that is able to issue RPKI is good and RIPE NCC should continue doing that, but we should not go forward and issue our right now, because there is no good way to implement that right now, and there are strong issues that, from my point of view, is right now a major show stopper, and if people will start out rolling it in the architecture like it is right now, then this may cause major problems later on that cannot be fixed easily and that is why I think we should not issue ROAs right now but make the technology and have that ready once the technology is right to roll out.
SANDER STEFFANN: I am not sure
Nigel: Nigel Titley, RIPE NCC board, and also one of the authors of the RPKI policy of 2008 08. I would like to make a small clarification: We actually have a clash of policies here, because the transfer policy requires blocks to have to be digitally signed before transfer, which implies the existence of an RPKI system, so here we have two policies which conflict with each other; in one case, we have the community giving us a mandate to go ahead and do certification; on the other hand, we have no consensus for 2008 08.
SANDER STEFFANN: In the past, there was a specific request to the NCC to do work on certification. NIGEL TITLEY: And it's been in the activity plan for five years. The motions that are before the general meeting this afternoon are an attempt to try and get us out of this particular quagmire and at least get us to the end of this year when we can have a look at a new activity plan, and the motions are there are two possible motions, one of which requires the RIPE NCC to throw away the RPKI work entirely; and the other motion would keep the RPKI system but throw away or at least switch off the ROA generating facility, which would seem to at least render it harmless, as far as those people that are opposed to the 2008 08 are concerned. Just a little bit of explanation of what is happening this afternoon.
SANDER STEFFANN: And if both motions are not accepted, then NCC continues as it is doing now?
NIGEL TITLEY: It continues as it does now, yes. And if motion one is accepted, then obviously motion 2, the result is discarded.
WILIFRIED WOEBER: As you said, there was nobody speaking in favour of RPKI during the first round; I think I tried to do that at the very beginning of my contribution and I would like to do the same right now in this context. I do think that digitally signing, certifying the fact that a party is the rightful user of a certain resource, is a good thing, and I am perfectly convinced that this is going to be in the future, one of the core services of the RIPE NCC, so with that in mind, I fully support the creation of certificates for the resources. Coming to the question of policy and coming to the argument of, well, we don't have to do anything because the IETF has issued some RFC. The IETF has done quite a few RFCs, not all of them are automatically applicable to the operations of the RIPE NCC, and so I do think that there would be a very, very good case for developing a policy statement with regarding to handling this RPKI system for certifying resources. However, if we go into that direction, we really have to do a little bit more than providing more or less an empty shell, pointing to another document which is not part of the policy development process, so I think the community should actually go ahead and try to find out what to put into the policy as a mandate to the RIPE NCC how to properly do that. The RFC business is something to find out what the format of assertion is and that sort of things. I really defer to the IETF with regard to that one, but I would really like to see this community to make up its mind what the RIPE NCC is expected to do in that particular case.
(Applause)
And the last thing, this is not trying to bash anyone or anything, but with my leg halfway down in the security mess, I didn't read the most recent version of the CPS; I read, probably, the end minus first one and minus second one and I have to state that the quality of that document would not stand in the security environment as a CPS, so, but this is just a formality; this is nothing to stop that to go ahead, but I think we should really acknowledge the fact that keeping track of a piece of resource in a database which we sort of soldered together and bolt together and run, is a different thing than deploying digital signature environment. There is a community out there which expects a certain form, a certain quality, a certain level of detail, describing what you are about to do, so with that in mind, I fully support this and I am going to vote in the general meeting in favour of this. I don't think it's the proper place to, right now, discuss the issue of the ROAs because we are in the policy thing. Thank you.
RANDY BUSH: IIJ. Since this culture seems so obsessed with process and rules, what the hell has a CP got to do with address policy? Why was it even here in the first place? It's not about address allocation at all. Number two is the CP is about the certificate, right? And what I think it was Wilifred just said, you know, certificates are the attestation of who has what address space; it's not about the ROAs, right? I think my lesson in take away from this week, is that those of us who have been working on this technology, have been very bad about education because the misinformation, the confusion and the bullshit is just amazing, OK? But 2008 /8, I don't know what was doing here in the first place. It's a CP, it's not address policy. And why you are discussing it now, I do not understand. It's not address policy.
SANDER STEFFANN: Are you suggesting to move this to the NCC Services Working Group or something or?
RANDY BUSH: Whether you do the RPKI is clearly a question of NCC services. What policy you are guaranteeing when you issue certificates, is not address policy; that is probably something that comes from your Board. It's saying what you were legally guaranteeing by your actions, though unlike Wilifred I am not an expert in that particular area and I would bow to other people's wisdom. I am sure Steve Kent is here and that gentleman standing there ain't too dumb, either.
AUDIENCE SPEAKER: I have a question from a remote participant: It's from and he says "RPKI models the need for hierarchical system using the wrong technical solution. I would like to step back and think again about the use cases and the real requirements before choosing a solution."
AUDIENCE SPEAKER: Richard Barns, BBN. So to follow up on what several people have said about whether there is a need whether there is properly something to discuss in terms of address policy. I wanted to make an analogy to another security technology that was recently deployed by the RIPE NCC. RIPE has a database and they have an http access to this and they turned on TLS recently, protection for that access. And when that was done, it was discussed in the database Working Group as part of the operation of the database, as an additional security function on protection for protecting the information in that database and how it gets transmitted to relying parties. So I think there is a very strong analogy as Randy suggested, perhaps the NCC services this would be much more appropriate to treat as a question of what security services we apply to the information we are already having. There is not a change to policy; it's a question as to how information is protected, given it's already here.
SANDER STEFFANN: Sounds reasonable.
ROB BLOKZIJL: I agree with most of what Randy said, except we are discussing it here because it ended up here but I fully agree with him, it's more appropriate either in the NCC services or maybe even in Database Working Group as part of the registry. I always hear feel that people do not understand exactly the role of the NCC in all this. The NCC is keeping the registry and the certificate only says that this instance of this number block is the one that is kept in the registry. It doesn't say by whom. If you want to know more details you look in the registry. That is all. What you do with your certificate (doesn't) that is your choice. You may generate a ROA, the NCC can help you there but you don't need to use that very soon from now. You can do that locally. You can say "I don't want to ROA but I want to use it to prove that when I'm selling part of my address space next year, that I have something to sell." Yes. And you can see might think of other things, but that is all your certificate holder, decision, and what we are should be discussing here is the role of the NCC, the activities of the NCC in this complicated thing, and it's very simple: They issue certificates. Now, do this do this Duncan experiment: Tonight, the members say stop all this nonsense and then in a couple of months from now you all have downloaded the latest and greatest version of software in your routers and there is something new, secure routing button oh, I like that, you press it and it says oops it only works if you have a certificate or a ROA, basically. Only works if you have a ROA and in order to generate a ROA you need a certificate, so you go to the NCC and say, "where can I get a certificate?" They will probably say "not here." This is a business opportunity for somebody to start issuing certificates.
SANDER STEFFANN: That doesn't sound like good me.
ROB BLOKZIJL: I am just telling some of the consequences of ill thought decisions.
SANDER STEFFANN: If I look at the responses from the room now, I see some opposition to the ROAs and about risks there, I didn't hear opposition to the certificates themselves, maybe about the technology, so I think maybe it's not as bad as we think. We should discuss if we need a policy for this and in which Working Group we might need it. I heard some voices already on that. So I propose we see to that and it's actually looking better than I expected. So thank you all for your feedback.
(Applause)
GERT DORING: So thank you for the lively discussion I am quite surprised because we are perfectly in time for lunch, I expected us to end 20 minutes early. So it's good if we actually ask for the time be given the time and make use of it instead of letting it go unused so. So I am happy to see that. That is pretty much everything for today. I have some more remarks about the general meeting today. In the general meeting, we have a new charging scheme on the table which formally is not something the address policy Working Group has to say anything about, but, of course, the charging scheme attaches monetary incentives to certain numbers and that sort of like influences address policy and is influenced by address policy. So, without saying whether I like every details or not, I would urge everybody of you who is representing an NCC member, to go to the general meeting, look at it and decide whether you like the new policy the new charging scheme or not, and vote accordingly. Yes, that is pretty much it, AGM is today, voting can be done electronically or in person. And without further ado, thanks for being here and for your input and enjoy your lunch and I hope to see you back again tomorrow at 9 o'clock.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE
1