Archives

The Address Policy session continued at 11 a.m. as follows:

GERT DORING: Somebody rang a bell and reminded me that I should be here, maybe, now. I see people still coming in, so we will wait a couple more minutes.

So, welcome back to the Address Policy Working Group. So this is what we are going to do now in the next 90 minutes. We go into specific proposals that are already formally in the policy development process. This is specifically the 2010?1 temporary Internet numbers, 2006?5, the very old IPv4 assignment size thing, 2010?7, which is a very new one about exchange point policy for IPv6, and, after that, I intend to sort of broaden the scope and discuss this in a more generic way and not specifically focusing on individual words but more about the general framework, whether we need to change something or want to change something.

Before we start the discussion on individual proposals, let me remind you of a few things:

I skipped over that slide in the first slot but of course, it applied there, as well. One important thing about the Address Policy Working Group is that we dont make discussions on the meeting, so we get feedback from you on the meeting, then we bring it back to the mailing list so it's open, documented, transparent. This is one of the pillar stones how Address Policy works in the RIPE region, so it's really, everything is in the open and this is no smoke?filled side?room policy.

If you speak up ?? and that worked very well this morning ?? please state your name so that people listening remotely know who is talking. If you are already well?known, you don't have to, but it's easier on the scribes and the remote listeners, of course. The session is webcast so people are listening from remote and watching us to make sure we do a proper job. And those listening remote can send backfeed back on IRC, RS C.ripe.net so they can really take part.

So we go into the open policy proposals, I see Nick already standing there. He is here twice, because, well, he always volunteers to do all the clean?up work, so welcome, Nick.

NICK HILLIARD: Good morning everybody. My name is Nick Hilliard and I am the Chief Technical Officer of INEX.

So, this is the temporary Internet assignment proposal, and I just want to briefly run over what it's all about here. So there has been experimental assignments available for many years. They haven't been used terribly much because address space is fundamentally fairly easy to get, so there has been no particular reason to use it so far. But in the future, IPv4 address space is not going to be easy to come by and there are many cases where people just need a small amount of IP addresses for a short period of time, and this is what this policy proposal is all about, to enable those users to get the power address space for a period of time and at the end of that period, it will be taken back to the RIPE NCC to be reassigned to a third party.

It also applies to ASN 16s. These are also a limited number resource. There are relatively few of them left and they have ?? they have different characteristics to ASNs. But I think we are going to concentrate mostly on IPv4 because that is a slightly more pressing problem right now.

So, the proposal creates a generic temporary assignment category to take over from the experimental assignments, and you can request any sort of number resource, ASN 32 or 16s, provider independent, IPv4 or IPv6 address space. And the policy, it does specify a couple of example categories, but it also leaves quite a bit of flexibility open to the IP resource, the Hostmaster team in RIPE. It contains information on utilisation rates and time frames and stuff like that. And I want to get on to that in a few minutes because there are some issues there which I think are quite important and need to be dealt with. The primary difference between these assignments and regular assignments is that they are strictly time limited. You can apply for an extension to the original time, but the intention is that these are not permanent assignments. Don't put infrastructure on them, don't put stuff which is ?? needs a permanent presence on the Internet.

And in pretty much every other respect they are the same as regular number assignment requests.

From the point of view of the RIPE NCC, the policy allows the RIPE NCC to create resource pools, and this is very important because unless you have a resource pool you can't draw from that resource pool. There are going to be a couple of changes necessary for database stuff, it's going to be automatic deregistration because probably I think it's probably just going to make things easier for the whole process.

Now, there are a couple of open issues: It's fairly clear that most people think that the general policy proposal here is a good idea, that it's a good thing, that we need some sort of facility like this to have IPv4 address space available in perpetuity if you need it for a limited time period. There is some disagreement on the details, and in particular, the disagreements circulate on what the time periods should be in terms of how long before, how long you need to register before you actually get the address space and how long after your event or your project, you are allowed to keep the address space. And there are very good arguments to say that these details should not actually be in the policy, and I have certainly been convinced of this argument at this stage. Unfortunately, we have a very serious problem and that is that IPv4 address space is going to be gone very, very soon, and I mean, we are not talking about sort of six or nine months down the line; in the worst case, it looks like the RIPE NCC will run out of IPv4 address space to assign by mid?January. Now, that is the worse case but that is only two months away from now. And when the RIPE NCC runs out of IPv4 address space it means it's no longer going to be possible to create a temporary Internet assignment pool, so we have a choice to make. We have two options: The first option is that we solicit general consensus on the policy proposal as is and we recognise that there are some details which need to be changed but that these are only details, that the policy is fundamentally a sound policy, and then if consensus is agreed, we can then fix up the minor details in a subsequent policy proposal.

The second option is to go through a new round of policy proposals to put this proposals back into, into the review stage and the problem is that this is going to take several extra weeks. And if we do this, there is a possibility that this policy proposal will fail, purely due to timing issues, and I think this would be a great shame. And I want to solicit input at this meeting on the fundamental question, which is: Is there anybody in the room who has an opinion that temporary Internet assignments should not happen, that this is a bad idea, this is a bad policy proposal, and that this shouldn't happen? There is not a whole lot here. We see one person.

GERT DOERING: Nick, thanks for bringing this up and for asking the right questions to go ahead. I see people already lining up.

AUDIENCE SPEAKER: What size of block for this reservation are you thinking about?

NICK HILLIARD: I am not thinking about anything. The RIPE NCC has indicated a /13 ?? where is Alex? It was a /13 or so or /12?

SPEAKER: It was a /13, yes.

NICK HILLIARD: /13.

AUDIENCE SPEAKER: Michael, private citizen and one of the people who complained if you dropped the timing constraints or at least stretch them a bit, I am perfectly happy with it.

GERT DORING: That is not exactly answering the question.

AUDIENCE SPEAKER: My original concern was the very strict time limit so if that one is gone then no objection so far.

GERT DORING: We cannot change that without running another round so you say we go another round, otherwise you will oppose this.

AUDIENCE SPEAKER: No, no, I am saying push forward.

GERT DORING: We cannot change the text now. The policy is at the end of the review phase. We have heard comments so we can either move it to last call if we agree there is consensus or change the text and move it back to review phase, back to the mailing list, another round of arguments, at least four weeks more delay. The question is really on you at that point since you were opposing the current wording, go ahead and fix it later or run another round.

