Live Transcription - Wednesday - Address Policy WG
Note: Please be advised that this transcript is the output of the real-time captioning that was used on a trial basis during the RIPE 55 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.
SPEAKER: Good morning, everybody. And welcome to the address policy working group. Since we are already four minutes past 11 I would say we start now. Well, as you can see this is the address policy working group and I have the honour of chairing this, my name is * * and one important announcement, this session is being webcast so if you want to participate in the discussion which we would welcome, of course, please go to the microphone so that people really can hear you and state your name and affiliation so people know who the speaker is. If you are coming up for the fifth time, of course, there is no need to do that, but yes.
As for today's agenda, we have in the beginning we have some formal stuff, like thanking the describe and /SKWR*EB relay from the NCC, approving the minutes from last RIPE meeting and reshuffling the agenda, if necessary. Then, as sort of a traditional item, I don't know for what reason we have again some Co. chair changes. Then I am going to give a very brief overview of the policy proposals that have been concluded since last meeting. This is basically the same that fill east did in the previous slot but Thor those who have not been there. Then we have the main focus for today is generic discussion on PI addressing. We get some feedback from the NCC board on the contractual thing that was discussed last time. And based on that, NIC Hilliard will then try to will steer the community towards a decision how to proceed with that. And then we briefly mention the other open PI related proposals. And lots of discussion, of course. There is about one hour of time reserved for the PI discussion so we should have plenty of time for that. At the end of today's time slot Leo will come up with a fairly radical proposal to restructure the IPv6 policy and then we will have some more discussion and then lunch.
Tomorrow, we have the early morning time slot and this is mostly dedicated to end of IPv4, so everything related to IPv4, count on IPv4 soft landing, whatever proposals and discussion go to tomorrow's time slot. Also, we will mention the current state of the two other currently open policy proposals, and we have time tomorrow for any other business, new policy proposals and open microphone.
So, based on this, do you see any need to do changes to the agenda? OK, nobody an is jumping up and down so we use this agenda.
I want to take this opportunity to thank the folks from the RIPE NCC that have volunteered or have been volunteered to relay from the /SKWRA*B /RA and to take notes. Thank you very much, this is really important work you are doing. Please give them an applause.
(Applause)
The last formal point is approving the minutes from RIPE 54. I have sent the draft minutes to the mailing lists and haven't seen any comments on them so unless somebody stands up now and says all these minutes are completely wrong, I said something different, I would declare them final. So do we have any comments on the minutes? OK. So, I declare the minutes from RIPE 54 as final and we go ahead.
The chair shuffling I mentioned before, currently the address policy working group has three chairs and co chairs, that is me, Sander Stefan who came on board last RIPE meeting and has been helping me very much last season, and we have Andrea * who cannot be here for personal reasons and basically that is the reason why he is stepping down, because well personal reasons, change of job and stuff is keepinging him from spending enough time on address policy matters and so he volunteered to step down. Thanks to abray I can't for your help in the last years and please give him an applause.
(Applause)
We are not going to spend time today on trying to reorganise the chairing. I think for the time being, we can work with two chairs, that seems to work out pretty well. If one of you is so interested in doing well community work, that he wants to volunteer, please speak to sander or me over the next month or today at the social or whatever.
Short summary on the concluded policy proposals since last meeting. We had 2006 02. That was basically getting rid of the 200 customers rules in the IP 6 allocation, that was accepted and implemented. We had 2006 04 the requirement for working contact e mail addresses. That was withdrawn from the proposal because we hadn't been able to come up with consensus on that. 2006 06, the IPv4 maximum allocation period that was changed from two years planning time to one year planning time and it was accepted and implemented.
2006 07 the first raise in IPv4 assignment window, be more liberal about the whole assignment window thing and come with audits later on if you mess up. That was also accepted and implemented and all of you that have been done proper bookkeeping have now an assignment of window of at least slash 21 if you don't talk to the host matters. And then we have 2007 02, which was reopening the Anycast DNS policy criteria. That was basically withdrawn because the proposer changed job and lost interest in fighting for his former company.
If you are still if somebody else thinks that this really needs changing, you are welcome to pick up and sort of reopen the discussion on this. This specific policy proposal is now closed so if the discussion is reopened it will get a new number but of course, policy can be changed at all times.
2007 03, the IPv4 count down policy presented at last RIPE meeting was also withdrawn because there was no consensus. It will be back with us tomorrow in a new form presented by the same proposer.
And then we have the 2007 04 IANA policy for allocation of ASN number blocks to RIRs, that is concluded in RIPE and we are waiting for the other regional registries for be able to proceed to ICANN.
On that URL you can see all the archived policy proposals with all the details and what happened when.
So, coming to the generic PI discussion, we have currently three open policy proposals regarding PI space, part of it IPv6, part of it IPv4, part both, the most important one one of those is 2007 01 that is it's contractual relationship part. Right now, if an end user gets PI space the RIPE NCC has well sort of no contract with that end user. If that end user disappears, we don't know who has the address space and whether it's being still being used, we cannot reclaim it and so on. So, Nick Hilliard proposed to change that, bring up contracts between end users and the NCC or the LARs, or whatever, and the other two PI related proposals have been stalled to first sort out the contractual thing and based on that, modify the other proposals to better suit into the new framework with agreement by the corresponding proposeers, of course.
At the last RIPE meeting, we had an action item on the RIPE NCC to draft a sample contract on how such contract could look like and to check with NCC board on whether this is OK with them or whether they want a different contract or what they think about it, and so they did; actually, the public is being ready to give us feedback and, well, let's do that.
New speaker: Thanks. I hope I won't duplicate too much. But I just want to go through a few statistics there. Obviously what we ask to do we did. We looked into the matter and proposed or produced a draft contract that I took to the Board and I will talk about that. We are looking at statistics, PI related. We have since 92 made about 16,000 well nearly PI S assignments quite a loot. We loose looked how many different distinct organisations were involved with that, that should be less than that obviously. And we looked at the last few years only 4440 since January 2005. Quite a bit.
The I will just move on. The total allocated space that we did in PI is relatively small compared to the other and we see this here. This is the address space and it's basically the PI bit is just the bottom there, just a little bit, compared however if we look at assignments then, we have done more PI assignments than proper allocations and PA space. That is interesting.
Looking at where PI space goes, these are the top ten countries over the last three years where we see PI assignments going. And also we have a couple of very active members there and these are anonymised obviously. I think we more or less knew that before but it's just background.
So the goals of the proposals were to install responsible stewardship of Internet resources on the PI space. Avoiding hijacking, get the stronger link, higher quality of data between the RIPE NCC and the resource holder or user to avoid hijacking and the like. We have looked at that, we think that is very good idea.
We prepared as I said the draft contract and discussed the proposalate background for the proposal with our executive board, none of their board meetings. The board says this all sounds very good (one) intention, motivation and goals and the like; however, as they should, as an executive board, look at what impact that would have, the implementation of this proposal would have on the RIPE NCC and they think there might be quite a lot of administrative overhead involved in setting up, probably thousands and thousands of contracts. Also, it was entirely clear what impact that would have on the membership structure (not) whether those PI holders would possibly become members or have to become members. Then they are many more than we currently have in the RIPE NCC association. What would that mean?
Also, the proposal was to look at new assignments only put them into contracts. However, the RIPE NCC is based on fairness and neutrality and the like and we think we should look at all of them, of course that is a bigger number then. So basically the executive board, while supporting the overall motivation and goal of the proposal, and the direction this goes in, thinks we, in the community, should discuss this a little bit further and see whether there are other ways of doing this or modified ways of doing this. Now, obviously, I am from the RIPE NCC, I don't have a role in the policy making process, similar to our board. We, however, of course, looked around and had some weird ideas of what one could do or maybe doesn't want to do, don't want to go into any details here, it's just some rough ideas. I sat together yesterday with the proposer and the working group chairman and Phil to go through this and basically this is my little bit of presentation here. And I would either hand it back to the working group chairman or maybe straight on to the proposer.
SPEAKER: Thank you, Axel. Well, if there is any direct question on that, I would like to take them now, but I don't see anybody coming up to the microphone so, I would just land over to Nick who has done the bulk work on this.
Nick: Thank you very much. My name is Nick Hilliard, head of operations at INEX in Dublin. This policy proposal isn't particularly anything to do with INEX; it's more delivered in my personal capacity.
Now, the original goals of 2007 01 were outlined very briefly by Axel, just to recap on them a little bit. The main issue is that we have a situation where a provider independent IP address space is more aracktive than provider associated address space. We have a lot of scope for abuse and hijacking and, you know, loss of resources, loss of the chain between the Internet registry and the end user and there is garbage there in the database and that is is a problem.
We have a situation as well where technically, you can maybe sub assign provider independent IP address space as well, the wording in the RIPE documents is is a little bit unclear in this and we just want top tighten up on that a little bit, but the fourth issue there is just responsible stewardship, you know we have a situation where there is not responsible stewardship of provider independent IP address space at the moment and we need to fix the problem.
2007 01, it could work as Axel has noted. But we don't want to do that because to be honest with you it's going to turn RIPE into an administrative monster. You know instead of being a numbers registry with an accounting department, it's going to turn it into a debt collection agency with a numbers registry wing a little bit in the corner. We don't want to do that, it's not what RIPE NCC is about.
In terms of the focus of what we are trying to get towards here, new IPv4 assignments are not particularly interesting in any real way. There has been a situation where we have had explicit support for IPv4 provider independent IP addresses for the past roughly 12 years, since about June 2005. Now, before that, there was a registry of last resort and you know there are still some registrations from that floating around in the RIPE database. Who knows if any of them are active. Probably some are and some are still used. There is an awful lot of stale information in there.
Another issue that we have is the any policy change which we implement, it's going to take a while. It's going to be May 2008 before we can really get anything actually into the works. Which means that, realistically, in terms of new IP v4 assignments we are talking about maybe 2 years, maybe a little bit more but not much more. So the primary focus on here is to get IPv6 version IP version 6 right. We have a clean slate with IP version 6. You know and we have a good opportunity to ensure that we get things right from day one and I think this is important. We need to get this policy or something like it in place before we start handing out IP v6 provider independent addresses.
We also have the policy also deals with autonomous system numbers as well. They are in issue, there is quite a lot of them floating around, you know and get again it just comes down to bookkeeping, now we have got 32 bit ASNs we are kind of sorted from that point of view.
And as Axel noted, we have a very large legacy of existing IP v4 assignments which we have to account for in some meaningful way.
So, what I would like to propose are four modifications to 2007 01. The first modification is to explicitly create a cost model for provider independent to IP addresses, and autonomous system numbers. The second proposal is to create a hybrid model where we would encourage end user address holders to use their local Internet registry as an intermediary, but, on the other hand, we acknowledge that this isn't actually feasible in all situations, and, therefore, there must be some facility for them to liaise directly with the RIPE NCC.
The third change here is to make the policy retroactive. This wasn't included in the previous proposal but I think it really needs to go into the this. We can't deal with E R Z assignments, it's just not going to work. (X). Because RIPE NCC really has no authority to create a billing or a cost model, and ERX assignments are a kind of a closed book anyway, we have a good handle on that particular problem and it's been dealt with carefully.
And most contention issuesly of all we need a facility to expire ghost registrations in situations where the registrant cannot be located and where there is no real way of actually getting in contact with them. There are several possibilities here, you know the end user might no longer be functioning as a company, they might have lost interest, they might have forgotten, there are lots of reasons why this can happen, but the policy of expiry is something that we need to address.
Now, going into these in a little bit more detail. In terms of creating a cost model, we or at least the RIPE NCC is going to have to do an awful lot of work. It's going to be very long, hard and tedious to go through a database of 12,000 odd assignments and track down each one individually, and that is an expensive process, you know, it takes time and money, Leo's Leo has indicated that even tracking down the very small number of people who were using 14/8, even that took sometime and effort but this is a problem on a much greater scale.
On the other hand, applying a cost model creates a natural garbage collection system. If somebody stops paying for a resource, then their entitlement to use that resource will naturally come to an end and this is a very important point. It is a very useful way of getting back IP address assignments which are no longer being used. It also concentrates the mind of the end user, do we actually really need this IP address space or holding on to it for whatever reason? As I noted earlier, the official RIPE NCC policy dating from RIPE 127 in 1995, is to specifically encourage PA assignments and discourage PI assignment but the problem is zero cost PI model actually encourages the opposite. We are effectively people to go out and get PI because not only is it effectively free, they can take it with them when they go to another ISP or service provider. They are not tied to any particular upstream provider. So there are a lot of advantages with PI and the zero cost model is simply another thing that acts in its favour and I think from the point of view of the policy of RIPE 127 and beyond, we need to change this.
In addition, the cost free IPv4 PI model puts the RIPE NCC funding model or funding burden entirely on the local Internet registries and not at all on the 12,000 PI and ASN number holders and that isn't fair. There is fundamentally a problem with this and we need to change it.
So, in summary, we need to change we need to charge for a number of resources.
Going on. In terms of the choice of end user relationship, RIPE NCC cannot feasibly in its current incarnation deal with an expansion from 4,000 to 16,000 contractual or at least end user contractual relationships. This is a major problem both in terms of ramp up where you need a huge amount of resources to actually implement it and then a sort of ramp down into stability. It's a very difficult process to put a company through and to be honest, it's not what we want for the RIPE NCC.
On the other hand, there are legitimate situations where it's important for an end user to be able to choose to have a direct relationship with the RIPE NCC. There are several possibilities here. One example might be say Internet exchanges, you know they may not from the point of view of neutrality, want to enter into a contractual monetary relationship with a particular local Internet registry because that may be perceived as displaying favouritism and that is something that is very important for mutual based Internet exchanges. You may have a situation where you have end users who have a troubled relationship with their local Internet registry or you may have local Internet registries which do not always act in the best interests of their end users. So we need an opt out clause here and I think it's very important to emphasise that the opt out is an opt out of last resort. It's not something that RIPE is terribly interested in pushing as a major, I don't know, money maker or whatever. Because RIPE NCC has an obligation to all its members, to all its local Internet registries not to compete with them, so it would be realistic to envisage that whatever sort of financial model is chosen for PI and autonomous system number registration, that there would be a wholesale price to local Internet registry and an effective retail price for going to RIPE directly or the RIPE NCC directly, and that the retail price would be significantly greater than the local Internet registry route.
We envisage, but we are not going to put it into the proposal, that it would be fully automated sort of web based, no human interaction, credit cards only, you know that sort of thing. And then the situation where the end user is going to choose their local Internet registry the LIR will build the end user and RIPE NCC will maintain a list of PI and autonomous system numbers that LIR holds or that the LIR manages on behalf of their end users and they would bill on the basis of that.
There are some consequences, unfortunately. It is going to mean a little bit of increased overhead for local Internet registries. We can't avoid that, unfortunately. There is significantly more increased overhead for the RIPE NCC in terms of creating and I hesitate to use the frayed an on line store for Internet resources. It's the wrong phrase, but it describes what is happening (afraid).
A transfer method is required to deal with several cases. The friendly transfer from Internet registry to Internet registry, a transfer from hostile local Internet registry at the end users' request. Local Internet registries sometimes misbehave and you know, we just need to acknowledge this.
And we also need to a facility to transfer from LIR to RIPE and RIPE to LIR just in case people to decide to change their mind, they want to go to RIPE directly and then suddenly find that billing for or being billed for a huge amount of money that is not entirely compatible with making a profit at their end.
On the other hand it does create an onus on the LIR to maintain good records for provider independent address space and for autonomous system numbers, this is a good thing. And in the other situation the end user is obliged to maintain the relationship with the RIPE NCC and the burden of maintaining the proper records will be shared between the RIPE NCC and the end user and this is also good. This is a long term maintainable and feasible way of maintaining accuracy.
Now, deviling into slightly more controversial issues. I didn't include the retroactive aspect to 2007 01 because it's a slightly controversial issue and it has quite a lot of consequences. The board, being a rather smart bunch of people, saw straight through this policy and realised intuitively that the next proposal was going to take 2007, 2007 01 and make it retroactive but I think we should just bite the bullet, make the policy retroactive in this particular proposal and just stop messing around.
As I mentioned before
SPEAKER: You are missing a there. Sorry, yes we have one or two errors here. It doesn't include ERX autonomous system numbers or IPv4 PI address space. Sorry, no, this is actually correct. It does include IPv4 space marked as PI in the registry but assigned before RIPE 127. Sorry this is actually a last minute change. For those people who are officially classified as old farts at this stage, there was a system many years ago where we had registries of last resort, you would have you know, UK dot XX or NL dot XX or IE dot XX and they were designed to hand out IP address space for people who needed unique IP address space for organisation but who didn't have a relationship of any form with a local Internet registry within the country and you have to remember that this was back in the early days of the Internet and there weren't that many people using Internet connection where Internet is spelt with a big I. They were phased out, I don't know, in 1993, 1994, I can't remember no, 1995. Thereabouts. But they haven't been around for a long time. But we need to include that, as well.
This particular policy change is going to really stuff RIPE because they have got to chase up a huge number of number holders. They have got to liaise with the local Internet registries about who gets billed for what. And they have got to create a categorisation and a means of dealing with lost registrations. And all of this is hard. It's a pain in the butt, there is no doubt about it and I really don't envy them this job. But it has to be done.
Finally, the issue of expiry. And you know, again this gets back to the retroactive application. It's going to be a painful thing, because in all likelihood, there are it is going to end up with we are going to end up with a situation where RIPE is not going to be able to contract all of the people who are still using their PI assignments. Most expiry is going to be caused by dead registration, bad contact details, that sort of thing. RIPE NCC of course is going to have to come up with a policy about what to do with expired registrations do they get put into a holding pool for a couple of years until the rest of the PI space that they assign from is used up or does it get recycled immediately? I don't know. These are questions which are going to have to be dealt with by RIPE as they are operational matters.
There are going to be a lot of situations contact details are going to be stale but we will be able to tell from the routing tables that the IP assignments are still actually active, and they may have no there may be no link between the user and the user of the PI space and the original contract or at least the original registrants because of you know for example company mergers and take overs, actually hijacking so on and so forth, so there is going to be an awful lot of chasing down and policing here. But on the other hand, we are very familiar with the idea of number expiry and you know, paying for resources and you know when we stop paying things just go away. We have it for phone numbers, when you stop paying for your phone number it gets recycled after a short time. Similarly with domain names, you stop paying, it gets expired. You know, so, what of it? And fundamentally, no expiry is bad stewardship of resources. Bad information is as bad and possibly worse than no information at all. So, you know, it's difficult to understand why RIPE is still maintains these ancient records, you know from a certain point of view it would make a lot more sense to just be more upfront and just say well look, we don't know who really holds this PI address space any longer, we don't know if it's active, but we are going to just mark it in the database as being unknown and somehow or other we are just going to deal with it and try and chase down the assignment holder.
And fundamentally, there is a policy change here. We require a heresy, we require end users to maintain some level of responsibility for their registrations. This is quite a change from a lot of other policies maintained within RIPE, it all goes through local Internet registries but in this case, we actually require end users to maintain responsibility.
So, those are the four changes. This is a difficult proposal. RIPE are under no illusions about the fact that it's going to take a lot of time and effort. And we would like to hear what you have to say.
SPEAKER: Nick, thanks for detailing this and all the, well, necessary /PWRA*BG. I see Wolfred already standing up on the microphone, I hope that we will have more input from you. Some more things, I have been thinking about, we haven't mentioned how much the yearly price for a PI might be in the end. Based on the budget of the NCC and the amount of PI blocks out there, I think it's likely to be somewhere between 100 and 300 euros a year. If it's much more expensive the NCC is going to make it a surplus and they are not supposed to do that. If it's far less, then the whole exercise is sort of not very useful, so I think that is a realistic range of money. How much it will be in the end, will not be decided by the address follow see working group, of course; that is the AGM and the board's job. So much from my side, Wolfred please.
Speak. Ful wearing the hat of RIPE da da base working group chair plus being a member of the data protection, privacy task force. To start with, sort of one question or one observation: Axel has presented us with a list of alternative potential solutions. You have come forward now with a pretty detailed new approach to the thing. Was this new version of the proposal sort of talked about and agreed with the RIPE NCC board? Because initially I was a little bit disappointed that sort of we got the ball back in our playing field with no go back think again without getting guidance in which direction we should think so your proposal seems to be going into one particular direction, which I like personally, but is this something we can expect the N cc's board in the end to ratify to accept with minor or major modifications, maybe this is a question to Axel actually. ?
Axel: Well I can't speak for the board obviously. I do see that this, let's say, hybrid proposal or implementation would make it easier for us. I see the big progress here or the big change in our favour to put some, or quite some responsibility on our members to help maintaining the link to the PI holders and that I think was the foremost concern there. If that happens to a significant amount, then I would think that the board is is a bit more positive about this. But some of them are here, maybe they want to speak. I think this is a better way than was presented before. But we have to talk to the board and see. Plus there are other implementation details here, like for instance, a fee or still some contracts or some implementation of web based interaction that we would have to implement. The fee for instance would be something for the general meeting, possibly the next general meeting in May that we could twist the charging scheme there that. All needs to be done still.
Q. OK. Thank you Axel. And the second thing is more coming from the direction of the data protection or data privacy task force. We had quite interesting discussions on Monday and many of these issues which are in your slides actually do come up in the different problem space of maintaining proper contact information, so my feeling is that all of us, we should actually get ready to give the RIPE NCC the main date, plus the resource, to do a lot of legwork in the end to chase down old or broken or outdated information and links to resource holders, so this PI stuff here is just one area where we are aware of this problem and where we are discussing potential solutions. But more or less the same problem also applies to the ERX resources and all of this actually is very tightly tied to data protection stuff, and I think we should also invite the RIPE NCC folks here which do have quite a point of view regarding this thing and also sort of to give us more details like what these things are. In the end, I think we have to bite the bullet and also do other things retroactively, like if someone actually requests the last link for a contact for a particular resource to be removed, and that may be because of privacy reasons, then, again, we have to think about what are we going to do with that resource. And our current thinking would be that we have to reclaim that, in the end, and in my point of view, this is very similar to what you are proposing here; like, if we can't come up with a contract, if we can't sort of establish that chain of responsibility, eventually we have to take back those resources and put them either on hold or back into the pool, so I think this is a very important thing and you can easily go ahead and try to solve these problems in the framework of this proposal. But the problem is bigger than that, and some of you may actually have observed this again and again coming up, bouts of mud slinging at the RIPE NCC. Like, you are responsible for providing proper contacts, which in the end is not the case, because in the end, the responsibility is either with the local registry or with the end users to provide proper information so this is a pretty fuzzy and pretty big area of things that we should probably discuss over the next month. Nick: Thanks very much which will Fred. Yes, the points that you bring up are very important and I think probably the RIPE NCC are in breach of data protection laws or at least data privacy laws at the moment in terms of not maintaining accurate and up to date information, so this is important, to deal with. Daniel?
Daniel: Daniel and I am quite explicitly only wearing the hat of old fart right now, not the hat of RIPE NCC staff. Actually, more precisely, the hat of the author of RIPE 127 which actually brought us the term PI space.
First of all, let me thank you, nickly, that you actually sort of volunteered to be the point man for this and you actually saw something that was wrong with other people also saw and that you actually took the work and the sort of responsibility of standing up there in front and raising this issue, because what we are doing with this PI stuff in my mind, and again this is just old fart and RIPE 127 author, is put things right again, because in RIPE 127 we already said, and I remember quite clearly and this was in 1995, so it was ages ago in terms of Internet time, we said we want to encourage users of PA space, we want to discourage usage of PI space and actually if you read that document it actually says in very many places, you know Internet registries both regional and local, should clearly recommend PA space to their customers and give them a quite clear consumer warning on PI space, and, somehow, that intention got lost and we actually made the stuff free, which I still don't understand why we did that, so I think this is not really a new policy that is being proposed here; it's just putting things right again and I think we should do it and I also fully agree with the last minute change that you actually said, you know, all the stuff that has been assigned through registries of last resort, should be included, because it's in fact PI space, it's just RIPE 127 just was there to clarify that particular policy. So, yes, I think we should do this. I think I also agree with most of what Wolfred has said, is that in the future, we will have to do much more cleaning up of the data and this can be the first step towards it. So I am personally again only as old fart not as RIPE NCC staff member I am very much in in favour of this policy and of the direction this is taking. Thank you, Nick.
Nick: Thank you very much Daniel.
SPEAKER: Thank you for the clear words. Todd under wood: Nick, you made an analogy of IP address allocations to the DNS system and sort of people are use today things expiring but what I don't understand and maybe I am missing something is there is a clear stick in the caret in the stick metaphor in the DNS system when you don't pay your bills your name stops resolving. I don't understand. So if you expire my whois information one my space is routed, the legacy spaces that is the existence proof of the enact this stuff doesn't really matter that much, so what if it expires? Nick: That is an interesting question and what it comes down to is RIPE are not the police. RIPE are a clearly house and a registry, a numbers registry and what they will say is look, we are a member of the community which has been given a mandate to maintain a unique registry for awful the RIPE or at least all of the address space which you manage. And if you trust us, then we will say that we we can guarantee that this block of IP addresses has only been assigned to you. If somebody else starts using that, starts hijacking it or whatever, you know, you have to take it up with them, you have to I don't know, talk to their upstream local Internet registry, their upstream transit provider whatever, but it's up to you to do the policing in this situation.
Todd: I am absolutely in agreement with that, I guess what I am saying if you take the direction you were heading with that one step further, the only thing that you could possibly do with expired registration whose fees were not paid but were still in use, is give it to someone else, right, but as RIPE who are not the police who don't police the routing tables or people's acceptance policies or customer filters you could revoke the whois information or leave it blank or give to someone else. There is not that many things you can do. Neither is very satisfactory outcome. So I guess I am suggests suggestion there is not much of a stick you can bring to people in this case and the analogy with the DNS system is fairly deeply flawed.
SPEAKER: Well, OK.
SPEAKER: * *, Deutsch Telekom. Actually, in the RIPE NCC database, there is also colocated via routing registry which is interlock by R P S S for authorisation and I would expect that cleaning up the will actually have the side effect of cleaning out all the route objects that are referencing the same address space. So anybody who is using that will have a benefit of already kind of seeing what is it called in the certificate stuff?
SPEAKER: Revocation
SPEAKER: Revocation, yes. Nick: Todd, just getting back to your question again. If you stop paying for a number resource, then you lose you lose the entitlement that the rest of the community gives you to use that space so you can no longer be guaranteed that you have unique access to that space. Well there is no guarantee there, you no longer have the implicit shall we say consent of the community to say that you have a unique right to use that space. As I said RIPE are not police, that is the bottom line. They are a registry and they operate on a trust model and they operate you know on a model that you know, they can't chase up specific abuse of resource in great detail. We don't give give them enough money to do that
Q. I am not exactly sure who was next, Leo or Daniel. Leo: IANA. I am in support of this proposal, I spoke in support of it at the last meeting. I am a little bit worried that we might be in search of the perfect and missing the good enough, and once begun is half done, and I can't remember how many tens of thousands of organisations you mentioned that there is a need to contact, but yesterday afternoon there was quite a lot of talk about how if we don't do something, we might be regulated, we will probably be regulatelated anyway but there is light touch regulation and not so light touch regulation and if we don't make a start on this, we probably are not going to take the light touch regulation and we are going to get the heavier regulation, and I am concerned that we are talking about revising this and coming back in with a different model, at some point in the future, but we are not actually going to get going on it yet and at some point maybe in six months' time or a year there will be an agreement and then the RIPE NCC will conclude its preparations to get going with this and it will be two years before we actually kick off with getting people signed up to whatever it is in whatever way it is, and two years is quite a long time.
Nick: You are absolutely right. You know, as I said, we are in terms of existing IP v4 allocations PI assignments we have been or at least RIPE NCC has been handing them out willy nilly for 12 years, you know, and we are reaping the rewards of that policy failure. RIPE has a policy creation procedure. I don't think it would be appropriate to bypass it, but I would like to think that we could that if we could achieve consensus that this was actually a good policy to have, that we could implement it relatively quickly. The next opportunity to actually implement it is May 2005, because and the reason for this is that it has a budgetary impact and any budgetary matters must be dealt with at a RIPE general meeting. So yes, you are absolutely right, we do need to do something about it pretty dam quick.
Q. Yes, yes I would like too far sample policy that gives the RIPE NCC the authority to get going and then obviously, an initial policy is not going to be perfect T can be revised, there is a process to continually revise policy and if we decide after a year or 18 months it needs a bit of tender loving care, then we can give it some tender loving care.
Nick: OK, I see where you are coming from. It may be a good idea to reformulate 2007 01, throw it out on the address policy working group, see what happens for a couple of weeks. You know, if there are major objections received during that period, you know, and the RIPE community are unhappy about it, then I think we should certainly look at what you are suggesting at, but it may be that people just think that this is like a good idea and that yeah, we just need to goer it. Do you think that is reasonable compromise?
Q. Certainly I think it needs to be agreed by the community that it should be done. So I would concur that it must go to the community in whatever form. I just think that let's try and keep the policy as simple as possible so that we can get it approved as quickly as possible, and give the RIPE NCC a relatively freehand to act responsibleably, which I know they do and if we then need to refine the NCC had a can come back, say we have noticed this, it would be helpful if and improve it based on experience.
SPEAKER: Actually I think what we can do is if we as a roomful of working group agree that something like this is the way forward, we can of course not make this policy right now because that is not how the policy development process works, but I think we can sort of put an action item on the NCC to get prepared because something like this will come and then if, it comes, be there to implement it quickly. I would like to do that sort of with a show of hands at the end of the discussion phrase, which is in about 15 minutes,.
Daniel: I have to say this time with the RIPE NCC hat on. I think what Leo is proposing is quite sensible and I agree with /H*ERT that we are here to discuss this and I haven't heard anybody speak against the whole thing, so if you actually have reservations about this, now is the time to stand up at the microphone and say it because I am quite sure and I am looking at Axel here, if we they are a that this room wants this the RIPE NCC will take the necessary steps inside its budgetary process and inside its operational process to prepare for the time when this policy gets formally adopted and so to hit the ground running, and we are not formalists, we are pragmatists and I see Axel nodding, I don't see any board members I don't have board members in my field of vision, but I think that that is what is going to happen so I think we are good in that sense.
The next one is this question I wanted to speak to originally, is this RIPE NCC being police, and doing stuff about the routing. Obviously we can't do stuff about the routinging, that is for the ISPs to do but I just want to maybe speak to one concern that actually people who don't maintain their contact information but actually are using their PI space on the Internet with a couple might suddenly be might off, things like that. And that is certainly not going to happen. At the RIPE NCC, we have all the tools to actually know what happens in the routing area. We have the /RA*EUS and we have had it for years and obviously we are going to use it, so if we cannot reach the address space holders directly, we will probably work with the up streams to get a hold of a contact there and find out what is happening. It might be a good idea to include something in a policy that may be not forces but strongly suggests to LIRs and ISPs to cooperate with us when we come to them and say, hay, can you give us an address, OK can you give us a pointer to these guys you are routing. And that can just abvery simple paragraph that says, you know, LIRs are encouraged to work with the NCC if this situation arises. It would probably make our work easier. I am not sure whether actually something like this is in there. But if it's whether it's in there or not, we will look at the before we do anything, we will look at the routing and we will try to track down people based on that. And we actually have the tools, and I mean there is no budgetary for consequence for that we have those tools already.
Nick: If I can just make a comment on what Daniel said there. There may be an issue relating to data protection, because if contact details are stale, and it's going to be necessary for some new person to present their contact details to RIPE, then all we can do is ask for an encouragement from the local Internet registry to talk to their end user and get their end use tore authorise this transfer of data to RIPE or to provide RIPE with the details directly. The local Internet registry, there is no way of compelling the local Internet registry to actually pass this information without consent. Daniel: I was not suggesting if that is not possible, but as you say there is a way around that, it's basically tell the address space holders or the people that actually, you actually route to contact us or to actually go through you as the LIR to register this space and this contact information. And it's just sometimes from a practical point of view, it might be useful for the people in the NCC who actually have to do this to be able to point to a policy or to something writ then a says you know, you are encouraged to do that" because if you talk to these kinds of these parts of the companies, they are more likely to do nothing in doubt than to do anything so if there is some encouragement that is written in whatever status it has, it would be helpful to the people that actually have to do the work. But I agree with you, we cannot outright ask, you know, give us the data because sometimes it's prevented by law, sometimes it's prevented by contact. All that we would need is some cooperation in a pragmatic way.
Nick: OK, I think that is a very good suggestion.
Wolfred: Daniel has said most of the stuff I wanted to add or to suggest. Actually, I would like to see the community here provide the RIPE NCC with a clear mandate to in parallel with developing this policy proposal to also investigate which sticks either we do have already or which can easily be developed to motivate people to collaborate and I think the certificateication is one of those possible sticks, so if you don't collaborate you don't get your digital signature on your piece of resource and eventually this is going to have some impact in reality, or another thing which I could imagine is to expressly and openly authorise the RIPE NCC to actually perform modifications on PSP registered in the database to properly reflect whatever the situation is. Like, no contact for an IP address block, this IP address block is going to acquire new status, whatever it is in the end in detail, and like what was suggested already, you would probably want to also modify the routing registry to reflect that new situation. Right now, RIPE NCC does not have the mandate to change any of these other voluntary pieces of information in the database because it's not their registry data, it's voluntary data put in by the routing folks F we can come up with proposals or recommendation toss interlink these things we may easily end up with very good sticks to get the flock move into the right direction. That is one of those things. And the second thing was just referring to this notion of PI address space being for free, that is not that is not completely correct. Because right now, we do have a price tag attached to PI distribution and that is actually small additional piece of sort of responsibility on the local registry channeling this request to the RIPE NCC. It adds to their size category potentially, but it only does so during the first 12 months period and that was based originally on the idea that RIPE NCC should not charge for holding resources but the RIPE NCC should only charge for the amount of effort that is required to keep track. Now, over time, these keeping track of things has developed different aspects and different colours than it was many years ago, so in those good old days, we were just looking at the effort that had to be spent to just pull a new piece of address space from the stack, registered once in the database give it out to the holder and be done with it. These days we do see there is a recurring cost, not least by keeping the database updated and is a sort of things, so I think there has been a model to actually charge for it but it was too cheap but it was not completely for free. Daniel: You are right.
SPEAKER: I see three more persons coming up. Hans Peter is next and then I am closing the queue due to time constraints. I see four persons lining up then we close.
SPEAKER: Hans from advise more IT. I think this is a very good proposal, a step in the right direction for the future. Basically I think it's important to have a stronger tie or link between the address space and those who is holding it. So adding money to that link is going to maintain it over time, but we also need to add technical signatures or certificates or whatever, over time, if this is going to work. So I think in the large perspective, the first thing we need to do is to run this policy proposal through the policy proand get approved. Next step for NCC board to have money into this equation. And then the third step for this community at the end is to see how do we want to police this. I mean, this is not for the RIPE address policy working group but this is for every single one of you as an ISP. If you get the customer where the address space they are asking you to announce to the Internet isn't in the database you should start to say no. And then the next thing that could happen is that you start to look in the database or look at the publications from the RIPE NCC to build your filters. I mean this is this has happened in the past. People are filtering on non allocated address space and there are technical ways to do this like the black lists used for spam and other things like there could be a black hole for unpaid address space in 15 years' time so that all the packets who does didn't pay the bills would end up there. Then you would have the same mechanism as we do for DNS, we don't have that mechanism in place today but in the future Internet in 10, 15, 50 years, we may need something like that in order to maintain these resource for a long time. Nick: Just as a comment to that, the big Internet with a capital I is not the only Internet, there are a loft private inter nets and intra nets and situations where people need unique guarantee unique address space outside outside for what we use for browsing your favourite search engine.
SPEAKER: : Telecom. I like this policy proposal very much as well. And this is pretty much in line of what Wolfred saves what Hans Peter said and Daniel said, I would like to have a little bit more of a policing function in the policy, though, so you I guess I got you right when you said RIPE NCC can hardly police something because it just has not the money for it. What I would like to see when the NCC comes up with a say cost recovery model and whatever else, an alternative or like addition to the basic model, what it would cost to actually police the thing in the light of what Hans Peter suggested.
Richard cocks from the spam houses project and before I make my question I would like to say to Hans Peter that we would be delight today host that database for you if you want to go that way. Of course, it might increase the case we have for slash 24.
Now, since 2003 I have been investigating what we might best call inappropriate BGP announcements and two things are very clear: First of all, that if anybody is up to nepherious things whatever addresses you have got will be bogus, unreachable. You have got to be able to have a method to get progress when that happens. At the moment there doesn't seem to be one and even some existing space within RIPE we have seen as questionable but then only questionable if someone has got the right to question it. Which in general they don't.
The big problem is that RIPE assigned IPs can be used to originate a G GP announcement outside the RIPE region, most specifically North America. I spent quite a bit of yesterday investigatesing a slash 20 I which nounsed in north California but never announced from RIPE Hostmaster, in other words not allocated. The only way I sigh of getting any form of policings, and fortunately it won't cost us anything is to get 201 on board, contractual terms between them and people they connect to which say in simple terms only addresses assigned by an IR RIR and only they be by the people to whom they were assigned.
SPEAKER: That would certainly help a lot. Mr. Cox: Have we asked them. Are there any T 01 here? Nick: That is difficult problem. I am not going to go into the technical details but it involves maintaining access lists for starters and maintaining fresh information about what your customers are doing. For what it's worth, a lot of tier ones and twos filter customer announcements already, obviously some slip through the net but I would suspect that the whole issue of illegal well or illicit shall we say
SPEAKER: Inappropriate Nick: Inappropriate BGP announcements probably falls out the scope of 2007 01 or modification and I would say that fresher information within the database is going to help with the problem.
SPEAKER: I need to cut this short, one last comment please and then we wrap it up.
Denis: RIPE NCC database team. I would like to say from database point of view we fully support this proposal and all the arguments that have been said today. We have wanted for a long time to be able to clean up a lot of the contents of the database but we have no mandate to do it. You said the RIPE NCC is just a registrar, but we are legally the data controller of this register and as such, we have a legal obligation to ensure that the contact data in it is accurate and relevant to the purpose of the database and we know for a fact at the moment a lot of it isn't accurate. We also to our customer services department, we face an increasing number now of angry and sometimes abusive complainants when you say we are trying to contact somebody about some abuse but the contacts are all wrong, what are you going to do about it? And we keep telling them we don't have a mandate to it it, we tell them what our community about it and ask them to come and speak to you but nobody ever does. So we do need we would love to have this main date to be able to do it, from a timely point of view if you give us a mandate we will start working on it tomorrow. So we just like to say we are fully behind the proposal and from technical point of view we have been thinking about this for a long time. Nick: OK thanks very much. That gets back of course to what Wolfred was saying earlier. And might I say that Phyllis has been extremely help envelope this regard in terms of making suggestions to the policy about what we can do, how it would tie into other areas of the RIPE NCC and I will be working with her and through her with all of the other areas that needs to be dealt with. So thank you very much.
SPEAKER: OK. To wrap this up, I have heard only supporting voices with some detailed improvement wishes. I have heard the wish to go forward quickly, so I would like to, well sort of to a show of hands, if there is somebody in here who is absolutely opposing this, please raise your hand. I am not asking for people who are asleep or reading e mail. We are not going to do any decision on this today, of course, but based on your input we can give a main date to the RIPE NCC (mandate) to get prepared for this to happen. Axel are you listening? I see him nodding. And I see an action item on Nick to bring this forward to the mailing list, the current proposal wrapped into some text, together with Phyllis and get it through the policy process quickly. Thank you very much for your work on this.
(Applause)
And now we have one sort of radical presentation from Leo on why all the IPv6 policy is such a mess and what we can do to improve it.
Leo: Hello, Leo, and I am here speaking in a personal capacity. This presentation is not made on behalf of my employer; it's made on behalf of me.
So, making the IPv6 policy simpler and more fair, that is my goal. This is an idea that I am presenting, I am looking at the high level idea rather than the details that have been presented with it. The details aren't so important; the concept is the thing that I am trying to get an idea of consensus on. If there is a general feeling that this is worthwhile, then I would like to make it a more formal proposal, take it through the process but I thought it was a good idea to sort of run something up the flag poll and see if people like it before going through the whole process of getting a number assigned and everything.
So, what is the situation? Assumptions, some flow charts that I did myself, my proposal and then an opportunity to tell me whether this is worth taking any further.
So, the situation as Phyllis explained earlier on today, RIPE doesn't have a PI assignment policy at the moment. I think it was 2006 01 proposes one, but it didn't define criteria for quantity and required multihoming. There is nothing wrong with having multihoming as a criterion, but there are obviously some organisations that feel the need to renumber when they move from their single home connection to their single home connection is incredibly expensive, especially as IPv6 is a big number space, it allows them to deploy very large networks and renumbering isn't actually significantly easier with IPv6.
So, in trying to think this through and seeing if there could be any improvements, I thought, well, what is the policy like for IPv4, and the policy with IPv4 is in this region, at least, a network qualifies for the same amount of PI space as PA space. If you have a network that only has 12 hosts on it, you are going to get a slash 28, whether it's PA or PI. And there is no real minimum other than I don't think the RIPE NCC have ever been requested to assign anything longer than a slash 29, and I know there is a maximum assignment size either, so (no) so if you absolutely desparately need a slash 6 if you justify the RIPE NCC will make shoe that off slash 6 of PI address space in IPv4.
I don't think a slash 6 has been assigned recently, but it's theoretically possible.
And does it work? Well, I was quite impressed with something that I heard Geoff say. I think it was in New Delhi a few weeks ago and he said the allocation policies we have had for v4 were spot on. They fuelled a revolution in networking and v6 has the same capability, the address space is massive and we can make that policy work as long as we have abundance" and we do have abundance but we only have it if we don't waste it. Because you can fill up any amount of address space with rubbish if you want and if you take a very large address space and you go and cut it up into pretty large pieces you are still going to use it all up and the larger the pieces the more quickly you will use it.
So there is a responsibility to use the address space fairly sensibly to be responsible stewards and to not to not just waste it.
And so the intention here is to simplify the policy to make it more fair and I am looking for an equality of opportunity. I am not looking for an equality of outcome. The idea is that everyone who needs address space will get the address space, but they are not all going to get exactly the same amount of address space because if they get the same amount we will end up with some people who need truly huge amounts and some people who don't need very much address space and if they all get the same space they need the truly huge amount and our abundance has been wasted.
So, the assumption I went into this with are IPv6 doesn't really change multihoming. That is a problem that is still being worked on. The scaleable routing issue is not one that I am clever enough to fix. Obviously, there is work going on in that area by people who are more smart than me and hopefully something will happen that is, you know, we are going to get a solution to that but in the interim, we have still got people who do need some independent address space because renumbering isn't easy, and most network these days aren't ISP networks, so what do we have now (I). It's very simple: Do I qualify for a PI assignment? No, I don't because there is no policy to allow me to get an assignment. So I think this is what you would have got with 2006 01. Do we qualify for a PI assignment? Well, of we are multihomed, then we do; if we aren't, we don't qualify. And that is good. I mean, it's a good starting place but not everyone is multihomed, not everyone needs to be multihomed and there are some organisations that have is a mandate to change a lowest cost provider and change it every year. It isn't fair to go and say we are going to require to you renumber your network once every 12 months. Or potentially once every 12 months. It could be that the lowest cost provider remains the lowest cost provider but there is competition in the marketplace these things change.
So also, I might need more than a slash 48, so do we qualify for a larger assignment, a shorter prefix? Well, no. And are we multihomed? If we are not, we can't get PI anyway. And if we are multihomed, do we qualify and is our need documented and justified? I think that was the phrase I took from the policy proposal. And documented and justified is great in saying that you have got to meet these cry tier why and those should be documented and justified. But just saying documented and justified, well documented and justified what? Effectively, just requiring that gives the policy making power to the RIPE NCC and really, I think the RIPE NCC is perhaps looking to implement a policy rather than make the policy. So I am hoping that I can make a proposal here that will give the RIPE NCC the guidelines that or the policy that they can actually implement in a fair way when the criteria I am suggesting are documented and justified.
And here, I have got a nice shot from a Dr. Who episode. Everyone probably remembers the Castra Valva episode where Dr. Who was trapped in a recur sieve space and this is something that Phyllis mentioned earlier on today; there was the proposal that end sites should qualify for a slash 32 allocation or assignment when they themselves have end sites, which is a little bit recur sieve and I think while the RIPE NCC have probably capable of seeing through what the intention of the policy was, the text that was proposed actually didn't quite pass to me. I kept on I was trapped in an infinite loop and had to hit myself around the side of the head, so I think policy requirements that are recur sieve are bad and should be avoided.
So, when you are trying to think up what the policy should be, these are the sorts of things that we have. Should I request the PI or the PA and what does my network need and what are my traffic engineering needs? I only really want to say in the request once, I only want one prefix, ideally, because that would be a public benefit, it would keep the routing table that most people see as small as possible. I am interested in the cost to me, both in 9 cost of managing my network, multiple prefixes could be more expensive there and also in the cost that I will have if everyone goes for multiple prefixes and there is a documentation hurdle on policy requirements. If the policy is not really simple and clear, we are going to have a problem. People will go and look at the poll see, won't understand it and they will be either be irritated and go and say those RIPE people are really bad or they will give it a go and maybe they won't understand it and they will go and put in a request that doesn't actually meet the requirements and then they will go through a long and arduous process in getting their address space, which I think everyone would prefer doesn't map happen
So I am thinking about this a little bit more and what is the difference between an ISP and enterprise network? I think that nowadays, the difference is very vague. It's permeable. ISPs have customers that pay them. Large enterprises have business units that actually transfer money between budgets with other business units. There may be contracts that are legally enforceable, there may not be, but effectively you are providing Internet services as the service provider unit to the service consumer units within the company. And what is the difference between PI and PA? Well, PI address space is independent of an unstream and PA address space means you are trapped with the upstream. And the difference so far in getting your own block, basically your PI block as an ISP are, your provider aggregator will block your issue to your customers has been magic numbers, this 200 slash 48 and I think people generally agree that it's a vaguely random number that is thank has been picked. It's not picked because there is a genuine reason that if you have got less than 200, if you have got got 1999 you are too small; it's (199) just you have got to pick a number. So it's been hard and this actually makes it very difficult to get a fair policy for PI because you are trying to think, well, if we have got a minimum allocation size of slash 32 and that is a really large block and we don't want really teeny tiny little networks to get a slash 32 because that would just be a waste, then how are we going to get a policy for PI? And what is the minimum and 200 seems to have been the number that was hit on, so that was the one.
So, I am proposing that we remove the distinction between PA allocations and PI assignments. Removing the slash 32 minimum allocation. Base all delegations on a networks planned need measured with whatever the amicable H D ratio is and make all delegations using a sparse allocation so that when people need to come back for more address space there is really good chance they are going to actually get a contiguous block and they can just extend their network prefix.
So there won't be magic numbers. Needs based allocation is fair. That is what was proposed by the ITF with T L A and N L A and with the slash 128, 64, 128, that is needs based allocation.
This is just measuring the needs a little bit more closely.
No need for complicated split fee structure like we are talking about now like PI space and IPv4. No incentive to disguise allocation as large PI assignment, I know that gets people requesting slash is an of PI for their cable network because they don't want to become RIPE NCC members to pay a fee. Limit prefixes allocated to no more than than the number of contracts with the RIPE NCC. I am assuming we are going to go with contracts. You you are not going to have more prefixes if you go this way than the number of contracts.
Disadvantages: Prefix length filtering becomes difficult. You probably need an SC L per RIR issued prefix, routing registry, probably really going to really need to use a routing registry or some other routing registry plus. And routing scaleability, well it's reaching its limits and this would be a challenge but it would also be fair to people who want to get into the market. It's not easy. This is a big change in concept, it's removing the difference between the services provider and the enterprise. It's people who don't sell connections commercially getting the same rule as people who do sell connection commercially.
So, it's a big bad, mad idea. Am I the bad idea fairy? I don't know. I would be interested in hearing what people say, either at the microphone or at lunch and in the halls or even on the mailing list if people are willing to have their writing quoted on the mail archive.
George: Thanks for for this. Just let me point out one minor detail. We got rid of the 200. That is there is no magic number in the policy any more. We are running into the lunch break. Well I am sort of sorry for that but this is important stuff so I think I take the liberty of holding you up five minutes more.
SPEAKER: George Michael son, I am also speaking for myself, I play no vanishingly zero role in policy and this is my personal observation and not an APNIC observation. My observation is people don't come back for more v6, while I applaud you doing things for second come back they don't come back. That is one observation.
And the second observation I would like to make is I am personally unconvinced about aspects of how we apply when you come back you automatically get double. I think the behaviours that you do lowering exponential curve of how big a space is different than you do it high. We are giving out large amounts of address each time we give anyone a block
A. Yes. Well, you won't come back if you get a slash 32 and you need a slash 47.
Q. What you are doing is good it mitigates against bad effects. It's still likely people won't come back?
A. Maybe.
SPEAKER: Geoff Houston. I am not sure if I am making for APNIC or not, probably not. The thing here is that trying to overload the agenda for the address distribution function and somehow magically save the routing system for from its own worst you know fate, over loads the entire problem to the extent that I think we don't understand what we are doing. This whole PI/PA thing has got us all very, very confused and quite frankly an address is an address. The routing system, everyone, an address is an address, so removing that distinction gets you along way down the track. And then trying to understand beyond that what is the real issue with v6; is this a scarcity, rationing thing? Is this an abundance thing? What are you actually trying to achieve here in terms of industry outcomes? Are you trying to make it easy for folk to get addresses and never come back; do you want them to come back every six just so you are shaking hands? What do you want? Because by phrasing these policies you can phrase any outcome you want as Leo has shown, but the real and very basic question is, what does the industry actually need from us to make this rather painful you know, get to a place that is better? They have given us a huge amount of address space. If we replicate the v4 policies that ultimately became policies about scarcity and rationing, I am not sure anyone will thank us. So, perhaps we do need to think again about what we are trying to save and for whom and why, and I would certainly recommend that we think firstly very strongly that there is no distinction between PI and PA, they are just addresses and then think maybe Connelling back every year for fillup of addresses is kind of daft, maybe we should be doing a little bit better planning all through this industry and try and figure out what we want from a registry as distinct from what we want from an allocation agent because I think they are sootly different roles. Thank you.
SPEAKER: Well, just commenting on the there is no difference, it's just addresses. I think, traditionally, one of the big distinctions inherent is that you get a PI block on a sort of well defined need for a well defined network, sort of. It's not always very easy to do. Why you have a PA block is sort of based on the assumption that you will have some number of customers that you have no easy way to plan beforehand and specifically in IPv6 the distinction gets a bit more important because as the networks grow larger, the provider networks, the need for internal aggregation, internal structure, is very important and having a prefix that sort of gross over time with coming back sever six months to get another bit, will directly (grows ((bring your problems in in turn aggregation. I agree that for a big enterprise that has business units all over the place and is buying and selling daughter companies every week, there is no distinction to a provider. So, as soon as we have a decent PA policy, I don't see a big problem for this sort of resource users. Call it whatever you want.
SPEAKER: []... from Deutsch Telekom. Well I can see the an appeal of doing away with sophisticated rules to deal with scarcity of addresses which isn't there in IPv6. As long as we are talking about the routing problem like, well OK there are very some very clever people working on it and they should have been working on it for a couple of decades and didn't really, doing away with the distinction between PA and PI and the economics in routing space that have that we got for out of CIDR well OK, looks to me frightening as long as we don't really have a hand on the routing thing. OK, the address space, the scarcity of the address space is no problem any more in v6, but the routing table size is, and unfortunately, the only thing that is around, as far as I can tell in the address registration area for keeping some hand on the number of possible distinct routes, is actually the PI/PA distinction. And I feel very uncomfortable about giving that away and not even having a language mechanism of telling people, well, OK, you should be going PA because we cannot tell them it's PA we want them to use.
SPEAKER: OK. Thank you for all the inputs. I think I take one last comment and then we really should leave here.
SPEAKER: Cathy earn son. I want to say there is one really big distinction between PA and PI, from a customer's point of view sure they can't usually change providers if they have PA space but when the routing table goes to hell and people start filtering the longer pre if I cans they will still be able to be reachable because they will be in their provider's aggregate and I think that gets lost in here a lot, well it's true Geoff.
SPEAKER: Well something that needs to be pointed out when discussing this distinction is at the level that you get address space from your regional registry, there is no difference. If you are a big enterprise you get and the slash 32 from RIPE, you can take that to whatever provider you want. If you are an end user and get address space from your local registry, also earmarked PA of course there is a big difference to PI space. So yes this is a common issue of misunderstanding whether there is a difference or not, it really depends on what what level you look at allocation.
Speaker: So you were saying the thing we have to market is, well, OK, guys, you can get PI and you will only be routed if you actually agree to renumber in case you want to connect to a service provider.
SPEAKER: I am not saying anything. And I just cut this interesting discussion. I would have to things to say about renumbering and enterprises and cheapest provider on the market and so on. Thank you all for attending. Thanks for participating so lively in the discussion. And enjoy your lunch.
THE CONFERENCE THEN ADJOURNED FOR LUNCH.
|
|
|
 |
| RELATED TOPICS |
| RESOURCE LINKS |
|
|
|
|
| |
|
you
are here: RIPE -> RIPE
Meetings -> RIPE 55 
