These are unedited transcripts and may contain errors.
Address Policy Session, 5 May, 2011, at 9 a.m.:
CHAIR: Good morning, dear Working Group. It's nice to see so many of you here at nine o'clock after a nice party. So, I take this as interest in Address Policy and I am quite happy to see so. This is the Address Policy Working Group, so if you plan to discuss DNS things, you missed the time slot. We do Address Policy only.
The Working Group Chairs is me and Sander Steffann. In case you haven't been here, Sander is over there. If there is anything you want to discuss in private, feel free to grab either of us in the hallways or whatever. And of course, if there is anything in the Working Group you want to speak your mind of, feel free to.
We start with some formal stuff, like agenda bashing, and I am right at it, so this is the over layout I have planned for the agenda for today and tomorrow morning. Going into some more details, first of all, of course administrative matters, agenda shuffling, bashing and approving the minutes.
Then, also traditional, Emilio from the RIPE NCC will give us an overview of what's going on in the policy development section of RIPE and the other four regional registries.
Then we will have a presentation by Marco Hogewoning, who is now working at the NCC as a trainer on the policy change that he did just before becoming NCC employee on documentation requirements for IPv6 assignments, which is useful to actually point out what providers have to do regarding documentation.
Then we have a new policy proposal coming over from the EIX Working Group, it's here, this is why the numbering is a bit weird, we had to shuffle around bits and pieces from the agenda and cap the letters, so the letters wouldn't change. So we have A, B, D, Y and then we go back to E.
Then we have about half an hour presentation from Alex Le Heux from the RIPE NCC who is going to bring us feedback from day to day work at the NCC. Things that show up, things that the Working Group might want to be aware of and background information for the next action point, which is after the coffee break, that's me on stage again discussing IPv6 policy and some of the problems we had with that and some ideas we have, how to fix it for good. This will be a long one with lots of room for discussion.
Then we have one specific policy proposal for the PI policy and a short presentation from Dave Wilson on a document that he has been preparing about guidelines for address space holders that want to transfer that address space elsewhere and pitfalls that might not be obvious in the first place, and he is basically asking us for feedback.
Then there is lunch break and end of today's Address Policy.
Tomorrow morning it's nine o'clock again and I am quite curious to see how many of you will make it. Nine o'clock after RIPE dinner is only for the hardcore folks.
Next RIPE meeting, I think database should have their slot back.
Anyway, Friday morning we will have Emilio again. It's not personal that you are always here at nine o'clock; it's just the way the agenda worked out about the document cosmetic surgery project and the current state of things. Then we will have all the currently formal proposals in the system up here to give you an update, what's happening, what's the state of things as they stand. Some of them, quite obviously, need discussion, so we'll have discussion.
And the last thing on Friday is Jan Zorz and Mark Townsley bringing up thoughts on IPv6 allocation, if a provider wants to use 6RD, which has some implications that need to be considered and maybe other policy needs to be adapted. So that's the agenda so far.
Is there something missing? Something that should be in a different order, anything you want to see changed?
Okay. So we'll just keep the agenda as it is.
Minutes. The minutes from the RIPE 61 in Rome have been sent to the mailing list. I haven't seen any comments, so if there is anything else you want to see amended in the minutes, please speak up now. Nobody going to the microphone, so the formal stuff of declaring the minutes final is hereby done.
And we go to the presentation from Emilio about current policy topics.
EMILIO MADAIO: Good morning, Working Group. I am Emilio Madaio and I am the policy development officer at the RIPE NCC. I'll try to be brief and there is a lot more to do in these two days. What I am going to talk about are three main points.
One is the common policy topics in all the other RIRs in all the other regions, either what happened recently and what kind of policy proposal are active in the other RIRs Policy Development Process, PDP. Then we will have a brief overview about what happened from RIPE 61 in Rome, what were the proposal and the policies that completed and the proposal that completed the PDP and the policies that get implemented in the RIPE NCC service region. And, finally, some last updates relating to the policy development office so that you know better what goes on in this, in that department of NCC.
I want to start with with the global policy that was approved a long time ago and was scheduled for implementation in starting in January 2011. My colleague talked about this on Wednesday, I guess, in the RIR update. You will have some more numbers in another presentation by Alex from RS. Basically, the NCC is assigning 32 bit ASN block by default; 16 bit only on request.
IPv4 depletion is still a hot topic globally and you know that, for sure, that IANA ran out of their address pool. APNIC was the first RIR to reach the usage of the last /8 they have available and they entered, as they say, the stage three of their IPv4 address block exhaustions. So, they are going to make allocation for new entrants they are going to follow new policies in their region. Allocation for new entrants in IPv6 deployment.
AfriNIC doesn't have in place an implemented policy yet as a soft landing policy proposal, and I wrote here that it is approaching the last call. Basically, it reached consensus in the last AfriNIC meeting, AfriNIC 13, there were some changes suggested to the text that there were well accepted by the community. It took some time to have those changes into the text and, just recently, I guess last week, the new updated version of the proposal was posted in the mailing list, and very likely will reach will be moved to last call by the Working Group Chair of the policy discussion in the AfriNIC region.
ARIN had already policy proposal before the exhaustion of the IANA address pool and they activated it as soon as they received the last /8 block. I just put here one detail, that, as soon as they received it, they put aside a /10. Actually, there is another important thing to mention and it was mentioned by Leslie Nobile again in the RIR update on Wednesday, that, basically, they changed the supply period, they moved it from twelve to three months, so they satisfy a three months' supply request of IPv6 of the requesters.
LACNIC doesn't have any news from November 2010 when I gave the report related to the common policy topics. They just have ready a final last eight policy that differs from the other because it will be activated when they start using the last /12.
This is another hot topic, quite recent, let's say. I wrote here IP resource transfer; basically, meaning IPv4 resource transfer. With AfriNIC in February, a couple of proposals entered the, started some discussion in the AfriNIC mailing list and just two days ago, the proposers were asked to, were invited to present it at the next AfriNIC meeting where there very likely will be an interesting discussion. I didn't put title or the details because the threads in the mailing list were very long and there was a very active response, but basically one proposal tried to cover the possibility for an AfriNIC member to transfer and to non AfriNIC members their resources and trying to define an AfriNIC role in this transfer. Another proposal tried to, intends to define the same but related to legacy resource holder, so what is the policy a legacy resource holder should follow in order to make a transfer inter RIR? The proposers changed the title. There was a re draft of the text. The proposer expressed the intention, there is a discussion going on and very likely will be an interesting topic at the next AfriNIC meeting.
In the APNIC region instead, the last APNIC meeting in Hong Kong, it achieved consensus on this proposal, inter RIR IPv4 address transfer proposal. Not only consensus; last week, this proposal also ended the last call for comment period, so very likely it will be moved to the executive Council review according to the APNIC PDP. This proposal allows APNIC account holder to be the source or the recipient of an IPv4 transfer, provided that the other recipient of the transfer in another RIR respect the inter RIR policy in place in that region. It is a preview and reached consensus after some rewording of the text.
In the ARIN region, this globally co ordinated transfer policy was discussed in the latest ARIN meeting, and there was a general support of the proposal. It was suggested some kind of rewording in this case, too. Although the consensus seemed pretty clear on this. This proposal differed from the others in terms of allows, inter RIR transfers as long as both RIR agreed in a condition that maintains the need base of the transfer itself in respect of the RFC 2050. It's difficult for me to quote this proposal because it's, again, in the mailing list and there will be some rewording, there will be some update considering the input received in the latest ARIN meeting.
In doing so, before I go on with the proposal, I just mention meetings, RIR meetings. Something that maybe Gert was going to say later. Here in the RIPE NCC server region, the RIPE community decides to discuss policy only in the mailing list, that is where there are the decision, or the decisions are taken. Here in the RIPE meetings, we can reach conclusions and then we transfer to the mailing list. But it's different from the other RIR PDP, just to make it clear.
And then I start the, I hope not too long list, of all the policy proposals that kept the RIPE community busy.
Starting with 2006 05: PI assignment size was discussed in Rome and there were some more input that led to the decision of a new rewording, some text will change. Unfortunately, the proposer had some difficulties in working with us he couldn't show up at this meeting, unfortunately, but he agrees to be helped to cooperate with another co author if there is someone in the community interested in that. So, I invite you to read the proposal and give a thought or two about participating and supporting this in the PDP. Yesterday I had a chance to meet a community member who wants to take over part of this job. So, you will see, anyway, an update in the PDO website related to this policy proposal.
2008 07: Ensuring efficient use of historical resources. I am just officialising that it was withdrawn. I presented the status of this proposal in Rome, saying that the proposer intended to withdraw it long time ago. There was some some interest showed by some community members to take it over. But it never happened, so we called it for the last time if one wanted to join, it didn't happen. You are going to see it withdrawn soon.
This is three policy proposal discussed in the Anti Abuse Working Group mailing list. They were presented in Rome, in the Anti Abuse Working Group. Most of them was decided by the Working Group were addressing technical issues, and it was decided to create a taskforce to tackle that issue at implementation level, not at policy level. A different fate for the 2010 08, just recently we decided to withdraw it with agreement with the Working Group Chair and the proposer because the same taskforce is working on that specific issue and, in their time line, it is meant to have another policy proposal, it is not useful and effectively to keep it here. We will withdraw it, but you will see it very likely in the future, a policy proposal that will cover the same scope.
2010 07 was an IPv6 policy proposal. It was presented in Rome again. The feedback from the community was extremely positive in terms of the scope of the proposal, not very much in terms of the solutions presented by the proposal itself. It was clearly an ambiguity cleanup. The current policy text, the now RIPE 512 sorry, not, the other, the IXP current policy had a sentence in one section that wasn't very clear how to interpret it and how was the correct implementation, so it was presented to the community. The community gave some feedback. At the end, it was decided that that was more an activity that belongs to the cosmetic surgery project I will present tomorrow because it was only a textual change, not a process or procedural change according to the policy. And before we decided to withdraw it and move the same scope to the cosmetic surgery project, I recently published a new draft on this policy that took into consideration also the input we received in Rome.
2010 05 was a global policy proposal that entered review phase where we, right after the RIPE meeting, there was some discussion, the phase was even extended, there was a new text starting right after the RIPE meeting that was published for the community discussion. There was a lack of feedback. There were other, even, in other RIRs, in other RIRs PDP convenes the proposer in agreement with the Working Group Chair to withdraw it. This proposal was rejected in the APNIC meeting. It was accepted in the ARIN region, if I recall correctly. It should be still under discussion in the other two RIRs, AfriNIC and LACNIC.
You can find on the ICANN website, the ICANN announcement with the overview of all the global policy developments all over the regions.
2010 02 is, instead, I think, the first policy proposal we accepted at the beginning of the year. I mentioned before the common policy topics the final /8 policies different RIRs are implementing. This is ours. It was a long path to reach here. There was four different versions that were discussed by the community. It is active. It is not implemented yet because we haven't reached the last /8. But when it will be implemented, it will be one single /22 per requester and allocations only. I think you will have some other numbers and details and what is supposed to happen in the following presentations.
2010 06 is the registration requirements for IPv6 end user assignments, and, as Gert said before, you will have a detailed presentation of what happened, what it means to have this policy active and in place now in the RIPE NCC service region. It was approved around February, if I recall correctly.
This proposal, 2010 01 and 2008 08 are in last call. That means it started the last call for comment period of four working weeks. Room for well motivated objections in the mailing list. The Working Group Chair posted in the mailing list. For both of them, the motivation, a brief summary, the motivation to move it to last call, you will have a presentation by the Working Group Chair on this proposals.
And these are two new policy proposals this year, 2011 01 and 2011 02. The first one is the global policy for post exhaustion IPv4 allocation mechanisms by the IANA. It started a discussion, I don't remember correctly, I think at the beginning of March, and there was some feedback. It got a bit side tracked. We extended the discussion phase. The proposer posted a clarification in the mailing list explaining the intention, the scope and the motivation behind this policy. Unfortunately, he couldn't come to the RIPE meeting, or whatever. Again, the Working Group Chair presentation on this. What I want to say is just to give you a brief update on what is this global policy proposal doing in the other RIRs PDP? It started the PDP in all the other RIRs. It was accepted and reached consensus and ended positively the last call for comments in the APNIC region. Started discussion phase in LACNIC, and in AfriNIC, and is also a proposal, not a draft policy yet, in the ARIN region. So it's active all over the globe.
2011 02 is a policy proposal that regards the multihoming requirement for IPv6 PI. You will have a presentation by the presenters here, and I just would like to suggest that this is just the first practical consequences of a long and very useful discussion in the mailing list related to IPv6 policy, that actually covered many topics. It was a very useful input so far.
Finally, last two slides related to the policy development office. Not much to update on that from Rome. This is the document that describes, basically, what the community does. What are the principles followed by the community in order to discuss, accept or reject proposals. This is the website where you can find all the current policy proposals that I mentioned and that will be talked during this meeting.
A brief update: In the last six months, I had the chance to consolidate all the cooperation with the other RIRs. The other RIRs PDOs, collaborate with the NRO. There is a comparative policy matrix of all the other RIRs, and I would like to thank all I won't mention names, but I would like to thank people I had a chance to work with, face to face, and also remotely, ASO members who needed my help for part of the coordination and the text that the ASO covers, ICANN members that are into the policy and follow, especially, global policy proposals. It's part of the job, it's part of the intention to become a strong to keep on being a strong registry, it's part of becoming an even stronger community and, therefore, having someone who can represent in different environments and scenarios. These are my contacts. That's the e mail address you can use to submit proposal, submit questions and so on. And that's also the Twitter account I presented in Rome. I am looking for followers. I mean I want to follow people. I am interested in what's going on, also, in the Twitter sphere, I keep some kind of updates of the policy proposal status also there, so if you are a Twitter junkie, you can be updated there, too.
And, with that, I think it's time for questions, if you have any.
CHAIR: Thanks, Emilio, for setting the stage and making sure everybody knows what's going on in policy land. So, we can have more educated discussions here. Any questions on that? I don't see anyone. So thanks again
EMILIO MADAIO: I am happy I didn't receive one question that is: What is the Address Policy Working Group mailing list URL? So it means that all of you knows it and you participated very well. Thank you.
CHAIR: Thanks again.
(Applause)
CHAIR: There is one thing I have been asked to announce, which I forgot, nine o'clock is early up there. Macintosh laptop power supply has been found in the Terminal Room late evening. If you are missing a power supply, it's been deposited at the registration services desk. That was the one thing. I also forgot to thank the scribe, the NCC is volunteering to actually type whatever we say and a big thanks for that because it's a hell of a work.
[] STENOGRAPHER: I know.
CHAIR: Now we go to Marco, actually you all know them.
STENOGRAPHER: I am wrecked.
CHAIR: Marcos introduced a change to the way IPv6 assignments can and should be documented in the RIPE database and, as far as I understand, now working as a trainer he figured out that the registries don't really understand what that means for them, so he volunteered to explain it to us. Marco, thanks.
MARCO HOGEWONING: Thanks. I am Marco, I work for the RIPE NCC. I am also Working Group Chair still and in a previous life I was also a proposer of this policy change. So I am standing here with about four hats on. It's pretty warm, but bear with me.
Yeah, IPv6 policy: That had this strange phenomena on the registration and this is what it used to say. "When an organisation holding an IPv6 address and it makes IPv6 address assignments, it must register assignment information in a database accessible by the RIRs as appropriate."
This got quite a lot of questions. Nobody understands what was happening. What should be in the database, what means accessible? Is it the text file, can we mail it, do we need some fancy API? So, after a bit of discussion in the community and with the NCC like where should we take this, we decided to change it and make it clear. So, we removed this and it got replaced.
It now says: "When an organisation makes IPv6 assignments, it must register these assignments in the appropriate RIR database." Which, in our region, means the RIPE database. Brand new, pretty clear. Basically, all. If you make an assignment, it has to go in the database. Now, this immediately causes the section problem, because if you have ten customers and ten assignments, it's doable, but what if you have millions? You will have a huge number of objects to create to update and hopefully also remove, and especially when you are doing residential, probably all those will point to the same context because either you are not allowed to publish private information or you don't want to publish it, because if your customer is causing problems, you actually want to get the phone call and not the customer.
So, the solution is, group them, and, actually, we looked a bit on how it's done in IPv4, when you have a residential pool, usually never register a /32, you create one object saying this /22 is my DHP pool for broadband users and it kind of follows naturally that each customer will get one IP, so we kind of looked for feature parity, and the solution, of course, is group them. So, what it would do. We created a new status attribute. The first four were already there. Aggregated by LIR. And it actually does what it says. You are the LIR and, actually, you are aggregating a couple of assignments into one object.
Next to that, we also created a new attribute, it's the assignment size attribute. Technically, from a database perspective, it's an optional attribute, but the moment you set the status of to aggregate it by LIR there are some business rule that mandate that assignment size has to be there and has to be filled in. So, it's an optional attribute, unless you take the status, then it becomes mandatory.
Put this graphically: This was the old situation, so if your allocation on the top and, under that, either [sep] allocations or large assignments and all the small ones, all these 48s, 56s, had to be in an internal database. You can all see that it's cumbersome. After eight objects I got tired and stopped drawing them. But if you have millions...
So, changing only the registration requirements would have meant this. Moving them up to the RIPE database, millions and millions of objects. So, this is where aggregated by LIR comes in handy because what you now can do is group them. So, you can say this /34 is aggregated by LIR and actually using that to make individual /56 assignments. And same goes here. So you can also put them, if you make a separate allocation the guy who is running this sub allocation can do the same thing. This is aggregated again and hint: These are all /48 objects, individual /48 objects. Pretty easy, and, technically, you can only have one object. If you have one object covering your old /32, it is done. So, question arose: What to do with different sizes?
Well, there are two solutions: You can either put them side by side, or, as we say, this is a 48, this is 56, and together with that, or you can actually create different levels. So you have this /40 here. I am not sure what happens with this number, but assignment size /48, and then you can create other object that must be the same size of this assignment size, or of this assignment size is a /48, then it follows naturally that this object is a size /48, and you can create smaller ones again.
What's not allowed is to build a tree all the way down from a /32 to a /64. You are only allowed two levels of aggregated by LIR. Also still allowed, of course, if needed, you can create separate assignment objects. It's still allowed. You can just put them in there and nobody complains. The rule set of this:
Well, the assignment size must be greater than the length of the containing block. Obviously, if you say this is a /56 object, and I am assigning 48s out of it, it doesn't make sense. When creating more specific, the underlying block has to be of the size of what the parent says is assignment size. There is one little caveat: Once created, you cannot change the value of the assignment size. You actually have to drop the object first and recreate it. It might seem cumbersome, but, then again, if you are already assigning /56s, what's the chance you, all of a sudden, change your policy to /48, then you have to drop the object. It's a bit of a heck, but otherwise the software would be getting very complicated and it would take months to introduce. So a little short cut here in the implementation phase.
How does it look in real life? There you go. This is actually a real Dutch broadband provider, they have pools of /46s, and, from that, they assign /48s to customers. And whatever happens, mail them if you see problems. This is what I did here, /36, or, at least, that's what the database says they are doing, they are /36 which gets cut up in the /48, then the first /48 is assigned to a POP and assignment size is /64 and that's the way you can use this.
Now, when is it used? Well, if you ever need more addresses, if you run out of your /32, it's not likely, but, yes, you can, there is an audit and maybe there are intermediate audits as well and then it asks to calculate the HD ratio, so what's actually assigned. It's then very easy, because if you show the exact number of assignments in each block, then the [MOP] becomes easy. It says this is /36, if you can show there are 1,000 users there with /48, then you can easy calculate the ISD ratio. Because it usually equals the number of customers, and, mostly, the auditor reports already have those statements in there so it becomes pretty straightforward. In effect, if you run a large IPv4 broadband assignment, it probably seems very familiar because when you do that kind of stuff with IPv4 pools, you are asked for the same information, they are actually customer account or at least you have to show how many of the addresses in the pool are actually in use.
Well, other uses? It's a public database. The information is there. If you are running blacklist, you could take it as a hint on where to aggregate if you want to block a customer or where not to aggregate. Or if you see a lot of spam coming from a single net block, point that it finds out that it's a single assignment so you can prove those complaints. It's a million other uses, probably, but that's up to you. The information is there. Well, the information is there, actually, this got moved to what was supposed to do was a slide on statistics accounts last week, we have got about 53,000 [INET] [] sick nabs and only 75 have a status called aggregated by LIR. So, it's still nothing used that much. And that's why I am here.
Any questions?
CHAIR: Marco, thanks for bringing this to us and explaining it. And, actually, thanks for having that changed in the policy text and the database implementation, because the old one was sort of the workable and unclear and new one is very clear and quite useful, so
MARCO HOGEWONING: Many thanks for the community support in this proposal, actually. Reaching consensus is much harder than writing the proposal.
CHAIR: If the proposal is good enough. Okay, I see one question over there.
AUDIENCE SPEAKER: This is Andreas Polyrakis from GRNET. My question is suppose that an ISP wants to actually register the /56 that gives to end users, is there a policy that prevents this or is this considered abuse or is it send the information in the database?
CHAIR: You can do that, but if you have residential customers, data protection laws of your local country my not actually permit you to put their personal information in there. So that in that case, you end up having your knock in there for all the 56s, which is not so useful, so then the aggregation stuff. If you have business customers and they want their data in there, you can do it.
MARCO HOGEWONING: The policy text says it must be registered. It doesn't say you must use this form. If you want to create all those different assignment objects, go ahead, they are still allowed. It's just if you want to make your life easy, then this is an option. Database object itself, by the way, is described in RIPE document 513, if you want to look it up.
CHAIR: Thanks again. A round of applause for Marco.
(Applause)
Okay. So next one is Andy Davidson. I have been told he is here looking a bit like yesterday evening was too long, but I can see him.
This is, basically, stuff that came up in the last days only and it's not yet in the formal machinery of the policy development process and that stuff usually goes to the last bits of the Address Policy Working Group time. But that's in parallel to EIX and is supposed to be there as it's well, his Working Group and so we shuffled it around and you have Y quite early in the alphabet.
ANDY DAVIDSON: I don't think it was the social last night was too long. I think that it's the gap, the night in between then and now it too short, but...
I am here to report a piece of work that the EIX Working Group did yesterday and gather feedback from the Address Policy community about this work and your ideas before we turn this into a formal policy. A big apology, first of all, because this is a conversation about IPv4, which we are all somewhat people certainly in this room are certainly moving words to deprecating, and I certainly didn't think, when I joined Hurricane Electric, I'd be talking about v4 policy. Here we are.
The idea of this policy is to ring fence some IPv4 resources for future Internet exchange points. This is quite important because there are some lovely parts of the world that do not have Internet exchange points, and my view is, that by installing some there, it will significantly improve the availability of Internet access and the quality of Internet access, both v4 and future v6 installations, so boot strapping IXPs in places around the world is a very, very good thing.
In order to boot strap an IXP, you need to get some numbers and we start to get some IPv6 first. We have a specific policy for IPv6 assignments to Internet exchange points already, but we don't have a policy for IPv4 for Internet exchange points people today, just go and get some PI. But IPv4 PI will go away very soon indeed. As soon as the NCC starts to allocate from the final /8, v4 will go away. v4 PI will go away.
I looked at some measures we could do instead of ring fencing IPv4, and we came up a few ideas like doing v4 prefix exchange over the v6 transport. And this doesn't work very well for our purposes, because you still need to stet a v4 next hop before you look at any of the other technical measures that make this undesirable like the lack of process separation, which is very, very desirable, and it also forces you to make some assumptions that just because a v6 session is up, lots of things could be assumed about v4 connectivity. So, when I thought about this with some operators, they thought it was a horrendous idea and should not be explored and I agree with them.
So then we thought about well maybe we can just make exchange points with RFC 1918 v4, and this is also pretty bad because you haven't do your R PF filtering, which I am sure everybody does here and also it means that the risk that an are RFC 1918 address is used in one part of your network already, is on the same, or the same sub net as the Internet exchange point that you are trying to connect to and that would mean that you probably couldn't participate in the exchange.
Also, trouble shooting is made harder because many exchange points announce their peering LAN so that the exchange peering LAN shows up in trace routes and members of exchange points like to set reverse DNS so that other people can trouble shoot connections with the right operator, which, of course, you won't be able to do certainly on anabolic Internet if we use RFC 1918 v4.
There is a question that maybe this is quite late in the day and we should just consider that future exchange points will be v6, and traffic growth in v6 will be natural and we should just do v6 peering of new exchanges. But, actually, when you look at where a lot of v6 advocacy happens, it often happens within the exchange communities, operators come together at the neutral Internet exchange point region and share v6 knowledge. So, in a fairly in a way that might be a little bit disconnected from your first thoughts on this, making an Internet exchange which needs v4 and v6 resources may actually be a way of driving v6 deployment elsewhere in the world.
If there are no technical measures that we can use to address new Internet exchange points elsewhere in the world, then maybe we could just not make any more Internet exchange points, but I also thought that this was a fairly unappealing strategy idea as well.
So this leaves me with a suggestion that we should save some IPv4 for Internet exchange points and my policy proposal would be to hold a /16, either from a final /8 or however, or whatever /8 addresses are being assigned from now, which will be used for Internet exchange points. Now we already define Internet exchange points in the RIPE documentation today. So and we defined that exchange point as the layer 2, good at the Internet changes that they are. There was significant support in the EIX Working Group yesterday, lots of exchange came forward and said yes, we think that this is a good way of preserving, good at the Internet projects that will need addresses in the future, and the suggestions that came from yesterday's meeting was that maybe we don't wait for the final /8 to make this registration and start assigning new EIXs from this pool today. Also, we shouldn't make this policy just for new Internet exchange points but we should make it for all Internet exchange points that are going, so if a large Internet exchange point grows out of an existing peering LAN, they need more addresses to continue, and, also, there was a suggestion that there should be a minimum assignment size within this /16, that maybe a /24, which I agree with.
Are there any comments on this? This hasn't reached actual written policy stage right now, but I think that a discussion here will be helpful and make a better policy in the drafting stage. I can see Remco at the mike already.
REMCO VAN MOOK: I think this is a good idea. I do want to refer the audience to a similar discussion held at the ARIN meeting a few weeks back where the subject was discussed, but it was, as far as I can remember, folded into the critical infrastructure which already in ARIN policy that we don't have. So, in that sense, I support building this proposal and, if need be, I am happy to help out pushing that forward and editing it with you.
AUDIENCE SPEAKER: Alexis, and one idea after yesterday's discussions that I got was that how about ccTLD a main service, anycast services. It could be another thing that might deserve similar special treatment and if so, maybe should could it be you know combined with this so that they could, you know, maybe share different sides of the same pool or something.
CHAIR: I would actually rather not go there, because I wouldn't object to having a second policy proposal in the system for ccTLD anycast stuff, but from the experience with previous domain name related addressing policies, this inevitably seems to cause quite lengthy discussions. While this is sort of like a special case, easy understandable and no rat holes, so, let's keep them separate, which doesn't mean we can't have the other one. It's just going to be even more problems in the process if we lump them together.
AUDIENCE SPEAKER: Fair enough.
KURTIS LINDQVIST: I actually think this is a very good idea. I can't make up my mind if you should take it a final /8 or from the existing policy. I just make one observation: A /16, there is 256 future changes assuming /24s, that's more than twice the number of exchanges we have in Europe today, which is that would mean there are three times the number of exchanges we have managed to build in the last few decades. It's quite a lot, actually. And I do believe the minimum assignment size should be longer than /24, I don't see the reason why it should be a /24, it could be smaller, I think it just justified like all the other space. To the point about anycast of the ccTLDs, there is already a policy for the ccTLDs to go get anycast. I don't see a need for a new one, if they want space go for it. If they ran out before they do it, well, tough luck. ISPs can't get it, either, so...
CHAIR: I just interrupt the queue because there is feedback from Jabber.
AUDIENCE SPEAKER: It's not a question, just a feedback from James Blessing at Limelight Networks wants to say he supports the proposal and that it should be from existing address space.
CHAIR: Thank you. I think [Joao] is next.
AUDIENCE SPEAKER: Full disclaimer, I work for a TLD so I am not jealous of Alex is taking this, I am very happy, I think it should go fastrack and get that proposal, whatever length it is, but, from my memory, I don't agree fully with Gert. Lengthy discussion was there because we didn't have an agreement on what is a critical infrastructure. Now that we have got many examples and saying that anycast might be for this kind of infrastructure, I think that next one should be very fast and if TLDs want to reserve whatever space in it, it should be easier than having lengthy discussions, but yet, once again, I don't object getting this very fast and without any connection to any other community asking for the same thing.
AUDIENCE SPEAKER: I wanted to just comment on Kurtis's comment, that about the number of how many IXPs this block can accommodate. Since it's also for growing existing ones. Now, if an existing one already has a /24, it's not going to be grown into a I mean, a 24, it's not going to be grown into a 23; it's going to be grown into a 22, or something, so that drastically reduces the number of IXPs that the /16 can support.
SPEAKER: Actually, we can have a look at previous trends of IXP growth when we evaluate this policy and what is intended to happen and if that's desirable and if we'll do it the same way again and shape an implementation rather than the policy based on past performance and if it seems to work, maybe.
RANDY BUSH: Since we are not queueing in order. Randy Bush, IIJ. Just one quibble with you, Kurtis. I think, unfortunately, we are going to be dealing with IPv4 for a long while, and, so, 256 may prove not to be enough.
ALEX LE HEUX: Alex le Heux, RIPE NCC. I want to comment on what Kurtis said, as well. The last /8 policies says the RIPE NCC should only allocate /22s to LIRs, one per LIR, and that means that there will be no more PI assignments, no more anycast assignments in IPv4.
CHAIR: Which is exactly why Andy brought this up.
AUDIENCE SPEAKER: Brett Carr from NomiNet. I just wanted to say that you are talking about the difference here between the IXP thing and the ccTLD thing is that we are talking about growth of IXPs and expanding, but the ccTLD space isn't going to expand. So unless we are talking about gTLD also being able to get reverse this space, then the ccTLD really doesn't come into this conversation.
CHAIR: Actually, I want to cut the discussion on ccTLD here. There is not going any new ccTLDs to show up any time soon but there is lots of them that don't have anycast yet. There might be some room for growth there, but please let's not mix these two things here. Jabber, Kurtis and then we close the line.
AUDIENCE SPEAKER: Matt Parker, RIPE NCC, feedback from remote participants. Also supports this proposal.
AUDIENCE SPEAKER: I think what I said was, I think I was misunderstood. What I said was how much space will fit into the /16 depends of course on what the minimum assignment size. I didn't quite follow Alex's counting there. One is, we had the space and people might have to expand it and we had the discussion yesterday. I am assuming that space will be returned to this pool or some other pool to be used for either IXs or something else and, yes, they can be taken out of this space. I totally agree with Randy, we'll be needing IPv4 space for the future. It all comes down to what minimum assignment size will be. It's important that it will not be a /24 but a smaller space or a longer prefix, depending on how big the exchange is. Yes, it will be very hard, but we are faced with other v4 space so we will have to trade between we will have to compromise between lack of space and hard work.
CHAIR: Okay. Thank you. So what I am hearing from the room is clear direction, so, I would say you write something formal ish with Emilio's help, and us, of course, as Working Group Chair, so we are here to help. So, we do formal proposal and send that to the list and do the formal process then.
ANDY DAVIDSON: Certainly. Thank you very much everybody.
CHAIR: Something I forgot to say, actually. Could you give me the slide before that? Just the formal stuff. We discuss ideas here, but, of course, we don't make decisions here, so whatever happens here, then goes back to the Address Policy Working Group mailing list, is documented, is discussed in the open and the formal process runs via the mailing list. So this is just to get feedback on the direction where we go, but we don't make decisions here. That's so far. Now, I invite Alex to enlighten us with things we might have overlooked or things we might want to think about.
ALEX LE HEUX: My name is Alex le Heux. I work for the RIPE NCC as the Policy Coordinator.
I have got four points to discuss today. I am going to have the first three are probably going to be quite brief. A short update on 4 byte AS numbers and implementation detail of the last /8 propose. I was asked to describe how we deal with the upgrade of /32 allocations, if that's needed, and then I am going to talk a little bit about our experiences with IPv6 PI and provide a little bit of background information concerning the discussion that's going on on the mailing list at the moment.
A few years ago, we began issuing 4 byte AS numbers, and, since 2009, we have been assigning 4 byte AS numbers by default. We treat it as a single pool, although we do still allow our members to tell us whether they would like an AS number from one end of the pool or the other end of the pool. And over the last year and a half or so, this is what it looks like. Roughly, a third of the AS numbers we give out are 4 byte AS numbers.
Globally, the picture looks like this. So, in the RIPE NCC service region, 4 byte AS numbers seem to be doing quite well. And then if we actually look at what happens in the routing table, they seem to work there pretty well, as well. This is all the AS numbers we have ever given out. Of course, some people either request or receive a 4 byte AS number and then find out that their routers don't work with this when we allow them to come back to us and swap it for a different one. And the 25% that's returned includes every single one that was ever returned. And, in the past, the return rate was much higher than it is now currently about 16 percent of the 4 byte AS numbers we hand out get returned because they can't use them for some reason.
Now, someone raised the point to us that actually, pushing or assigning so many 4 byte AS numbers could be seen as putting organisations in that region at a competitive disadvantage, because some equipment still does have problems with it. So, I would like to ask the room, is this actually a competitive disadvantage or is it perhaps a competitive advantage for in a few years? Or, does no one have an opinion?
REMCO VAN MOOK: Let's put my Equinix hat on. I think this is a competitive [NAP]. It is really indifferent. If you still have all the equipment, you won't be able to use it. Does it really provide a disadvantage when you are building a new network? I don't think so.
WILIFRIED WOEBER: Vienna University. I guess most, if not all, of the people running old equipment would have their 16 bit DS number anyway and if anyone upgrades the network or reconfigures stuff, there is a very good chance that pretty new equipment is involved. So, my wild guess would be just neutral.
ALEX LE HEUX: Okay. Thank you. I think we'll just we have another.
AUDIENCE SPEAKER: The few of the cases where I have been involved in a return autonomous number are returned and a new one for 16 bits is that the transit hasn't upgraded their backbone yet, so they couldn't the transit provider couldn't handle a 32 bit ASN number. So it's not the guy installing the new network; it's where he is getting, you know, transit. So it could be a competitive disadvantage between the different transits that are at different stages of upgrading their backbones, but that's their business decision, anyway, so...
ALEX LE HEUX: We see both reasons appear for wanting a 2 byte AS number: either the equipment doesn't support it or the transit provider doesn't know what to do with it. But I'd like to repeat: we are not forcing this on anyone. We still have 2 bytes AS numbers and we assign them if anybody wants them.
Okay, I'll guess we'll just continue.
The last /8 proposal says that when we hit the last /8, we shall be making only /22 allocations to LIRs, one per LIR. Of course, address space will still be returned to the RIPE NCC after that, and that comes from all our other /8s. There is a steady trickle of address space coming from LIRs closing down, it's probably some going to come back from PI assignments now that's it's gone into the final phase of its implementation, and we have to do something with it. And we are thinking of treating that address space the same way as we treat the last /8, but the policy text itself doesn't really say what we should do. So, I wanted to ask the room for input on this as well.
REMCO VAN MOOK: My personal opinion is that doing it this way, while I sympathise with it, it's probably taking a bit too much liberty on the RIPE NCC side to do this.
ALEX LE HEUX: I can't actually hear what you are saying on stage here.
AUDIENCE SPEAKER: I am usually quite loud. So I'll just read out what's on the screen. My personal opinion is that doing it this way I can't actually read what think that making the assumption from the side of the RIPE NCC is taking a bit too much liberty, so I would actually prefer for the community to come to a verdict in a proper way.
ALEX LE HEUX: Which is why I am here.
REMCO VAN MOOK: Yes.
CHAIR: The problem this year, actually, that the policy text is unclear enough that this is a valid interpretation and other interpretations would be valid as well, so this is the interpretation they have, well they are proposing to use, and it's on us to get feedback. So
REMCO VAN MOOK: So my take on that is that even though it might be seen as a valid interpretation, there is certainly multiple ways of looking at it so we should just make sure that gets cleaned up as we have cleaned up other pieces of policy in the past, like IPv6 registration, just as an example.
[ALEX LE HEUX]: A policy text which clears this up would be even better.
CHAIR: Remco, would you volunteer in actually helping clean up the text?
REMCO VAN MOOK: I think I might have just been volunteered.
CHAIR: Thank you.
(Applause)
RANDY BUSH: We had this exact same problem in the AP region, and I was co author of a number of the proposals. And you do have to clean this one up and this is exactly how we cleaned it up there, if people care, is that once we cross into the final /8 time, that is an irreversible transition.
WILIFRIED WOEBER: One of the LIR managers. I think it's a very good idea to do that, as you propose. At the same time, I think it's a very good idea to consciously do that and document it in whatever shape and form and fashion, whether this is actually going to be a fastrack formal policy extension proposal or whatever, or whether we consider that as an extended cosmetic surgery I really don't mind, but I think it should be documented and we could sort of look back in history two years from now and argue and prove that it was not a decision out of the blue, but there was community consensus to do that. Dropping the hat of the LIR and mounting the hat of the address council member, I am still in favour of that, but we should consider the fact that this actually has an impact on the other discussion about global policy that involves address space being returned to an RIR, and what now? Are we going to keep it within the region and put it to good use, or do we expect something which would require us in the end to take these small blocks of addresses and put them pack into the IANA pool for redistribution? I think it is something we should keep in our head. Thank you.
ALEX: This is really a nuance issue, but I just thought that since the expectation of the last assignments, the /22s, is that they aren't really going to be assigned directly to end users or anything well, basically, that meant for transition methods, so maybe, should the last blocks be called something other than PI and PA?
ALEX LE HEUX: Well, in the current policy as it is now, there will not be PI. There will just be allocations to LIR, that's by definitions are PA allocations.
AUDIENCE SPEAKER: Yes, exactly. But since they do not behave like PA, or they are not expected to be behave like PA, then that's why I make the suggestion.
And then another thing is, does the policy say anything about transferring this address space between RIRs?
ALEX LE HEUX: I don't think it does, no.
CHAIR: Right now, there is no inter RIR transfer policy. Okay, two more comments. I don't know which of you was first, sorry, and then I close the line.
NINA BARGISEN: I am Nina Bargisen from TDG. I am thinking I am in support of treating the space as this one. Because after we cross the time where we enter the /8, the only way of getting any IPv4 space that is not for your transition will then be to go buy it on the market that we all expect is already here. And if we have space at the RR R that be obtained in the usual way, which is not in the market place, it's going to be a difficult situation to handle both for the RIPE NCC and the other RIRs and for the LIRs like myself.
AUDIENCE SPEAKER: I am not of this group, so I apologise if I say something which is not but one issue that I have heard multiple times is that IPv4 addresses are maybe specially needed by end users, so if there is any means to reserve to have a particular attention to what end user will get an IPv4 address for user by some protocol like e mail that pool information and that couldn't have no means to handle IPv6 because it's not, it's being working on and there is nothing definitive on it. Thank you
SANDER STEFFANN: Basically, we've been talking about wh to do with v4 for very long and I think we have clear consensus on that we don't want any special rules for special purposes like this. I mean, we are going to run out of v4, it's going to hurt and it's going to hurt everybody. So I think making exceptions I don't think we could get consensus on something like that.
AUDIENCE SPEAKER: Nurani from NetNod. I am not sure, actually, if I understand the wording, because right, we get addresses returned, we either do something like returning it to IANA, we have had that discussion, or we I am not sure if I understand "Will be treated the same way as the last /8." Once we have the last /8 policy, people will get addresses according to that policy. We are not going to say, you are in luck, we got a /16 in the 202 pool so we'll have this policy apply to you, but you I am sorry, you got addresses you'll get addresses from the last /8, so we have one policy at, you know
ALEX LE HEUX: But the point is that the last /8 policy is worded in such a way that you can also interpret it to say that it only applies to space coming from that specific /8, and the address space will be returned to us will be from other /8s. So.
AUDIENCE SPEAKER: So, what I am saying is that once we have the last /8 policy in place, that will apply to all addresses that the RIPE NCC allocate, you know, from that point on.
ALEX LE HEUX: That was the idea from this. But I hear we are going to get a policy proposal to clear this up.
CHAIR: Okay. The very, very, very last comment, because well... experience speaking.
AUDIENCE SPEAKER: Hans. I just wanted to emphasise what Nurani just said. Please be careful not to make this an implicit policy which makes it impossible to return space to IANA unless that is really what we want to do, and I don't think I have heard that expressed clearly that that is what we want to do. I think the intent that you have proposed is very good, but reading it the way Nurani did and that I do when she mentioned that, I think we need to be very careful about that.
REMCO VAN MOOK: I am going to be the one after the very last comment. As the future proposer of this proposal, I will keep this in mind, I am well aware of the complexities around this. So, yes, I will make sure that the text of the policy proposal has this in mind.
CHAIR: Thanks, Remco. Thanks, Alex. This took way longer than I expected, so we are going to run a bit into the coffee break, but I still want to I think it was very important to have this discussion here and we have clear guidelines what to do next and we have a volunteer, so this was a success and worth use of the time.
ALEX LE HEUX: I'll try to be quick with the rest.
So, we have been allocating IPv6 space for a long time. In the beginning, a lot of LIRs requested a v6 allocation. They were probably not really that Tara long yet with their detailed deployment plans, so they said a /32 will do fine for us and we allocate them a /32. Years later they are actually making their deployment plan. They realise they have millions of customers that they would like to give a /48 and so they come back to us and they say okay, we need something because that /32 had to be much larger.
The way we deal with this is, it can go both ways. If they do not want to return the /32, it's just the normal policies apply and they can fill it up to their HD ratio and send in additional allocation request. Or, we say okay, that evaluation back in 1999 maybe didn't go the way it should have gone, you can return your /32 and we will just enter the process as a new first allocation request. I was asked to explain how we do this.
Any comments on this? I see someone standing up.
AUDIENCE SPEAKER: I just want you to clear something up. This is Nina from TDG again. As far as I remember, the policy, and I may be mistaken, it might have changed and I didn't realise it changed, are we not, when when we come back for an additional allocation, this 32 will be extended to a 31 until a 29, I think it is? Is that not going to happen, any ways?
ALEX LE HEUX: Well, we don't have so much experience with with this yet because not so many LIRs have filled up their /32, or whatever size, first allocation yet, but the /32s are inside a /29 reservation, so, should they be expanded, they can be expanded to a /29 without allocating additional prefixes. But in many cases, for the LIRs that come back to us and say okay, these /32 is too small, the block they would actually need to number all their users is going to be larger than a /29. And they have not actually used the /32 they got back in 1999 or back in 2000 or something, they haven't actually used it yet, we think it's better for aggregation, it's easier, simpler for everyone to just do a new first allocation procedure.
AUDIENCE SPEAKER: Okay. Thank you.
ALEX LE HEUX: Okay. IPv6 PI space: This is two parts. I'll be talking a little bit about our experiences with the IPv6 PI policy, and then I have some background information mostly numbers about the, or relevant to the discussion that's been going on about the IPv6 PI.
So the current IPv4 PI policy says "PI space cannot be reassigned to other parties but the IPv4 policy documents also defines IPs used to connect end users to the provider's network as that provider's infrastructure. So, providers that connect their users in some way, can actually use IPv4 PI space and many of them actually do.
The current v6 policy just says that addresses cannot be assigned to other organisations.
So there is no provision for providing connectivity.
So, the result of this is that in IPv6 PI you cannot do DSL, you cannot do cable, VPN, cannot do colocation hosting, etc., etc., and there are pretty much no exceptions to this. There are a few problems we see with this is that there are thousands of current IPv4 PI holders who are in the business of providing various kinds of connectivity services who cannot deploy IPv6 with PI space, which is what they would for various reasons, very much like to do. And it's sometimes very difficult to explain to them why this is the case, because they come back and they say, look, you are pushing IPv6, we have to deploy IPv6 but you are making it very, very hard for us.
So, that's one point.
The other point is that in IPv6 PI requests, there is a lot, there is quite a lot of work has to be done by the IPRA to decide whether this is in service provider or where there is in end user, and I have been thinking a little bit about why, how that works exactly. And like, in the past I think the world was friendlier, simpler place, there were ISPs and there were end users and the end user would get PI space or PA space and the ISP would move the end user's packets and everything was nice and simple. More and more often we are seeing other types of things being built. We see people who have a network and some routers and switches and they put a MPLS loud and some other guy builds on top of that, and rents out his network to someone else who builds a server forms around it and on top of it and operates cloud services on that and then starts selling these cloud service to say other people who might be writing software for their clients and then hosting the software as well because the client don't want to host the software but it's important stuff maybe for banks, people like that, so they set up completely separate infrastructures for these clients that have their own data centres, their own numbers, etc., and the decision of whether this is an end site or whether this is an ISP, at some point it becomes a matter of what is your point of view? Where in this picture, on which side of this picture are you looking at it? And this becomes difficult to argue.
So it seems that the sharp distinction we used to have between service providers and customers and end users is blurring a lot. There are still, of course, many normal simple networks out there, but more and more often there is very complex services built on top of other complex services that are built on other complex services that are spread all over the globe. And which means that it's actually becoming quite complex in many cases to decide what a request is actually really about. If it even makes sense still to say this is an end site, or this is a customer, this is a service provider in some cases. With a fairly large team of IPR addresses this is a little bit hard to do in a fair and consistent manner.
Then I have some background information about the discussion that's been going on on the mailing list. If we look at what IPv4 PI is used for, and take that as a model of what IPv6 PI might want to be used for by the people that use it, we see that about a third of the IPv4 PI requests are for classic end sites and the other two thirds are spreads about equally between various types of access and various types of hosting providers. A few RIPE meetings ago, I presented on this as well, and I said that, so this means that two thirds of the end users that now have v4 PI would not be able to get v6 PI. And those networks might not deploy IPv6. Well, this is exactly what we are seeing. This is, over the last year and a half or so, the number of v4 PI requests versus the number of v6 PI requests. And this picture might make you very happy if you are worried about the v6 routing table exploding. It might not make you very happy if you are worried about IPv6 deployment in the world. So and especially if you compare this to LIR allocations, I think about 41 or 42% of our LIRs currently have an IPv6 allocation, so the number there is very different, it's much larger.
Then we decided to look at the IPv4 routing table and see if we, if we can see anything there that might mean something for how the IPv6 routing table is going to develop. So, all RIRs publish all the prefixes they allocate and assign in the so called delegated stats files, and we operate the RIS, routing information service, so we with thought let's combine these two. For to keep it a little bit simple, we decided that everything, or we counted everything before 1996 as legacy. I know it's not quite true, but we had to draw the line somewhere. And as RIS sees a lot more prefixings than a normal multihomed BGP network might see, we had to put a cut off somewhere, so, a prefix is considered to be in the DFZ if it's seen by more than 10 RIS peers.
So, globally, the picture looks like this: Almost half of the prefixes come from address space that was given out before 1996, and then a little bit more comes from LIR allocations than come from assignments. But we make RIPE service region policy so we decided to lift out the RIPE NCC allocated and assigned prefixes and then the picture looks like this. We have a little bit of legacy space and then almost three quarters of the prefixes in the IPv4 routing table come from LIR allocations. And, in numbers, this looks like this: The number of prefixes for PI space and allocations are roughly the same, but allocations, every prefix we allocate seems to expand into 3.8 prefixes, while PI prefixes stay usually at a single prefix.
Part of the reason for that could be because about roughly half of the PI that we give out are /24s, so they can't be deaggregated very far. But even if you take that into account, LIR allocation seems to be deaggregated a lot more than PI prefixes.
Are there any questions?
CHAIR: Just as a technicality, the second session today will be pretty much dedicated to discussing IPv6 PI stuff, so the real discussion will go on after the coffee break. This was just to set the stage and give you something to think about. Of course, feel free to come up and asks questions. You are holding yourself from coffee, so, I am not going to stop the queue here. I think Leo was first and Jabber, then Randy.
AUDIENCE SPEAKER: Leo Vegoda from ICANN. I just, can you remind us why there is this artificial distinction between PA and PI?
CHAIR: I will do that after the coffee break. I have a couple of slides on specifically that.
AUDIENCE SPEAKER: More feedback from remote participation. James Blessing from Limelight Networks, he says that the issues about there being two definitions being used for PI space, he says that we, as in the community, have decided that v4 and v6 have different definitions and we need to either harmonise the definitions or change the naming to make it clear that they are different. He says personally he'd go for harmonising the v6 version.
CHAIR: I am actually going to go into that in far deeper detail after the coffee break, so, thanks for Alex to bring up background, show us where the problem is and show some actual numbers so the discussion can be on a solid background. Thank you for coming and a good discussion, and I hope to see you all back after coffee.
(Coffee break)
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
67