SPEAKER: Push and fix.

GERT DORING: OK. I think that was clear word.

NICK HILLIARD: I am very sorry to have to push this on the meeting right now. Unfortunately, the address run rate has ?? seems to have increased dramatically in recent times, and the original time?line for RIPE NCC depletion, which was looking like June/July of 2011, is now not even remotely realistic.

OK, that is good. I think we should solicit just more input on the mailing list, as we can't declare a consensus at this meeting.

GERT DORING: I think what I will do is just summarise what has been said here and call for last call on that. If people on the mailing list disagree with what we are now going forward with, that is what last call is for. So there is a stopgap in there. But we can do this. We are at the end of the review phase and then we decide whether we want to go forward or not and since we have had positive feedback and the one major opposing voice has now said "go forward" this is pretty strong. Of course we will send it to the mailing list to explain the reasoning.

NICK HILLIARD: Yes. Good. Thank you very much.

GERT DORING: You are perfectly in time.

(Applause)

GERT DORING: Then let's go for the next one. I think the next presenter is Nick Hilliard.

NICK HILLIARD: Good morning. My name is Nick Hilliard, CTO of INEX. Have we been here before? This is a proposal 2006?05, and has been on the books for a very, very long time indeed. Soon, it will be five years. And so I want to give a quick overview. And the problem here is that there is an elephant in the room with regard to provider?independent request assignments and that is that most end users don't need a /24, they need a couple of IP addresses, maybe ten or 20 or 30, but they have a requirement to multihome and they go to their local Internet registry and they say, well, unless you get a /24, this assignment requesting already meaningless, and things happen and then the next thing, RIPE gets a perfectly formed request for a /24. I would suggest that there are an awful lot of lies being told to RIPE and that there is no practical way for RIPE to stop these lies from being told with the policy as it currently is.

Rules which are ignored by routine are fundamentally rules which need to be reviewed, and I think that the PI addressing assignments for multihoming end users are flouted so routinely that it is really, really necessary to look at this rule and to try and come up with a way to match assignment policy with actual reality, with what is happening on the ground. Because if we don't do this, this is fundamentally bad stewardship, the RIPE NCC is listening to lies, it is hearing them, it knows that most of the applications that it's getting are simply incorrect, but it does not have the ability to go back to the end user and say, well, look, we know you are "telling lies" even though statistically because the assignment requests for /24 are, what, I don't know 15, 20 or 30 times the number of the assignment requests for /25 and greater.

So, something needs to be done about this, too, and to fix it. And policy proposal 2006?05 was intended to deal with this. It is slightly contentious, for various reasons.

So looking at the problem, most PI assignments according to the numbered are for /24, and the numbers also indicate that most of the end users who applies for these assignments are doing so on the basis that they have a requirement for multihoming their end?user site.

And there are two options for multihoming: Either you become an LIR and you pay your upfront fees, your LIR fees and your ongoing maintenance fees, which aren't great, they are not huge and you require a /21 of PI address space, you get your ASN, or alternatively you tell a few porky pies on your application form, and you get a /24, which is really all you need. Now, one of these methods actually wastes a very significant amount of address space, which is to say the LIR option, it's the more honest option with regard to the addressing assignment proposal, but it has this deoptimisation issue that it's just huge wastage of address space. So, the current version of 2006?05, sorry there is a mistake there; that is 2006?05 instead of 2006?04. It allows end users to be assigned a /24 if, number one, they have a stated requirement for a small number of provider?independent address space, and number two, if they can demonstrate a credible intention of multihoming. And the policy mechanism that is in the policy there is that if an end user has a requirement for eight IPv4 addresses then the RIPE NCC will assign up to 248 extra addresses. OK, and this was flouted on mailing list and there were a lot of people thought how can you choose eight? Really we should be choosing four or two or even one address and that there are all sorts of edge cases about why eight is the wrong number, and of course, this is completely missing the point. Eight is a detail, and eight was chosen because, well, say you want your two end hosts, HSR peer or something like that or maybe you want one end host on a /30 with a link sub net, but the point is that the number eight itself it's not terribly important, it could be four; eight was just chosen because it's a reasonable number. The point is that where the end user has a requirement for a small number of addresses, that the RIPE NCC will pad that out to a /24 and that if there are extra ?? if there is extra IP address space required later on, that there is no way of going above this 248 extra IP addresses. So this is sort of a built in anti?abuse mechanism in there, as well.

So, most of the discussion on the mailing list has been, well, OK we think this is kind of a good idea but we just are have a little bit of problem with this detail of eight, which is kind of ?? kind of missed the point.

So, in terms of arguments for: Well, the first thing is 2006?05, the intention is to align policy with operational reality. And to create an environment where, if you are an organisation which is small and which has a requirement to multihome on the Internet and let's say it, there are no other viable options for multihoming other than getting a smaller amount of address space and announcing that on your ?? on your ASN, then there is no particular benefit to telling lies to the RIPE NCC, OK? And this will cause much better and more honest stewardship of the power address space. RIPE will get a better idea of how much space is assigned on the basis of stated assignment need and how much IP address space is essentially dead address space which is not being used. And I think that is actually quite useful. There is not a whole lot of evidence to suggest that this will involve an increase in uptake of /24s or PI space in general. The reason for that is telling a lie is free, it doesn't cost any money to tell a lie.

Opposing this: Some people have addressed, or at least have voiced the concern that Address Policy is Address Policy, and Routing Policy is Routing Policy and let's not confuse the two. I'd like to suggest that this is actually not a very practical point of view because, in fact, Address Policy has really been aligned with Routing Policy since, signs Sider was implemented in 1994. I mean, we have been assigning /24s as the minimum assignment space since then, so it's a bit of a non?issue here. The other issue well, OK, it's too late, worse case the RIPE NCC might run out of IP address spaced by January. What is the point in all of this? There is two answers to that: The first is yes, that's correct, implementing this policy will create very little operational impact from the point of view of address assignment, but there is some other reasons and I want to get on to them later on.

So, I have a list of FAQs here. And these are all things which are culled from the mailing list, all issues that people have genuine issues which people have raised on the mailing list and which have been answered but for the benefit of people in the room who may not have been following every word that is printed on the mailing list because sometimes it gets a bit intense. There is some general questions here.

