These are unedited transcripts and may contain errors.
Address space Working Group: 2nd November 2011, 9 a.m.:
Address Policy Working Group 2 November 2011 at 9 a.m..
CHAIR: Good morning dear Working Group. Somebody rang a bell and told me I have to be in here and there is some Address Policy going to happen.
What should I say? I am glad to see that so many survived the social last night. I am not so happy to see that a fair number of people got lost on the way. It was definitely more full yesterday.
Anyway what that means, you are the hard core of people that really want to work on policy and that's better than just sitting here and reading e mail.
By the way, you might have noticed that the 5 gigahertz Wi Fi is switched off right now. That's because ops is trying to figure out where the packet loss problem is coming from so they turned off the RIPE Meeting A network for diagnosis, something will happen and everything will be fine on Friday morning, I think.
So, let's get started. This is the Address Policy. So if you are interested in test traffic, you are in the wrong room.
This is what we are going to do today and tomorrow. In this Wednesday morning time slot, first of all, we will have couple of presentations to sort of settle the background, give you an overview of what's going on, sort of get in the mood. Then discussion of open policy proposals. After the coffee break, more discussion of open policy proposals and a couple of different presentations on policy related topics and possibly future work items for the Working Group. Tomorrow morning we will come back to the subject of IPv6 PI and PA unification and try to find a way forward on that. And then there is the policy hour and aob.
Going into details of this, we are right in the first item A : Administrative is the issues and the agenda bashing. One of the important things is of course thanking the scribe, so I'm not exactly sure who is taking notes right now the good folks from the RIPE NCC over there, thank you very much. I know that it's really hard work and you are doing a tremendous job. Thank you.
So, back to the agenda. Administrative stuff first, then Emelio with current policy overview, what's happening here, what's happening in other regions, what are hot topics. Then Emelio again giving us some more insight into what's happening in the policy development office at NCC and handing over to Alex on our policy implementation. So this is basically for those not working day to day with policies and with these two, give a bit more insight into what they do and how we can make their life better or miserable or whatever. I haven't seen the presentation yet but I am curious what will be in there.
And then we go into discussion of the policy proposal 2011 4, which is an extension of minimum size for IPv6 initial allocations. Basically it increases the 32, 29 proposal.
After the coffee break this is what I plan to do. Start with discussion of 2011 5, which is the IPv4 for exchange points proposal. And then we have a talk about inter RIR transfers, from Dave Wilson. Some ideas from Rob Blokzijl on how the IPv4 Address Policy should look out after runout or might look like. Then we have some feedback from the IPv6 Working Group on renumbering. And before lunch break, some wrap up and summary on what happened to the proposal 2008 08 on RPKI by Sander.
Tomorrow, as I said, PI/PA unification. I have sent a proposal about that last Friday to the mailing list, and I think it would be very helpful for the discussion if you could all at least briefly skim through it, do some thinking on your own, what you think should be the result and about the technical details, because the overall thing is quite simple and the devil is in the details.
We will discuss all the details tomorrow.
Then it's Open Policy Hour, so if you have anything that's sort of not yet ripe to be a former policy proposal but you want to bring it up, that's the place, and we still have time left, so just approach Sander or me.
As a matter of introduction, I am so impolite this morning, I am sorry for that. I am Gert Döring, I am the Working Group Chair and I have a co chair, Sander Stefan. If there is anything about Address Policy you want to discuss in private, just approach one of us and we will see how to move forward with it.
So, agenda bashing: You have seen the agenda now, is there anything I want to see changed? I don't see anybody coming up, so that's with we try to keep to.
Minutes from last meeting: Again the NCC has done a wonderful job in writing this all up, what we discussed here. The minutes have been circulated to the mailing list and I think I saw one small comment which has been fixed. If nothing else is missing or needs correction, and I don't see anybody jumping to the microphone, then I just declare the minutes final and we go ahead with that.
So, current policy topics. Now you are rid of me again and Emelio takes over.
As a matter of introduction, if you don't know him yet, Emelio is the good soul at the RIPE NCC who has to keep up with everything we do like make it all comprehensible wording, make sure we all deliver on time and do all the nitty gritty day to day working related to policy work while we just throw around the ideas. So thank you, Emelio, for all that and the stage is yours.
EMILIO MADAIO: Good morning everyone. Emilio Madaio. I come from Rome, Italy and I work as a policy development officer at the RIPE NCC.
The presentation I am going to give you today is the usual presentation I give at the RIPE Meeting, an overview of what happened in other RIRs, in other RIR PDP, mostly what kind of policy proposal completed the other RIRs PDP in the time frame from RIPE 62 until today. I also talk about some of the proposals that completed the RIPE PDP and some that are active without entering much into details, you will have the proposals themselves presented and eliciting discussion in the Working Group today.
So, to start, I would like to go over one topic still covered by the policy makers in the other regions and one is the IPv4 depletion. I will start with two examples of community that actually are doing didn't do anything new about it simply because they already started implementing their exhaustion policy. And these are APNIC and the ARIN community. APNIC started using their exhaustion phase policy when they start using the final /8 of IPv4, starting instead their implementing exhaustion phase policys in they received the last /8 block from IANA in February of this year. I don't want to add much details on this one. In the APNIC region now they are allocating up to a /22 to new entrance and IPv6 deployers. In ARIN region they set aside a /10 for IPv6 transition and they also reduced the allocation period to three months.
Something new happened instead in the AfriNIC service region and in the LACNIC community. In the AfriNIC version 4 of the soft landing policy, as they call it, reached consensus at the latest AfriNIC meeting in Transania. I presented this proposal in version third, I presume there was still some talks. The condition that allowed the community to agree on the text was basically related to the usage within the AfriNIC region of the IPv4 address resources and more specifically AfriNIC resources are meant to be used within the AfriNIC service region. Any usage outside the AfriNIC region should in support of connectivity back to the African region itself.
In the LACNIC region instead these two proposals reached consensus and will end up their last call of the LACNIC PDP until December 5. The first one is a modification edition of a sentence in the section 11 of the LACNIC policy manual. Makes mandatory for every requester of IPv4, the registration of IPv6. So, if a requester doesn't have IPv6 already, he must request it in order to obtain also IPv4.
The other proposal is the gradual exhaustion proposal as they call it. It was accepted by the community at the meeting and there are many conditions to describe this proposal. But mainly a /12 will be reserved and as soon as LACNIC would not be able to satisfy an IPv4 request because the pool is depleting, this /12 will be used to allocate and assign resources under some conditions like, for example, the resources the IPv4 address received must not be transferred within 12 months. After the receiving of IPv4 Address Policy, it will not be possible to make another request within six months, and these are the main points of this policy.
Another important topic is the IPv4 resource transfer must be specifically IPv4 inter RIR transfers. In RIPE 62, I mentioned a couple of proposals that were still in a draft stages that tried to describe the role of the AfriNIC in a scenario where AfriNIC resources were meant to be transferred from one organisation to another in two different regions and one of these regions was AfriNIC. They didn't reach consensus in AfriNIC 14. One proposal was withdrawn and the other proposal was reconsidered by the proposer and will be discussed a new version in the coming AfriNIC 15 meeting.
In the APNIC community instead, this proposal "Maintaining demonstrated needs requirement in transfer policy after a final /8 phase" received consensus and I presume ended the last call today. So, according to the LACNIC PDP now, the Working Group Chair will decide to move it forward or not depending on the feedback in the last call, move it forward means to have the board analyse the community feedback and ratify the policy if the consensus is confirmed.
The policy itself is self explanatory, they are going to maintain the need base requirement in order to allow transfer between two organisations.
In the ARIN region, there is this draft policy "ARIN inter RIR transfers" that reached consensus in the last ARIN meeting at the middle of October, the AC decided to modify furthermore the text of the draft policy considering the feedback of the community in the mailing list and in the public meeting and move this text to last call, the last call will end in 16th November, as I wrote here. And there is still some feedback that the Advisory Council, the AC will have to consider in order to make the decision on how to move within the ARIN PDP framework. I presented this proposal in RIPE 62 with another title, there were some rework on this proposal, but it reached consensus at the meeting.
And this is what happened globally, what is happening regionally. What the RIPE Meeting has been busy with. This is the list of some of the proposals accepted recently. 2006 05, the PI assignment size, and I will give some insight on the PDP implementation in this proposal as an example in my next presentation and also Alex will give you some consequences and some highlights of the policy implementation itself.
This other, 2010 01 is a temporary Internet number assignment policies, approved in August. It's a clear policy that I did a new section and improved the way the NCC will assign resources for a temporary time frame.
2011 03 is the post depletion IPv4 address recycling. I will get into more detail later. This is a policy that touches a policy proposal that touched the final /8 policy we had already in place actively and approved by the community.
These are two proposals with 2008 08, that the Working Group Chair will describe more later.
And the 2010 08 is the abuse contact information, was withdrawn soon after the RIPE 62. The proposer decided to withdraw it and reconsider the scope of the proposal, reconsider especially the special abuse contact task force that was going to work on a technical level on the same problems that this proposal highlighted and I can report that yesterday in the Anti Abuse Working Group meeting, it was announced that a proposer would be submitted to the PDP and it would be discussed in the Anti Abuse mailing list.
2011 02 is another policy proposal that will change the way we assign PI space in IPv6 and the Working Group Chair will give you an update on that. It is in last call, actually ended the last call and a decision will be announced soon about consensus or not.
2011 01 is the global policy proposal for post exhaustion IPv4 allocation mechanism by the IANA. It was approved by the RIPE community. I don't have time to describe better what is the global policy development process, but most of the RIR completed the PDP on this proposal. The same text was approved by the APNIC region, by the LACNIC community and the AfriNIC community and I presume that the board of the AfriNIC community also ratified the proposal.
We reached consensus and now we have to wait for the ICANN board to ratify the final part of this global discussion. In the ARIN region they reached consensus at the public meeting at ARIN 28. They moved to last call. In last call there were some recent feedback from the community, and the last call ended today, so some news on this will come up very soon.
2011 04 and 2011 05 are two very recently submitted proposals. One covers again IPv6 policies and the other one relates to the implementation of the final /8 and some assignment for, in order to allow some assignment also for IXP during the final /8 phase and on this one you will hear the proposer explain in support and ask for discussion.
Here you have the RIPE PDP document itself so how we implement the policy making process in the RIPE community, and I will go much into details focusing on the principle of this document in my next presentation. The current policy proposals are available at this link, although I'm pretty sure you all already know it.
And this is, these are my contacts. The PDO [at] ripe [dot] net is the official e mail used for submitting policy proposal. I read this e mail also to answer questions, give qualification, you you can contact me at that e mail. The other one is the Twitter account that I usually use to update on policy matters, and to keep update also the community through the Twitter sphere, I usually like to follow back the community that decides to follow me.
And having said that, this was just a brief presentation. If you have any questions.
I will move on so...
So anyway, my next presentation, when it shows up it will be clearer is about the PDO activities. We have received the input from the community to explain a little more the PDP itself and at the NCC we decided to change the angle of the presentation. Instead of giving you just a lecture for a lack of other words, of information that you have already available in some brochure outside on the website, the explanation of the PDP, the PDP deadlines, the different phases, we decided to reverse the perspective and give you some practical example of what we exactly do. We are opening here the doors of the NCC a bit, and describe what happens in the PDO office, what happens in the policy implementation session of the registration service and how we coordinate among each other and with the community.
And in order to do so I will go through some of the principles of the RIPE PDP document that is the RIPE 500 I mentioned before. I will give you an example of something I am going to announce to the community soon. Another example will be a project that I am learning at the moment that still covers policy and policy change and I will emphasise some points of the PDP like the impact analysis in this case before handing over to Alex, will tag along and describe what's the next step after a proposal is approved and how we implement it according to the result of the PDP.
So, RIPE 500 is the policy development process in RIPE. It's based on three main principles. The bottom up process of collaboration, simply because policy are created, modified, updated by the community itself. So, whoever participates to the mailing list and to the policy discussion can make a real change.
I will highlight how this principle manifested in some cases in some of the activity. The transparency is guaranteed by the fact that the NCC is responsible for archiving all the policy discussion, the current one and the past one and all the policy proposal documents, the different draft policy, current one and the past one.
The openness is guaranteed by the fact that actually the RIPE community at large is all the Internet citizens who have interest in collaborating and have interest to give a contribution to the policy making process within the RIPE NCC service region.
In order to screen better this principle I will also have to go through some media support. So there will be a kind of surprise here, a video that we'll have to show you.
Something new is a new perspective that we are going to use in our presentation at the moment.
So just to give you a first example. The archive update. At the moment we have an archive of all the policy proposal that completed the policy development process in the RIPE community. These archive supply to date and I would like it to be extremely accurate for you, the community. And at the moment I have this special situation in 2009 01, this global policy proposal was accepted by the community in August 2010, and never made it to the ICANN board for final ratification. For a specific situation where this proposal was approved in a specific version in this region, it was approved in another version in another region. What I did was a solution that I found and the Address Policy Working Group Chairs agree with me is to add an extra note in the archive to explain better the situation. The impasse we have now is that basically we have a policy proposal that is accepted and that will never be implemented.
So I want to adopt this solution that to me is the one with the least impact. And adding this extra note that then you will read in the archive. I will explain that although it was approved regionally, globally, it never made it to the ICANN board and to the ICANN board ratification. For more information, obviously, you can see the ICANN announcement, they put an update on all the global policy proposal active in the different PDPs, and I will announce in the mailing list that will I will do it and I will update the archive in this sense so that you will know what happens.
Another activity I am busy with is the cosmetic surgery project. I will not go much into the history of this in more detail. I want you to know the status at the moment. What we see is relevant to do next. And how this example and the previous one matches the RIPE 500 principle that sometimes gets overlooked. So this cosmetic surgery project can be explained in the definition itself. It is a project, an activity led by the NCC, by the PDO. It is a surgery in the sense of an intervention on the policy, so it's going to change the policy in the RIPE community. And it's a change only at a cosmetic level. So we are going to change the text. We are not going to change the policy itself, the policy concept and the work we do. We are not going to change what you have to expect from the NCC and from the other community members. We want to change only the readability of the policies, to help you use them and to help you understand them better. It was a problem presenting in RIPE 57, in RIPE 58 the RIPE NCC presented a project plan to fix this issue, basically these are the details, I want outline, to say there is a time line and it's basically flexible. The Address Policy Working Group Chair will overlook this. We'll give the final approval on the craft that we will make that the PDO will make before publishing to the community in the main Address Policy mailing list and that work will be reviewed by the community and approved at the end. There are six documents so far in the included in this project. The implementation started in RIPE 59 and this is where you can find when I am talking about all the announcements, in the past, also the past drafts that we published and that were approved. The status of this project: At the moment we already had published the RIPE 596. It was the first interesting exercise, there was a kind of a test bed of the project, and we had to go through two versions because the community saw in the first draft a change to the policy themselves, not only a textual change and that is a positive feedback in the sense that it was clear that there was a distinction between the PDP, the process that the community used to change the system and the cosmetic surgery project that is meant only to touch the text, only to improve the readability.
One of the changes that we do in the cosmetic surgery project was perceived as too deep and, therefore, was removed from that and was clearly expressed that if somebody wants to follow this, he has to go and submit a new proposal to the PDP.
The second version of the draft reached consensus, there was a review phase and a last call and we can publish the RIPE 496.
At the moment we draft and publish a merger of these three IPv6 documents. We received some feedback and we were ready to publish the new draft. What is going on at the moment, however, is that the same documents and specially the first one is undergoing the PDP with some other changes. So basically the cosmetic surgery project cannot work on a stable policy document. On purpose I put the RIPE 512 because that was the identifier at the moment, I published the first draft. That document is obsolete now. During the performance of the cosmetic surgery project, that document changed so we had to synchronise a bit the two activities of cosmetic surgery process and policy development process and I personally gave more priority to the PDP so that whatever changes is inherited from the PDP goes to the cosmetic surgery and no conflicts are created.
This situation is lasting a little too long. So with the Address Policy Working Group Chair, with Gert and Sander, we agreed in moving on, putting on hold the cosmetic surgery project on the IPv6, the community still wants to consider more on the policy concepts and move on the other two documents that are in the list of the project. One is the IPv4 policy document and this is going to be worked and reworked. Apparently many times in the foreseeable future.
So we will start with the other one: The RIPE 302 policy for reverse address delegation of IPv4 and IPv6 address space in the RIPE NCC service region."
If I recall correctly, it was approved by the community in 2004 and since then has never been touched or no one expressed intention in modifying it. Therefore, we will prefer to work on this one that looks like a more stable, and I will announce in the policy Address Policy mailing list that we will work on that so everything I'm saying now will also be published in the mailing list to let all the community know.
And before moving forward, these are two examples, the update and the cosmetic surgery project of the transparency of the PDP and the bottom up process of collaboration. The transparency, as I said before, is meant to give everyone the accessibility of the documents we are discussing and the discussion themselves. Improving the occurrence see of the archive, we will improve obviously the transparency that is mandated by the RIPE 500, by the PDP themselves. The bottom up process of collaboration is guaranteed, manifested here with the cosmetic surgery project because changes in the RIPE policy can be validated only by the community, so even if we were tasked by the community itself to change the policy text in the policy system, we will have to go through your review and your last call and your analysis of the changes we are going to introduce.
So, before moving on, I would like to share with you this new video that maybe most of you don't know, but there was a tutorial video and all the tutorial videos on the RIPE website that described the PDP and I decided to update it and make this new video that is available also on YouTube, it's 3 minutes and 15 long and it gives you a first impression of what a PDP is. Obviously you will not be so knowledgeable after the video, but sure you will know better the details and some key terminology to understand better how the PDP evolves and works for you. So...
(Video shown)
It was meant to last only three minutes, maybe it will take longer.
There was a technical problem, so I cannot make the Premier for you. However, we would like to spend a few words on the colleague who helped me on this one, they are from the training service department and the communication department, so you can find them here. I know that Pedro is watching us online. The other ones are all here. Here they are. Pedro was the technical officer involved in the video. I invite to you watch it. It's available on our website and also on the RIPE NCC account on YouTube.
Moving on. Something that you would have seen in the video, and it's actually well described in the RIPE 500 is the Impact Analysis and I would like to describe a bit the role of the Impact Analysis.
In the policy development process, we start with an initial discussion on a policy proposal. That initial discussion gives the input from the community in the intention to go forward and make the proposal a policy or change the proposal in a certain way or withdraw it if there is a strong rejection of the intention of of the proposal.
After this initial phase, we move to a review phase, there is further discussion with more input and we publish a draft policy so that the policy proposer can assume the shape and the form of the real policy and the community can read and see the proposal as it was already a policy. Plus, we publish the Impact Analysis. That is the NCC staff assessment of the proposal. We work in a what have scenario where the proposal is already a policy and we try to highlight and describe what kind of consequences and impact we will have if the proposal received consensus and is then implemented. On so many levels, first of all we make clear what we understand of the policy proposal in order to make sure that you know what we see, what we read and you decide if some correction must be made.
Obviously we have an analysis ready to the impact on the registration service. We highlight if we see that the address consumption and aggregation will change. There are also some sections related to the operation service, how we will have to adapt or change the activity we have in the NCC if the policy goes through. There is always a legal contribution in that, what is the legal impact of the policy proposal? Usually we talked about Address Policy, address management policy, IPv4 and IPv6 policy. It's possible and I will make an example, that some policy proposals are related only more to other aspects, likes for example, the RIPE database and so I have to involve other departments of the NCC in this activity. I lead basically the Impact Analysis, there is a co ordinated effort to compare different views on the same policy proposal, and included is that document for the community to read and appreciate.
And these are some sample cases would I like to mention.
2010 06 involved the RIPE database, because it was the proposal on the registration requirements for IPv6 end user, and I had to involve the RIPE database not only on the Impact Analysis level but also the implementation level. They took charge of the implementation when the proposal was accepted.
2011 03 is another good example of transparency and and it was between the nation and the NCC. I called it a clarification addendum to the last /8 policy which was 2010 02. In that policy we published in the Impact Analysis that we were going to implement the policy in a certain direction with a certain interpretation. The opposite interpretation was still possible and valid, but we couldn't read any hints in the proposal of what was clear, what was really intended. So we assumed that the direction was the one we published, and more specficially, the last /8 policy described how the RIPE NCC was going to allocate address space when doing it from the last /8 block available. Nothing was said in relation to the all the IPv4 address space that eventually will return to the RIPE NCC for whatever reason. So, we didn't know how to use that IPv4 address space and we published that we were going to include it and distribute it according to the /8 policy.
At RIPE 62, again, talking about the policy implementation and the fact that we were going to implement this last /8 policy, sharing with the community again this interpretation already published in the Impact Analysis and therefore implicitly approved by the community when the 2010 02, the last /8 policy was approved, some community members agreed with the interpretation and preferred to have it, although at a policy level, well confirmed by the community and therefore submitted a policy proposal that went through the PDP gaining much support. But, however, it didn't change actually anything in the sense of policy implementation of the activity we will have. It didn't change the way we will distribute address space during the final last /8 phase. It just clarified better how we were going to do at a policy level and it is an extremely good example of how the Impact Analysis contributed, clarifying some idea and the community was receptive to this and improved also the policy framework itself.
The last two examples I am going to make now is 2011 01 is the global policy proposal that I said before in my previous presentation was approved by the community.
And basically what happened here is during the Impact Analysis we saw that there were some points not very clear. The policy proposal described what IANA was going to do. So we could only read what we understood were going to receive from the IANA, and so actually the real implementation one was not on ours, on the RIPE NCC. It was on the IANA. So therefore we just published an Impact Analysis that described what we were expecting. In order to have a clearer idea and help the community make the right decision, I had the privilege to collaborate with /AR I say goer I can and Louis God order, I would like to thank because they were very helpful in providing me an extended Impact Analysis, as I like to call it. Basically the IANA staff assessment on the global policy proposal that I didn't clue in the Impact Analysis because it's just an NCC effort. I posted in the mailing list in order to have the community completely aware of what was going to happen. And this is, again, and is a good example of coordination, collaboration and transparency in the policy making process on a large scale, not only regionally for this specific case.
2006 05 is instead a proposal that was accepted recently and it's also, very quickly, was implemented by the RIPE NCC. It is the PI assignment size. I will hand over to Alex for more details on the policy implementation itself but in terms of policy development process implementation, that was a good example of how some clear direction, when the new proposer takes over after sometime from RIPE 60 after some clear direction from them and after some good feedback from the community this proposal went straight to consensus and the implementation was clear and quick and more on the consequences on the proposal from Alex in his presentation later.
With this, I finish. I know I may have been a bit confusing sometimes but I am available for questions now and that's also my e mail, so if you want to contact and know more about the PDP.
Something I would like to highlight. Something that happened in the last year, sometimes there were questions in the mailing list relating to the PDP or someone was saying something incorrect about the PDP. The community itself corrected this and this is a good input for me. It means that we are promoting, we are sharing the PDP and the PDP process in a correct way because the community is becoming more knowledgeable on this important tool.
I am finished.
CHAIR: Thanks, Emelio, for that and are there any questions directly on this? Okay. I don't see any questions. I think we tried to get the video going in the coffee break and then try again with the video after the coffee. And then we hand over to Alex now.
EMILIO MADAIO: Thank you.
(Applause)
ALEX LE HEUX: My name is Alex Le Heux, I work for RIPE NCC registration services. I will pick up a little bit where Emilio left off.
Emilio told you about the development process of some of our policies and I'll tell you a little bit about the implementations that then follow.
Not all policy implementations are equal. Some of them are easy and quick to do. Others are not so easy and quick to do.
2006 05 was a proposal that was a long time coming. It was first proposed in 2006. So, we had sometime to prepare for the arrival of it. It concerns the setting a minimum assignment size for IPv4 PI space if multihoming is an issue, and the implementation mostly consisted of updating our external documentation, changing the registration services internal procedures, and updating the training materials for our training team.
It was finally accepted as a policy on October 20, and six days later, there was even a weekend in between, we announced the implementation of it. So that was very quick. Which was good too, because I think minutes after the it was announced on the mailing list that it was accepted, we started receiving requests from people who wanted assignment on Address Policy.
2010 06: That's a little bit more elaborate. It created a new database status for IPv6 assignments, deaggregated by LIR, which is for ISPs to register their IPv6 address pools for things like DSL or cable customers, and it makes it a lot easier to register this because under the old policy you could read that policy in such a way that all the assignments should be registered individually or you could read it that it should not be registered at all and it could be done in different ways. This would make it hard for the LIRs to know what to do and once an LIR would request an additional allocation, it would make it difficult for the RIPE NCC to verify that they would qualify.
And this policy just says you have registered your address pool so you don't have to register all of hundreds of thousands of DSL customers individually, and the object line would contain all the information we need to verify the utilisation of the allocation.
There is kind of two phases on the implementation of this. The first phase was well, both phases were kind of start immediately after the policy was accepted but the first phase of course was updating the RIPE database software to add the new status so that LIRs could actually register this. And the second phase was involved more creating the software and the procedures for registration services to then actually process this data. For IPv4, we have been processing additional allocation requests for quite a few years already. And over the years we have built various software tools that help us decide what the utilisation rate is etc., etc.
For IPv6, we haven't yet done many additional allocation requests, as you might imagine. And even before this proposal came, we were already thinking about how to deal with these requests if they start coming in. And this proposal made everything much simpler for us and put us in a clear direction where we should go and how we should deal with these things.
2011 03: Is yet another kind of policy implementation. In the original last /8 policy, there was one small point which was open to interpretation, and when we published the Impact Analysis on it, we discussed this point as well and the next RIPE Meeting after that we discussed the point as well and the address policy Working Group gave us some guidance on how to interpret that point and at that meeting, it was also decided that the policy text should be cleaned up and this proposal was the result of that, which cleaned up that one point. And the implementation of it was basically not doing a lot of work, because the point had been cleared up already and we updated the policy text on the website, or Emilio did that, and that was basically it and once we reached the last /8, we have a clear policy and will know what to do with that.
Then there are proposals like 2007 01. This was accepted in October 2008, and it concerns contractual relations, contractual requirements for direct assignments such as PI space and AS numbers. It required all new assignments to be, to have assigned contract either with us or with an LIR, well between us and the LIR and the end user of the assignment. It also required all existing assignments that we made over the year to be eventually covered under a contract as well.
Now, setting up the documentation, providing the creating the legal documents and updating the procedures for all new assignments, that was fairly straightforward. The existing assignments, that was of course a little bit less straightforward; we are talking about over 30,000 assignments made over the last 10, 15 years. So reaching all these people and getting them all to sign a contract is a little bit more work than your average policy proposal, and we are still working on this. We are making very good progress. There will be a presentation on this as well in the NCC services Working Group if you are interested in the details of where we are exactly.
So, this shows that every policy proposal is unique when it comes to implementations. Some of them we can almost start implementing already when the proposal appears on the mailing list. Others we really have to wait until the final moment. Some of them we can implement in days and some of them it takes ages.
Moving on. The last few RIPE meetings I was here talking about rough edges of the current policies. Over the last years, we have been working hard, both the people in this room and people like Emilio, publishing Impact Analysis reports and things like that, and I am quite happy to say that there is not actually that many rough edges any more. There is maybe one or two but they are actually under discussion in this very meeting as well, so I'm sure they are going to be resolved as well and I am very happy to be able to say that.
So, that left me a little bit with a gap of things to talk about. So I came up with a few other things.
Just like we are going to be processing IPv6 additional allocation requests from our members, the IANA will eventually be receiving additional allocation requests from the RIRs as well. So, just like us they are working on their procedures to process these requests.
Now, the global policy for IPv6 allocations states, amongst other things, that reservations that is do not expire in the coming three months are counted as space that is in use. And it also says that each RIR region can set its own reservation strategy. Now the IPv6 policy doesn't offer very clear guidance on the reservations. It does imply strongly that any subsequent allocations should, if at all possible, be an aggregatable block with the previous allocation. So, we have been making reservations in IPv6 since the beginning. Right now, what we do is we employ a binary chop mechanism for a /32 allocations. That basically means that we have a block, a large block set aside for /32 allocations and each allocation, each new allocation that we make comes from the middle of the largest block of free space there.
The result of this is that for as long as possible, each of these allocations will have the maximum amount of space to expand into.
We are not doing this for all allocations, because if we would take our entire /12 and start doing this strategy on the entire /12 for every single allocation, rather quickly, we would be unable to make any very large allocations in the future, and we have no idea what v6 policy is going to look at in five or six years, so we are not doing this for the entire /12, just to make sure that should there be a need in the future to make very large allocations, we can still do this.
Now, for allocations larger than a /32, we reserve three bits. So if someone receives a /31 allocation, we have reserved a /28 so that allocation can be expanded up to eight times. Now we haven't been doing binary chop, we have been doing that we started doing that fairly recently, so, there are quite a few /32s that also exist in 3 bit reservations.
We have not yet expanded many of these allocations, but that's only natural because v6 deployment is only starting only getting started. Eventually we expect to have to expand quite a few of them. And we're not sure yet how far we will need to expand them and how often this will happen. We have seen in IPv4 where we used to make reservations many years ago, that it turned out that many LIRs actually never came back for their reservation so at some point we stopped doing this. In v6 we are still unsure what's going to happen there.
So, our intention here is to keep doing this, and evaluate the practice and also the reservation that is we have made in three years time, because then we should have a bit more experience with how this is going. It's possible we still, in three years time, decide that we don't have enough experience yet and we can then continue doing this or perhaps we have a lot of experience then and it shows that we should be doing something else.
Are there any comments on this?
CHAIR: Either everybody is happy or everybody is reading their e mail. I would go for everybody is happy with it.
ALEX LE HEUX: Okay. Good.
The run out fairly policy which shortens a it progressively shortens the allocation period from two years to one year to nine months to six months and currently we are in allocating address space for three months. Now not every policy, in fact many policies will never be directly visible in statistics, but something like this should be visible in our allocation statistics.
So, I decided to look at the numbers. Now, these numbers are not very simple to get or to process, because there is quite a few effects that complicate things, because LIRs tend to be quite a promise queues lot, they merge, they split up, they do all sorts of things, so when two LIRs merge the allocations are moved to one of these LIRs and the allocations that are moved may not be fully used yet so that new LIR will then still be filling up that address space and this makes it very difficult to figure out exactly how long an allocation lasts in LIR before they need a new allocation.
Also, making an allocation and determining the size that it should be is of course a kind of predicting the future and while we have a good crystal ball in the office, it's still not perfect so some allocations last a little bit longer, some last a little bit shorter.
And also we have a minimum allocation size. It's currently a /21. Is used to be a /20 and even a /19 before that and there are quite a few smaller LIRs for whom a /21 is enough space for a long time. It's just policy says that we can't allocate smaller than a /21 so these LIRs will get a /21 which may then last longer than the minimum allocation size.
So the result of this is that the absolute numbers that I find are maybe not entirely accurate, but the relative numbers comparing what's happening now has been happening over the last year to what happened years ago, they should tell a story.
Now, in summary, in Jan 2010, the allocation period went from two years to 12 months.
Then in July, it went to nine months, then in Jan this year it went to six months and then this July it went to three months.
Now, I haven't used the data from the last few months because the actual duration lifetime of an allocation is, it's a distribution and if I would use the data up to today, we'd miss half of that distribution and that would produce some very weird results.
Now, this graph shows, on the X axis we have the date that we made an allocation and on the Y axis is the percentage of those allocations that have not been followed yet by another allocation. Now, as you can see, even going back ten years, about 40 percent of the allocations were never followed by an additional allocation. At first I thought that was quite a high number. But then I dug into it a little bit more and it turns out that that about one third of our allocations are the minimum size, the /21 and there are quite a few companies in there that may not be using that /21 in three months time or in two years time even.
And looking further, about half of our LIRs have only one allocation. So, given that, this number doesn't seem so strange and of course you see that it gets higher the more recent the allocation is, which is only natural because if you received an allocation yesterday, it's unlikely that you would have already received another one as well.
So, if we plot the actual lifetime of the allocations, going back a few years. You can see that while the allocation period was still two years, the lifetime was, the average lifetime was not quite two years but close to two years. And then going into the future, the lifetime of the allocations becomes shorter and shorter. So this means that the allocations that come later have actually been followed by an additional allocation in a much shorter period of time, which is exactly what we would expect. You can also see that there is a little bit of a delay there because of course if the allocation period drops to six months, we won't be able to see that effect until six months later.
Together with this, we should be making more allocations. Now, the rates by which we make allocations is influenced by quite a few things, for example new members as well, they have no additional allocations. So here the effect isn't as clear and as pronounced but you can still see that the number of allocations we make her month is going up as well.
The other thing that should be happening is that the size of allocations should be getting smaller. And the blue part here are the /21 allocations and the red above part are /20s etc., and as you can see, that the size of the allocations is also shifting downwards. Because there is of course nothing smaller than a /21 because a /21 is the minimum size.
So the conclusions are that this is, this policy is actually definitely visible in the statistics, which is exactly as we expected. The bulk of the allocations we make are still small allocations, while if you look at the address space distribution, that is the bulk of the address space has always gone and is always still going to the larger allocations.
So, this is working out exactly as you would expect.
And that brings me to the end. Are there any questions?
GERT DÖRING: Well, thank you a lot for bringing us these info, this data, letting us see sort of over this side of the fence to see what's happening with the policies after we try to make them and I'm quite happy to hear that there is not so many rough edges in the policies these days so it means that the communication is working and we don't make needless pain on your side, which I think is a good way forward.
ALEX LE HEUX: And I am very happy to be able to say it as well.
(Applause)
GERT DÖRING: And we are absolutely perfectly on time which is even more amazing.
So, already the right slide on it, we start discussion on the policy proposals now, and this is just a reminder on the mechanics; like we don't make any discussions here, we just gather feedback here and the final sort of decision and discussion always takes place on the mailing list. But it's sometimes just quicker to get an idea of the feeling in the room by discussing it in person and clarifying questions quicker.
There is remote participation so everything you say is should go to the microphones and it helps if you state your name because then people know who said what and it definitely helps the scribes a lot. You don't have to state your affiliation if you don't want to, but sometimes it gives more insight.
That's pretty much it and then we go to the open policy proposals. The first one that sort of is semi open is 2011 02. It's in Working Group last call and Sander sort of volunteered to give a wrap up on... and after that, /SKWRA*PB will lead the discussion on 2011 04.
SANDER STEFFAN: So 2011 02, it has been a difficult proposal, certainly in last call. We did receive some comments about some concerns about how it would affect the routing table. So, actually we gave this one a lot of thought. I talked to the people involved who commented on it, to get a feeling of how good or bad it was. And as Working Group Chairs, we think it's the best to conclude the last call. We gave this recommendation to the other Working Group Chairs because now at the end of last call, the whole Working Group Chairs collective will decide if we follow the process and if there really is consensus. So, we are waiting for that result, but in the end, we decided it was in the best interests of everybody to move ahead now.
Then of course there was this talk about putting a limit on the number of PI assignments made according to this, so we have also decided to work with the people who had comments to immediately follow up with a new proposal or at least start working on it to address those points.
So that's how we think it's the best way to move forward and well, we are waiting for the final decision of our colleague Working Group Chairs to see if we really have consensus now.
I see James walking up to the microphone.
AUDIENCE SPEAKER: James Blessing from what you have just said, you implied that there was consensus on the requirements to remove multihoming? And I don't believe there is, because there is no point following it up with other proposals if the first one doesn't pass.
SANDER STEFFAN: Well, actually we do think there is consensus, we had some comments from Michael Abrahamson and he suggested what we are doing now is get this over with, with then follow up with something to make sure there is a limit on it so it doesn't get out of hand in the future, but he specifically suggested concluding this proposal and call consensus.
GERT DÖRING: It's actually a tough call because the policy development process is not completely clear on what is consensus, so, it does not have to be it does not have to be everybody agrees, so...
AUDIENCE SPEAKER: I am going to continue with I don't think it's a good idea and I don't think we should be doing it.
SANDER STEFFAN: It's not up to us anyway. I mean, it's not it's in the hands of the Working Group Chairs, but thanks for your comment. So, we'll see if they agree with us, but it has been a tough call. We have been thinking about different ways forward and we think this is the best way because there is there also is a strong demand for it, so we did weigh all the options and chosen this one, so let's see if it works.
GERT DÖRING: And I definitely see an action item on the two of us to sort of summarise the thoughts and why things have been decided the way they have to the mailing list, so yeah, indeed.
So, I don't actually want to re open the discussion on 2011 02 now, just to explain what's going on. But I do want to open the discussion on 2011 04 now and welcome Jan on stage. There is three proposals but Jan has volunteered I see he brought additional troops.
JAN: Mark Townsley got a new form and shape. Hello, Jan from Slovenia, I am one of authors of this 2011 04 proposal. Mark and Jordi cannot be with us today, otherwise I would share this stage with them, but we have here Ole, he is also a 6 RD co author and we will try to explain how that stuff really works because there was some questions coming up, well there is one question coming up again and again, and he will try to explain stuff, but before that, I will just go through this stuff.
So, this is from previous episode in Amsterdam, we asked you the community three questions: Do we declare this not a problem? And you said that this is a problem and we need to deal with it. So, when people wanted to deploy 6 RD giving them too small allocation size is a problem and it's coming back and back again and again.
Then, we had some input from you, and we decided to go with option number 3: To allow /29 to everyone, because we don't want to make 6 RD or any other technology anything special in the policy. It just shouldn't be that way. I know that ARIN and probably APNIC, I don't know, they made a special policy for 6 RD, so they are allocating this space from a reserved pool somewhere, but we think this is a waste of time and resources because if you do that, this is a temporary solution and then you need to reclaim the space back, and then means just spending the resources because IP resource analyses then need to claim the space back.
So, for IPv6, for legacy IPv6 allocations, /32, as Alex previously explained, there is a reservation for /29, so the first allocation is done out of the beginning of the /29 block. So, that space is already reserved for the LIR that is sitting on the first /32 part, and it's not usable to anyone else, so why not just this LIR why we don't make this space available to use for this LIR.
We will probably include the suggestion from the mailing list from Remco. Our initial idea was to say okay, you can get anything from like from /32 to /29, but we really like the idea that default initial allocation is /32, so if you don't have a clue what to do you get /32 but you can ask for more and up to /29 you can get whatever you want without additional documentation. So, you get more space if you really need it and if you ask for it, actually.
We also remove the 5.7, at least in IPv6 address space holders section. There was a long discussion on this and this, about the extending allocations is an operational matter and should not be in the policy. So we put that part that every /32 allocation legacy one can be extended to the /29 if the holder of this allocation will ask. And if this proposal reaches a consensus, it's in the proposal that if this reaches the consensus, this will just take place and happen.
And the winner is: The most asked question on and off list: Why operators don't consider multiple 6 RD domains? And they want to waste 32 bits in so quick answer is: We are not the protocol police, I am sorry about that. Here we are just about this this Working Group is about Address Policy and we, if you want to talk about if you want to have this discussion, you can go to IETF and ask why this is done, but as we have a co author of 6 RD here, it's Ole, probably explain a bit and also comment on an operational description on why operators don't want to go on a multiple domains, so Ole.
OLE TROAN: Right. So if I know you any of you saw my presentation on mapping yesterday, this is basically the same thing. Where yes, you can do multiple domains in 6 RD. It is just more complex. And it has the added consequence that instead of getting, you know, mesh traffic, that you get C to C traffic, you now have to go all the way up to the root of the graph and go via BR to go to different sub nets. So yes, it has the same provisions in 6 RD that we have the map scheme that I described yesterday that you just put in the last bits of the v4 address and you can save address space. But it turns out of if you have to do as an SIP for every v4 block you have recollect and you have 10, 15 blocks of different sizes you have to do a little bit of fiddling to figure out the domain size, you know, the number of v4 bits, to end up with an end user v6 assignment of, you know, /56, /60 or /62.
So, it's from many ISP's perspective it's seen as a roadblock and are we at a point of v6 deployment where we want to create road blocks? So this proposal is really try to remove the road blocks that's there. We are not really you know the problem is really to get v6 deployed. This is, you know, 6 RD is a way to bridge across those 2, 3, 4 five years we have where access networks are not v6 capable. I speak to since who say my original plan was to deploy, we can deploy v6 in 2015 because we have to change all the access devices, with 6 RD we can do it this year and we want to do it as simple as possible. That's really you know the point in, and v6 is native, it offers dual stack service to the end users. We really don't want special prefixes. You don't want to look at 6 RD as to appear as if it's something special outside of your own network. This is an internal mechanism.
This is basically the same. It's a quote from an operator on the policy mailing list saying this is that, you know, sure, we can. It just adds complexity and it's slightly unfair in that the small guys, the ones who can only justify a /32, are the ones who have to do this, while anyone who can justify a slightly larger allocation, they get, you know, the 32 bit encoding for free.
GERT DÖRING: Thanks for that. Just as another reminder of since we had that proposal on stage before, at the last RIPE Meeting, the Working Group decided that we don't want a special policy that says: If you do 6 RD you can have more bits. But we decided there that the direction we should go to was just be more liberal on the initial allocation size. So, let's not tie this too much to 6 RD in the discussion. It's just one of the incentives why a bigger initial allocation size might be useful. And now let the discussion begin.
JAN ZORZ: So, the question is, we move forward with this? I just wanted to be clear on the mailing list. Me personally, we will never use this 6 RD or something, we would never deploy it in our country, so we are just strike to fix the issues that are coming back from the community, from the operators, from the real life, real field, and we see this not giving out /29s as an obstacle to deploying IPv6 as a service, not the usage of the service. You know, 6 RD is IPv6 as a service. So... I see Wagner.
AUDIENCE SPEAKER: Hello. I really support this proposal because this will, for us, as an operator with multi domain, or many prefixes would also help us to list the stuff. I don't care if it's a 6 RD special policy whatever, I need more address space to do my thing properly, so, for me, bigger size would be great. So keep up the good work. Thank you.
GERT DÖRING: This is actually what we heard from one of the other operators on the mailing list, that they say they are not going to deploy 6 RD ever, but they really would appreciate having an easy way to increase the initial allocation size, so there is more benefits than just 6 RD.
JAN ZORZ: Actually, that space is there, reserved for this LIR, for these operators, why they just don't let them use the space.
AUDIENCE SPEAKER: Andy Davidson from Hurricane. I think I said something along these lines on the list but keep things moving in the room, yes, this is a great idea, yes, keep the defaults to a /32 unless people ask for more. No, don't tie it to a technology. Yes, let's keep this moving, let's do it
GERT DÖRING: That was clear direction. So anybody want to bring up arguments against this? Who wants to be the black sheep in the room? Sorry, I should not say that, there might be valid reasons why we have to reconsider this. So, if you have concerns, please, by all means, bring them up now or on the mailing list. Sorry, I have to be the politically correct one on that.
We still have four minutes left before coffee and I'm not going to leave you out early.
JAN ZORZ: I can stay here for another four minutes, no problem.
AUDIENCE SPEAKER: Raymond. I am not against this, actually I am completely for this, but how, if ever needed some more space after this, will we count if it's in use, will we still use the same rule as there is now or
SPEAKER: Re number...
JAN ZORZ: So, you are afraid of what?
AUDIENCE SPEAKER: I am not afraid of anything. What I want to know is that once I have I need more space than a /29, how do I verify for that? Just ask more or?
JAN ZORZ: If you want more than /29, you need a HD ratio.
GERT DÖRING: For the initial allocation or for additional allocation?
AUDIENCE SPEAKER: Additional.
JAN ZORZ: HD ratio probably.
GERT DÖRING: That proposal isn't going to modify the criteria for additional allocations.
AUDIENCE SPEAKER: That's what I wanted to know. Thank you.
OLE TROAN: I think that's a good point to bring up because that will force you don't need any special policy for 6 RD because you'll have problems for HD ratio if you don't move or 6 RD.
SANDER STEFFAN: One comment I want to make on this is at the moment the initial allocation size doesn't take the HD ratio into account. It is usually smaller than what you get with the HD ratio. So I think this is also one of the things that this fixes because if the end user used HD ratio in the beginning but actually looking at the actual number of customers but not at ratio for the initial allocation, so there is a difference there.
GERT DÖRING: But that's actually sidetracked. This proposal is doing nothing about that.
AUDIENCE SPEAKER: So, just for clarification.
JAMES BLESSING: If I have have 32 now, and I am looking at this going, oh I could really do with a 29 because I want to do 6 RD, not that I am that insane, can I just turn around and ask for it?
JAN ZORZ: Yes.
AUDIENCE SPEAKER: And so the policy adds that ability for everybody?
JAN ZORZ: Yeah.
GERT DÖRING: Since the NCC has reserved /29s for everybody who has /32 now anyway, you could use that space then.
JAN ZORZ: Without renumbering.
AUDIENCE SPEAKER: And are we going to keep are we going to delete the bit that says because it's for 6 RD.
GERT DÖRING: There is nothing like because of 6 RD in the policy.
AUDIENCE SPEAKER: So anybody can request it for any purpose.
GERT DÖRING: Go and say I want this. Basically the new text says: I have considered the options I have and I want more, and that should be sufficient.
JAN ZORZ: Yes
GERT DÖRING: You have to tell that you want more.
JAN ZORZ: Yeah, but you don't have to tell why you need more. You just tell it, well, I need more and you probably you just get
GERT DÖRING: That's the no additional documentation necessary, up there, which is very clear. You have to ask for it. So if you just say: I have no idea what I need, then you get a 32; if you ask for bigger, that text would give you more.
JAN ZORZ: Well the thing is that that space is there and it will be it will never be used by anyone else, so, you know... use it.
GERT DÖRING: Unless the NCC runs out of bits. Which is a bit unlikely.
JAN ZORZ: Then the NCC can request another allocation from IANA, unless we hit the last /8 policy.
GERT DÖRING: I think I hope I am in retirement at that time when we do the last /8 for v6 policy. But, well some things just stick to one.
Thanks for your input. I think we have clear guidance to go forward with the textual change, so processwise, we are near the end of the discussion phase now, so there will be a textual change and then we go, I think, to review phase; is that right? Okay, we go to another discussion phase with the new text and then to review phase. Whatever, Emilio knows how to do all that stuff and he tells me how to get it right. So we change the text and go to the mailing list again; is that right? Yeah.
Thanks so far. Coffee break now. Back at 11.
(Applause)
(Coffee break)
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
1