Will /24 micro assignments create a new precedent for regional address Internet registry address assignment? No. LACNIC and ARIN have both supported micro assignments. LACNIC since 2003 and ARIN has supported micro assignments since 2002. They have changed that to /24 in 2010. But it's been supported since 2002, which is a long time. So there is no ground?breaking sort of address assignment criteria change being proposed by RIPE here. This is old territory that has been rehashed by other RIRs before the ?? over many years ago. It's too late. OK, yeah it's too late, but we will get on to that in a moment.

So this proposal is going to make multihoming really, really cheap and that is a bad thing and it's going to make PI more favourable to PA. Well actually, not really. Because, first of all, the existing policy says if you tell a lie, your lie is free and it's not actually any more expensive than telling the truth. But also, the cost of multihoming is not zero. If you want to multihome, you need your routers, your servers, you need clue, technical clue into installing a system, a multihoming?based system, you need staffing, ongoing maintenance support and a whole pile of other things, and OK, you can sort of be the cynic and say that costs zero. But the operational reality is that that does not cost zero; that costs many thousands of euros as an initial cap investment and for ongoing stuff ?? yes, many thousands of euros. This is not free. And in fact, the cost of the PI address spaces versus PA address space, it's peanuts compared to this. Some people have suggested that this is going to cause the default free zone routing table to explode and that the sky is going to fall. Well, actually, LACNIC and ARIN have been doing this for years and the sky hasn't fallen yet. It's good.

This will cause address space to be wasted; well, no, it won't, because it will cause some people who are a bit more honest not to open up LIRs and that will cause less address space wastage, probably, overall.

Probably, also, won't cause any more 24s to be assigned. It does change the addressing policy in a sort of a very academic sort of way, but, in reality, all it does is, it acknowledges that there is an operational reality and that is that end users have different needs for different types of ?? for address space. Some of it is stated need for a specific number of addresses for a specific number of hosts, and some of it, some end users need the address space because of multihoming requirements. It doesn't make PI any more attractive than PA in any meaningful way.

So, yes, the important issue here, having raised the concern in my last presentation, well isn't this too late? Well, in certain respects it is, and in certain respects it probably would have been better if we had this discussion and maybe cleared it up in 2006, but we didn't. IANA has eleven /8s left, which is to say it has six /8s before we get to the final five of them and it looks like those will be depleted very, very quickly. In future, there is going to be a constant trickle of IP address space requests ?? or at least IP address space trickling back to the RIPE NCC in terms of address LIRs closing, garbage collection from proposal 2007?01. There is always going to be small amounts of address space coming through, and actually, in the post?depletion era, one of the prime concerns from the operational viewpoint is because there is going to be so little IPv4 address space, that there is going to be a huge pressure to fragment the existing IPv4 address space and to change the minimum /24 that we have as a de facto standard in the default free zone, to /25 or greater and this will cause FIB table sizes on people's router to explode, to grow really badly. If we maintain a minimum assignment size of /24 in the RIPE area, this will actually reduce a an awful lot of pressure to defragment further than that. Being an operator, having an operator's head on me I think this is a really good thing. It will save a lot of money, it will save a lot of problems in the ?? on the Internet for large scale operators in years to come.

So, at this stage, I'd like to open it up to the floor. It is a contentious issue. There probably will be several people who have questions. I see Wilifred coming up to the microphone already.

GERT DORING: Thanks, Nick, for actually picking this up. It wasn't his proposal from the start but it sort of got abandoned because it's a tricky one and he picked it up and tried to push through. Before I give the microphone to Wilifred, I want to wake up Alex because he did the impact analysis to just say a few words on what the NCC thinks the impact is going to be. I could do it but since you have done it, it's sort of direct from ??

ALEX: Alex, RIPE NCC. If you look at our statistics for assignment sizes for PI, you will see that we do something like over 2010, we have done about 930?odd /24 assignments, and fifteen /25 assignments. So that is huge gap in itself, says that there is something wrong, and I think this proposal like this might ?? well, will, like Nick says, take away an incentive to maybe try to inflate requests, which, as registration services, I always think is a good idea because we'd like people to be honest to us. It will also help those very few last who actually think that this is already in place, will get very disappointed at the end of their evaluation.

GERT DORING: Thank you.

WILIFRIED WOEBER: User on the Internet: Whether I like the proposal or not, is a secondary issue for me here in this discussion. Some of you know my preference. A point I want to make here is that if this proposal goes ahead, I would strongly suggest that we completely do away with all the fuss of proving to the IPRAs that you have the need for eight addresses, that you have the need for hot standby routing, that you have the need and have plans for doing whatever. The data we have collected by now, and I think this is also supported by Alex, is that people always find ways to get a /24, and if we do accept that, whether we like it or not, just make the whole thing as simple and as cheap for everyone involved, and just openly state what you want to achieve, a PI is a /24, full stop. And if you apply for PI, you get a /24, full stop. No decisions by IPRAs, because the proposal you are making just now is shifting the phony lines of argument from the requirement for a number of addresses to a phony requirement for a particular configuration of the network. And I think that is equally broken, it's just different.

GERT DORING: There is a bit more to it actually. The question is what happens if somebody comes back and asks for a second /24, third /24, so this ?? the approach with having some sort of well?justified number of addresses, whatever that number is going to be, and then you get some slack space. That slack space is spread over all your PI applications. So if you come for a first one, get the /24 with one documented addresses needed and then you come for a second one, this policy is not going to give it to you. So it's not like you can get as many /24 as you like without having any need. It's up to 248 addresses can be sort of slacked, but then the next one you really should have the full need. That is the idea behind the current way it's formulated.

NICK HILLIARD: Sorry, if I could take Wilifred's point there. What you are suggesting is that the proposal has moved the addressing requirements from /24 to /29, which as you pointed out, is quite artificial, and your suggestion is to move it not /29 but to /32 which means that you are shaking your head.

AUDIENCE SPEAKER: I personally got /27 PI as customer and have a lot of problem with routing such small prefix and need to pay the same fee as for /24. So it does not sense to get smaller prefix for end user because he has the same difficulties and he will continual lie as before. It's more easy to get 24 and have some ? future.

NICK HILLIARD: Yes, I take your point. You were not given the advice that lying was the way to get what your requirements were and that was good from the point of view of honesty, but unfortunately it's hurting your operational requirements and the point of this proposal is to assist end users like you. So I take your point.

AUDIENCE SPEAKER: Rob Seastrom from Afilias. I would like to emphasise the benefit of this proposal I don't think Nick has paid adequate attention to, which is the ready good effect of this would not be making it easier to get /24, it would be removal of an incentive and a pervasive intestify to lie to the RIR which results in a cultural reverb aeration that it's OK to lie to the RIR, which ends up evading other interactioned with the RIR so I think cutting that off at the beginning to increase the level of honesty, can only be good for better stewardship of what resources we have left.

WILIFRIED WOEBER: Just coming back to your suggestion that I would want to move the boundary to /32, no, my suggestion is actually to agree on a granularity for PI, which is /24. No questions asked. If you sort of satisfy the criteria to apply for PI, whatever they are, then you get a /24, no questions asked. I agree with Gert here that if you want to have an upgrade on that then you probably would have to supply an address plan or to make that reasonably obvious that you need more than a /24. That sort of ?? I dislike this thing, if you have got at least eight and if you have got that particular technical set?up, this colleague was saying if you can prove you have got an old machine, there is lots and lots of credible technical requirements and I do not want to see the IPRA being involved in getting into those discussions because it's just expensive for everyone and the result, as you already represented, the result will, anyway, be the same, the guy or lady will get the /24 so why don't we start with /24 from the very beginning.

NICK HILLIARD: I think we are coming at the problem from a slightly different angle, that we agree. That the reason that the wording was made the way it was, was to ensure that for end users who were applying for second and subsequent PI assignments, that there would be a mechanism in there to provide full justification and that at most, they are sort of buffer space or their slack space would at no time exceed what was considered reasonable. But yes, I think your point is completely valid, yes.

GERT DORING: Let's play the ball to the NCC. I would say, Alex, what would you think makes more sense to you, something like this or something like very basic you ask for it, you get a /24, granularity of 24, no smaller bits and pieces of assigned. What is less work, what is more problematic for you?

ALEX: I think because the eight IPs Nick has in the proposal are actually also intended for the subsequent assignments, to make sure there is not slack space in both /24s, I think if you look in practice, the request where there is a real need for one IP or two or three, up to seven, less than eight, is very, very rare, so functionally, in practice, I think both versions will work the same way and then perhaps just setting the granularity at a ?? at a /24 is maybe a bit cleaner in policy text, but functionally I think they will be nearly identical in practice.

GERT DORING: OK. Thanks for that. I see nobody else queuing up any more. Technically, we are at near the end of the review period so that ends tomorrow, and then we decide whether we have enough consensus to go to last call right away, and I don't think we have enough consensus yet due to too many concerns about the specific wording.

NICK HILLIARD: Yes.

GERT DORING: So I would suggest to take the comments into account, do a version 2.1, adjusting the wording or maybe just going to Wilifred's suggestion with /24 granularity, do a short review phase of two weeks and if everybody agrees, then we can go ?? we can do last call and get it implemented before end of year.

NICK HILLIARD: Yes. OK.

GERT DORING: I think we can do that but, well, it's up to you, you are the proposer.

NICK HILLIARD: I think that is probably a sensible approach to take, and as I said, it's not particularly time critical in the way that the temporary Internet assignments proposal is quite time critical. It doesn't actually matter terribly much as a long?term proposition whether it's ?? whether the consensus is achieved before or after depletion occurs, so, yes, we will take this into account and post a new version to the mailing list. OK. Thank you very much.

(Applause)

GERT DORING: Yes, thank you very much for actually taking up this tricky one. It has been there since four years and thanks for closing the lid on it. Now, Sergey, Going from the v6 to 6 we have this special case about IPv4 assignments to exchange points, and that one seems to have a little bit of its own problems.

Sergy: Let's talk what is going on with IPv6 for IXP policy now. Some history moments this document was created in 2001 and the the same time when Cisco IRS implemented IPv6 in their software. It was perfect document at that time because RIPE got some small IPv6 address space and need to share this address address space. With Internet exchange point is good idea, should be first who need deployment of IPv6. For nine years, document changes was very small. First, in 2002, set of template is going to separate documents and one year ago additionally it was the ability to obtain IPv6 for IXP directly from RIPE.

Current practice: RIPE assign one /48 prefix from 2001, 7F8 /29 block, exclusively to IXP, and at current moment 92 prefixes already assigned. 29 of them has a route object registered in RIPE database. Also we know about good project of EuroIX, list. There are now 127 IXP at this moment. But 54 from then, it's 42 percent, does not obtain IPv6 here. But now we already have some relation of current RIPE 451 policy. Nine of them does not IXP any more and eight of them does not exist completely. I understand how it's occurred because they obtain their address space long time ago and something from them like ?? something don't know what to do with it but it's just fact.

Another interesting statistics from RIPE, it's available on public FTP site. You can see how many resources delegated to top 10 countries for ASN IPv6 and IPv4. You can see Ukraine, it's my home country, on position number 5 in IPv4 list but we are only 18 in IPv6 list. Why it's not normal situation because every country should be in the same position in both lists. Because RIPE refuse IPv6 request for our National Internet Exchange point, we got response, unfortunately we cannot assign you IPv6 block because your policy to join is not clear and open, so whole country now cannot use IPv6 because ISP could not exchange traffic between them, more than half of all traffic exchange inside our Internet Exchange point. What we have at current moment when error of IPv4 going to end first, any end user can obtain IPv6 without any problem; it's very easy. First IPv6 allocation for LIR is absolutely free. It's very good.

Second, we have several ISP and known customers who obtain special addresses from ISP block and we are led current policy and that very important thing, any real Internet Exchange point could be refused because different region of the open word. If you IXP, you are affected. If you require ISN number from member to join, you are not open. If your members have right to hold about peering with newcomer you are not open. If you require local licence to join you are not open. If national IXP does not allow international members, it's always not open. Any ISP has several restriction and limitation. Any of them could be recognised as not open, at my proposal to solve this situation very easy. Remove one word "open" from current policy. That is all.

(Applause)

GERT DORING: Thank you for bringing up the problem. I would like to have my slides back, if I could. Here we go. This is the specific policy text that the problem is about, the text says this policy is for Internet exchange points. What is that? The definition is an Internet Exchange point is defined as a physical network infrastructure late 2, operated by a single entity whose purpose is to facilitate the exchange of Internet traffic. And there must be a minimum of three ISPs and there must be a clear and open policy for others to join.

In preparation for today, I went and talked to the persons listed as original authors of this policy and tried to figure out what they thought that the policy should mean, and whether this is a misinterpretation or a sort of misguided policy, and we have the interesting situation that they disagree on what the "open" means here. One of the authors is Leo who is now working at ICANN. He says "open" means openly documented, so you can find out about the policy, but of course, there are restrictions, every exchange point has restrictions, and the other one is Timothy Lowe, who says "open" means open as in open to anybody, with just a different interpretation. And so we have a problem here, and the current NCC interpretations is open as in open to anybody, so they couldn't get a prefix. And what we can do now is either agree on what we think this should be or change the text, but I am personally sceptical about removing the word "open" from policies. Rob, I think this is about what you are going to say.

ROB BLOKZIJL: Yes, in the first place, Sergy, I think you gave very clear presentation of the problem. It is triggered by your problem ??

Sergy: It's not only my problem

ROB BLOKZIJL: That is the second part, it was triggered by your problem. But I think you gave a nice analysis how things have not been implemented as one might think. So, yes, it all seems to revolve around the word "open" and you are absolutely clear there is not a single exchange point in the world that is open as the total open as one of the authors thinks.

So, I must say, I am personally rather disappointed that whereas the RIPE NCC has been using this to allocate blocks to exchange points which are not open in the most open definition, every exchange point has requirements for joining. And that is healthy. That certainly you fell out ?? you have dropped down from the table. I am disappointed with that procedure, but that is a procedural question which the RIPE NCC internally has to solve. I think if we have policies that are open for misinterpretation, by not helping the community in getting forward then we should change them or ?? well, clarify them; that means change the text.

GERT DORING: Fully agreed.

ROB BLOKZIJL: I think it is absolutely needed and I also am a bit worried that if we go through the whole PDP, which we have to do, that our dear colleagues and friends in the Ukraine are being put in a waiting mode for, I don't know, two or three months or so, or 19 weeks I think is the shortest period. So, I would urge the community to solve this editorial problem as quick as possible and I would urge the RIPE NCC to find an immediate solution.

GERT DORING: I think I will skip the queue in this point and let Alex respond.

ALEX: I think that is possible in this case. As registration services, this is open to multiple interpretations. We did a while ago, we did some digging in old archives etc. And the result of that we chose the interpretation we chose, but in a way that is quite similar to the 80% rule we discussed at the last meeting. That was also open to interpretation. And as registration services, in cases like this guidance from the Address Policy Working Group about how we should interpret things, is something that we are very happy with and we will be happy to change our interpretation in such cases as this, if there is clear guidance. Any proposal that goes through the PDP to subsequently clean up the text so there is no more chance for misinterpretation, is, I think, a separate process from that. Yes. So.

ROB BLOKZIJL: So actually, in my simple minded mind frame, I see two action points: One on this Working Group to agree on a better definition of "open," which makes it possible to give, in an agreed way to all exchange points, including the ones we have received, make that legal, because none of them is open, in the most open sense. That is an action on this Working Group, on the community.

And action on the RIPE NCC is to not wait until that has gone through all the processes but to realise that the situation in Ukraine is not different from many other exchange points that have received an allocation, and to find a quick solution for this particular problem.

ALEX: We don't deny many requests under this policy. Most of the cases we have denied the requests, it was in the ?? the issue was usually it was issue that existing members had to vote on whether a new member could join or not. That is ?? whether that is a problem is clearly an interpretation issue so as NCC, my question to the Working Group is in the correct interpretation of the word "open," should that be allowed or not? I would like a clear answer from the Working Group.

ROB BLOKZIJL: I am not a Working Group but my answer is, there is ?? the service area of the RIPE NCC comprises, what, 60, 70?odd countries. There are differences, cultural differences, there are legal differences and we should not try to make the differences a stumbling block. We are here to coordinate and progress and I personally remember, I don't know whether it is still the case, but a couple of very large exchange points in Europe which are based on the legal constrict of membership associations that have this requirement. Maybe not for admitting but certainly for kicking out, for discontinuing a membership. It's a membership organisation. The RIPE NCC is a membership organisation, so you could ?? ipso facto say does not open or ?? so let's not quarrel or discuss about the exact meaning of the word ?? oh, no, that was Bill Clinton who had such a discussion. "Open" was the word I was looking for. For some reason, we have created ?? no ?? an administrative problem has popped up; let's fix it as soon as possible. Part ?? there are two aspects: Get the exchange point going again and fix our definition of our rules. And there is a little third thing: One of the first slides gave an overview of existing practices of IPv4 and exchange points and there was a lot of dirt there. Maybe the NCC could think of doing internal analysis, how this happened, how could it be cleaned up or it's not important enough. I personally don't care. But it has been presented so it should be picked up.

ALEX: Specifically the IXPs that don't exist any more, these are direct assignments, these ISP assignments and they don't exist any more. They will be covered in the Phase Three implement takes of 2007?03.

AUDIENCE SPEAKER: I am from the Netnode exchange. I have two comments to make: One is that I agree on the term "open" is unclear, it's quite common for exchange points to have requirements such as an AS number, and there are several exchange points that, today, get addresses where the members have to prove new memberships, new members to become members. So that is one comment.

The other is that, I think we should separate the openness of becoming a member and actually get peering at that exchange point. Those are two separate things. Was that clear? Since there was one other thing, you counted it under the term "openness," that I think in your ?? you had a point there that the members have to approve peering at the point.

GERT DORING: Even if you are permitted to connect if nobody wants to talk to you ??

AUDIENCE SPEAKER: Exactly.

HANS PETER: I would be in favour of interpreting this as openly published and if you don't want to get rid of the word "open" then it could be maybe written as openly published policy for others to join. As one of the authors of that interpretation, I think that the Working Group should give that advice to the RIPE NCC and that we should clarify the text.

As a side note, the Norweigan Internet Exchange point had the clause that you needed to have the intent to peer with everybody on the exchange in order to be allowed to join. How is that openness, that is another interesting request.

GERT DORING: That is openly documented but certainly not open to everybody.

KEITH MITCHELL: ISC. I recall some of the discussion behind this because I was one of the IXP operators at the time pushing for access to for IPv6 address space. My recollection of this is that the openness was intended to mean openly documented. Internet Exchanges in Europe in general are much more open than they were in 2001. There has been significant policy change there or practice change, I should say. The ?? I don't think that enforcing the policy in the way that it's enforced in this case actually makes any sense. The main issue, I'd sort of concur with Rob's point, that there are lots of Internet Exchange operators in Europe who do not have literally open membership policies or connection policies who have received prefixes under this in the past, absolutely for sure. I think the other point is that I don't think it is RIPE's role to dictate what the policy of exchange operators should be in terms of participation, incentives for openness are good, requirement for openness I think is ?? what has that got to do with IP address stewardship, particularly for IPv6 address where we are trying to encourage deployment rather than restrict scarcity?

So, my interpretation is that this should be openly documented rather than just open.

GERT DORING: Martin?

AUDIENCE SPEAKER: Martin Hannigan, member of the Links Endorsement Panel. I think that open here was ?? is significant only in actually demonstrating that it's really an IXP. I don't think we need ?? I am not sure I understood the comments about peering and whatnot. I think once a need is established, that is good enough, it's established that it's an IXP. We don't need to get involved in the IXP's policies or requirements. I think this is more of a cosmetic surgery?like that anything else and I would urge that the RIPE NCC interpret this as such. Thank you.

(Applause)

GERT DORING: There is another one. Don't clap yet.

LORENZO COLITTI: Just from a linguistic point of view, if we want ?? I have a difficulty imagining how an exchange point that decides whether people can join or not could be called "open," so if that is the interpretation, please let's change it to public policy as in ?? clear or accessible or clear and public policy, because that is not what "open" means. If a group can say, no, we are going to exclude you, then that is not open. And if the feeling of the room is that that is OK, then we should change that to "public."

GERT DORING: OK. Thank you.

AUDIENCE SPEAKER: Emilio, RIPE NCC. I mentioned before the cosmetic surgery project, like to give an update and possibly solicit discussion here. What we are planning to apply was that line, replace "open" with there must be a clear and transparent policy for others to join. So I don't know if the community consider this as substantial change. We consider it just a cosmetic one. And therefore we put it there in the cosmetic surgery.

GERT DORING: I think "transparent" works as a replacement for "openly published."

SERGY: Could be read in different manner, because "clear" can be not dirty or shine up.

AUDIENCE SPEAKER: What I am here for is just solicit a discussion on the mailing list, here and in the main list, to have feedback, either in removing "clear" as well or adding ? I mean, the intention of the policy were clear and understood, I guess, by discussion here. There were some doubts that for the cosmetic surgery project were considered only editorial. If you see replacing "open" with "transparent" a substantial change, then please speak up here and in the mailing list, either for this proposal or for the cosmetic surgery project. That is it.

JAMES BLESSING: James Blessing, Limelight. Going forward, could we do two cosmetic changes? One is go from "open" to "published" because that is what the intent was as far as I can work out; and second, change ISPs to networks.

GERT DORING: Good arrangement, thank you. Things have changed a lot since we wrote this, and at that time, one of the drivers for having some clauses in there, what is an IXP and so on, there was no PI and people were afraid that this might be abused as a way to get PI space in v6, so a few stop gaps were put in there, not too strict but at least some, so this is why we are in this mess today.

From what I hear from the Working Group, I haven't heard a single person that says an exchange point should be open to everybody, so at least in this room, there is agreement to go for the policy must be published, must be well?documented, but not open for anybody to join, so I think is that enough guidance for you?

ALEX: Yes.

GERT DORING: The NCC is happy with that and we clean up later on. Thank you for bringing this. Thank you for your feedback.

(Applause)

So, it's actually me again now, having two microphones, which is cool. Sorry for the outage, by the way, on that screen that you have noticed, there was a problem with the cabling and so on and thanks for ops for fixing this quickly.

One of the things that has been sort of like on and off every now and then is IPv6 provider?independent addresses. And the difference between IPv4 provider?independent space and IPv6 provider?independent space. There is one ?? the basic idea behind it is the same: It's you want to be independent of any provider, you get independent address space, which seems to be sort of like obvious and no big room for discussion, but the real world is a bit more complex, so the IPv4 policy has a very explicit clause in it that says, if you want to number the interconnect network to somebody else's network with PI space, that is fine, which means number the other party's router with your PI space is fine. This got interpreted as you can run a whole DSL network with ten millions of different customers on PI space because in the age of NAT, the only thing you do is number the other person's router. This has not been challenged and this is common practice in IPv4 these days, there is providers that run on provider aggregatable space and others on IP space. This is before v4 is going to run out. We are not going to change to v4 PI policy. Now these networks come up and say we want a block IPv6 PI addresses to run our business as such and the NCC turns them down saying there is no such clause, so if you want to number a ISP network and give your customers addresses, do it properly and get a PA allocations, become a LIR give them /54, 56, whatever, which I think is a good thing. You shouldn't give single addresses to end users in v6. That is one of the aspects.

The other aspect is that v4 PI basically is come ask for it, get it, and v6 PI requires the intent to multihome, which brought up discussions about how strict should the NCC be, what is multihoming, how can the NCC verify multihoming. It's there because you, the community, wanted it to be there. Basically, it's part of a stopgap measure to prevent opening the floodgates so it was the need for multihoming with PI in lieu of another technology was acknowledged and PI was open to satisfy that need. But maybe we need to go further on today.

One thing that also comes up is hosting providers, like you run a data centre, it's sort of basically all this Euro Network but this customer machines in euro data centre. So are you permitted to use PI space for that or not? And especially here, the boundaries are very fuzzy. Like some things are pretty clear. If you run the service, there is virtual machines in there, you run the virtual machines and all your customers are permitted to do is upload web pages, they have no admin rights, they don't own the machines, it's ?? you put IP addresses on it. The network doesn't change if the customer buys the machine but all of a sudden it's the customer's machine and you are not permitted to sub?assign PI. That is sort of tricky. What happens if the customer purchases three recs with power and Internet access, ubt it's all in the same network. Can you give him PI or not. That has been under discussions for, I think, three or four RIPE meetings now and it has been on the mailing list. Some people seem to be unhappy with the current state of affairs, but nobody has been unhappy enough yet to come up with a formal request to actually change this.

So I want to bring it out in the open, that yes, there are differences, they are there because we put them there, and if we have a problem, we can change it; if we have no problem, we just need to acknowledge that there are differences. Alex has volunteered to come forward with some statistics from the NCC that show how these differences play out in the past. If you could come up.

ALEX: In a previous RIPE meeting, I presented also a little bit with Herrs mentioned that the policy differences between PI or v6 and v4 PI space and now because ?? now, we have some experience with assigning IPv6 PI space, we actually have some statistics about what goes on, so I have got some graphs for you.

This is to put IPv4 PI in perspective. The blue bars are the number of PI assignments we make, the and the red number of LIR allocationed we make, as you can see here in the RIPE regions in terms of prefixes the PI space is more than half of the Internet if you couldn't it it in prefixes and not in size, because the PI sizes are much smaller. So we are talking about a significant part of the Internet here. Now the size, average size of PI assignment has doubled over the last five years going from /23 to /22 while the average size of a PA allocation is much larger. So in terms of address space, PI space is only a few percent of what we do.

Now, if we add IPv6 PI assignments to it, it's those little green blobs in the corner there, it's not yet picking up very, very quickly. So then if you look at what happens with LIRs and IPv6 allocations. I didn't try to do any stars, two stars, three stars. I just looked at, do they have an IPv6 allocation, because I figured that would be the first step on their way to actually deploying it, and about a little over 30 percent of our LIRs have an IPv6 allocation so they have taken at least one step in the right direction.

Then if you look at PI space, and it's a little difficult with PI space because not ?? it's not always clear if one organisation ?? how many PI assignments one organisation holds. The 2007?01 project is helping to make this much clearer but it's not as clear yet as with LIRs, although most organisations that hold PI space or maybe nearly all of them, are small organisations and they have a single PI assignment. So for PI space I looked simply at the number of assignments and number of prefixes we have and the picture changes quite dramatically then. And we saw that in terms of prefixes and perhaps meaning in terms of organisations, PI space in the RIPE region is a little bit over half of the Internet and this is how much of that half has set the first step to deploy IPv6. So there seems to be some work to be done there.

Now, to relate that to what Herrs said about the differences in policy, I did a small analysis of the PI ?? IPv4 PI requests that we get these days, and about ?? there seemed to be evenly spread about one?third for access providers like DSL, cable, that kind of thing, about one?third are various kinds of hosting providers and the final third is the classic end user, end?site type organisation. So and we have had requests from these providers, these small hosting providers, DSL providers who had IPv4 PI coming to us and saying we would like to use your brand new IPv6 policy to deploy IPv6 because we know the world is going to change and we'd like to get on with it and we have had to deny these requests.

Yes, these are my statistics.

GERT DORING: Thanks forgiving us background info and some numbers. To make it completely clear from my point of view, it does not mean we have a problem here, just a difference; and the difference is there because we put it there. If everybody agrees that it should be the way, because providers should have provider aggregatable space, then we are fine. It seems everybody is quite hungry. So this is the first time nobody is actually standing at the microphone.

AUDIENCE SPEAKER: Owen DeLong, Hurricane Electric. I think this is important that providers be assigning more than a single address to their end customers in v6. I think that using the provider?independent policy to do DSL networks in v4 was kind of a perversion of the policy and I don't see any reason to bring that forward into v6.

GERT DORING: Yeah, well, I fully agree with that, that the benefit of v6 is that we have enough addresses for end users to be assigned network blocks and not single addresses. I see Wilifred coming up.

WILIFRIED WOEBER: With regards to the terminology we are using here, like we have seen in the previous discussion, like there is content providers, there is the industry is evolving, also in the IPv6 thing there are entities around in the real world which do not easily fit the definition of ISP. They are still valid organisations and they have a valid right to deploy this PCP IP?based technology. And in my point of view they have a right to be part of the global management of the unique resources but they will not necessarily fit the historical mindset of an ISP. And one of the things where we had some private discussions over the last few days, one of those typical types of entities maybe things, maybe organisations working in the health services industry. We have one of those cases at the moment where we are discussing how to mutually understand what the other side of the game is expecting and is doing, and there are some more rough edges in the wording of the policies which eventually triggers the IPRAs to do things which we did not expect to happen when we worded the policy and that also goes into the area even if you happen to be multihomed, is the alternative path probably being visible on the global DNZ. And there are quite a couple of industries where this is probably not to be expected. So there is quite a few things which we should keep in mind when we also do the cosmetic surgery thing, like to review the wording, like is this still in line with how the industry looks these days. And in the future when we develop new policy, that we sort of do not set things in stone which we need to adapt to the industry going forward and sort of also IPv6 related collecting real information by trying to do it, instead of, well, this is probably how it's going to be. Thank you.

ALEX: The Internet is constantly evolving and we see that because for years we will get certain types of requests and then, all of a sudden, technology shifts or fashion shifts and we start getting very different kinds of requests, things like virtualisation, and that, they didn't exist ten years ago and we are having to deal with it now.

GERT DORING: That is basically why Alex constantly volunteers to stand up there and bring insights from day?to?day business. Just for the record, you don't have to be an independent provider and get LIR address space. Maybe the wording "provider aggregatable space" is misleading here. You don't have to be Internet provider; you have to sign the papers, and there are lots of organisations that are not classic providers and do so because it fits their needs.

ALEX: Wilifred did mention something which is also a difference between IPv4 and IPv6 PI and similar things have already popped up today, and I happen to have a few extra slides. May I?

GERT DORING: Sure.

ALEX: There is another difference between v6 PI and v4 PI. V6 PI requires the organisation to demonstrate that they multihome, and this happens to be a requirement as well for AS numbers. The traditional way we have dealt with this is to, in the request form, ask what are your peers going to be, and we'll get the AS numbers and contact e?mail addresses, we will look at that, and see if there is something funny, if we have a small organisation based in Berlin that lists one other organisation in Chile and one in Japan as their peers, we might wonder what is going on and ask some questions. In practice, we do not always contact these peers. If everything looks perfectly normal, contacting the proposed peers and asking if they are actually going to peer with them would add days and possibly weeks to an otherwise very, very simple request.

So if we don't see anything strange we tend to not do that. What we have done is to come back to that request, to that ticket, about three months after we had made the assignment and to see if it's actually multihomed. The results are something like this: For both AS numbers and IPv6 PI, a little bit over 50% are not multihomed in the three months. We have been sending some e?mails then and telling people that being multihomed is actually a requirement in the policy and they should get themselves multihomed, and six months after the assignments, more than 20% for both of them are still not multihomed.

Now, as this period gets longer and longer, it puts us in a strange position especially with IPv6 PI, we need to deploy that stuff. We see what appears to be a violation of the policy. And that might push us towards saying, all right, maybe if you can't comply with the policy, you need to hand back your resources. But on the other hand, that seems to be a very strange thing to do with IPv6 space and tell people you seem to be deploying it but you haven't quite finished your deployment today so just pull everything back. That seems to be a strange thing to do as well. I am wondering if the room has any ideas about this?

RUDIGER VOLK: Alex, one question is what do you ?? what criteria do you actually use for detecting or figuring out whether someone is multihomed? Is it multihomed between at least two ASs that are actually publically visible or would it be sufficient to be with two other ASs which are actually distinct and, well, OK, maybe not connected globally?

ALEX: Two separate ASs. We are aware that not everything is visible in the global routing table, of course if we check and RIS produces lots of peers and paths, then it's clear, it's simple, everything is publically visible, we can go back to sleep. If it's not, we will contact them and say you appear to be not multihomed and we get differing responses. Most of the cases they are actually single?homed. In some cases multihomed but only to the other peers, we only ?? we have no exports yet so you are not going to see this, and that sort of thing is fine, as well. It doesn't have to be publically visible or visible in our RIS systems; it's ?? we are fairly flexible there.

WILIFRIED WOEBER: Well, actually, this starts a very interesting discussion because in the long run, as you say, the RIPE NCC gets into a difficult position, true, but at the same time, also, the holder of the PI space gets into a pretty difficult position potentially, because if there is a real situation where this address block was multihomed and, for whatever reason, you could not imagine or look into the future for two or three years, you lose one of your peers and the RIPE NCC continues to double?check whether you are still multihomed, you have to live with the situation that you might have to give it back in two or three years' time to the RIPE NCC because the RIPE NCC verifies you are no longer multihomed. And if you look at some of the organisations that have to do planning for larger timescale than a couple of months this would, in my personal opinion, completely invalidate the concept of PI, because, for example, like medical university or a hospital, moving on to some different type of connectivity, if you come back in three or four years and ask would you please give back your IPv6 address space and move to a different PA or whatever, that is not going to fly. That is the long?term vision from the other end. That was your end but this is the customer's end.

ALEX: Yes. I understand that side of the story, as well. So that is one of the reasons, also, why I am up here.

GEOFF HOUSTON: I am a little bit confused by this and maybe you can help me. There is no such thing as 1918 space in v6.

SPEAKER: There is.

GEOFF HOUSTON: There is no reserve blocks that I can use, I could normally come to RIPE and request some space.

GERT DORING: There is ULAs.

GEOFF HOUSTON: If I choose not to use them because I don't want to play that game of roulette and I want a unique numbered block, I would come to you and get PI space for private use and then have to demonstrate multihoming?

ALEX: Yes, that is one of the policy sets.

GEOFF HOUSTON: Could you give me a clue as to how I could do this.

ALEX: I don't think you can.

GERT DORING: Under the current policies you will get PI space if you demonstrate you need and actually do something about it, that you want to use it for multihoming. So if you use ?? want to use unique globally guaranteed unique space for non?Internet purposes, this policy doesn't cover it. Let's phrase it that way. It hasn't been put into the policy yet, so you can't get it.

GEOFF HOUSTON: So you are saying that if I wish to have assured uniqueness, not statistically but really, for private use in v6 at this point, there is no clear way of doing this with the RIPE NCC's policy framework?

GERT DORING: There is only no clear way, there is no way.

GEOFF HOUSTON: Thank you for resolving my confusion. I am not saying good or bad, I was just confused. So thank you.

GERT DORING: That is pretty much the idea. The v6 policy people say we need BGP based multihoming.

GEOFF HOUSTON: It's not a value judgement. I was just trying to understand if there was a gap there or not. Thank you.

RAYMOND: I think if I remember well, correct me if I am wrong, that in IPv4 to get PI space, it's not allowed to have as the only reason to be multihomed, it's not an issue, it's into the reason to get PI. In v6 you have to, so what am I going to do with an organisation that definitely needs PI and wants to be ?? dual?stacked?

ALEX: In IPv4, routing reasons is not a reason to request additional space, is what it says. Which we take to mean that if you need one IP, you cannot request 255 IPs extra just to make your routing a little bit easier. We do ask people once before PI space but the policy doesn't actually provide any any information about what would be good reasons or bad reasons, so v4 policy is very different. If you want v4 policy to multihome and because you like PI space, that is good enough. If you want IPv4 PI space because you want to use it privately, that is also good enough. V4 PI policy is very broad, very flexible and nearly everything fits in it except sub assignments. And v6 PI policy is, it was made because of the reason that people said we need BGP multihoming and so it's very much centred around that.

GERT DORING: We are into the lunch break already. I think a number of quite important points have been brought up. I would basically leave it at that. Thanks again to Alex. If one of you feels that the gap in the current v6 policies is big enough to really cause problems for enough people, that it's worth changing the policy, by all means come and speak to the Working Group chairs, come and speak to Emilio, bring up a specific proposal to get it changed. Expect some resistance, the PI policy has been a difficult one and it's restrictive because that was pretty much the only way we could get it in place at all. So I am quite happy to have it at all. But the times have changed. If we need to revisit it, that is fine. Somebody needs to put up the hat and say "I need this changed" and go forward with it. Enjoy your lunch. We will be back here tomorrow morning at 9 o'clock. Some scheduling thing is against me this week. It's always 9 o'clock in the morning. Enjoy your lunch.

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE