Address Policy Working Group
10 May 2017
11 a.m.
GERT DÖRING: Welcome back everybody, well not everybody, but everybody interested in policy making. Thanks for being here. And where is Elvis? Without further ado, I'm handing the stage to Elvis and let's go on with the discussion on that.
Now we have plenty of time.
ELVIS VELEA: So, we were having a discussion with Erik. I don't know ‑‑ do you still want to chat about it? Let's start with that.
ERIK BAIS: So, one of the things that you wanted to do in the, that we discussed before the break, was the old historic data and that it was not matching the registry in the database. I did actually have a chat with Maurice on that, the seller cannot verify that with the registry, which is an issue.
ELVIS VELEA: The buyer.
ERIK BAIS: The buyer, the seller won't do it because he knows the problem. However, the buyer can actually see with the versioning, you know, what the changes were in the actual database.
ELVIS VELEA: But that doesn't mean anything.
ERIK BAIS: It means as such that if things were changed ‑‑ you can see the versions and what has been changed, because it's a full, you know, change in historic changes and see when it was changed, it does give indications on why.
The stuff with getting this optional in the, so that the contractual changes were actually an optional thing in the services agreement for all transfers does not fix the thing in the end, because if you want to do this you need to do it for everything, and ‑‑
ELVIS VELEA: Can I answer that just so that we answer like every comment or question so that...
The way I'm seeing this being done is that from the moment this gets approved, every time a legacy object is updated, the NCC would add a remark or some sort of a line saying this was updated but not yet verified by the NCC. And then it it will require both the buyer and the seller to sign a sort of a transfer template which then gets verified and when that is verified, the actual legacy resource object will be updated, the remarks will be removed or whatever, and therefore you would know that the holder of the legacy block has been approved by the RIPE NCC. So it was an approved or finalised transfer. So that's the way I was seeing this being done.
Any changes to the object would trigger an automatic update from the RIPE database saying this was changed but we have not yet been notified about this change. So we have not yet verified T we have not yet approved it. This way, whenever someone hijacks a block, they cannot go and sell ‑‑ or they could go and sell it to someone else but that someone else would then knowingly buy something that was not verified by the NCC.
ERIK BAIS: Okay. So basically what you are asking is for uncontracted space which is not inside from the NCC, to have the NCC approve the changes and I think that would actually put the NCC in a liability issue. I think this is going to be a major cluster fall.
ELVIS VELEA: Let's see the analysis.
GERT DÖRING: I think we can have a quick feedback from us right away. As far as I understand, and I'm playing the ball to you, the NCC is currently neither mandated to nor do you do that to validate resource holder ship for legacy resource holders. I have no idea. I don't have legacy resources, so I have no personal experience with it ‑‑
Speaker: Ingrid, RIPE NCC.
When we get a request to help out with a change on legacy objects, for example in the resource holder does not have access to the object at that moment, we do a verification and we make sure we help the legitimate resource holder. If the current is listed in the RIPE database is not verified has access to the object, maybe because back in the days somebody was given access to the object to actually make network changes or, you know, to maintain the object not necessarily being the resource holder, we don't know.
ELVIS VELEA: Or maybe an ex employee or whatever.
AUDIENCE SPEAKER: Ingrid: Whatever, but if our help is not needed up to date a database object of legacy space, then we don't know about it. The object will have a chase date in the RIPE database, how often it has been changed, for every change a date is added. So that will be there, but we don't ‑‑ the only ‑‑
ELVIS VELEA: The last modified you mean. And then the version as well, the history.
AUDIENCE SPEAKER: Yes, but if our help is not needed to update the object and the object is not added to the registry, then we are not a party in that he is changes.
ELVIS VELEA: And I actually have a question for you ingrid. If a legacy resource holder has a contractual relationship with the RIPE NCC be it directly an LIR or they have a sponsoring LIR relationship, will the change of the legacy object require a RIPE NCC verification of that change?
Ingrid: The moment it has been brought into the registry we have already done our verification of that resource holder, we do want to know about further changes, that's why we are also being updated when there is further changes because we need to maintain the accurate information. We have something registered for something that we have an agreement with. So if something changes, we need to be informed. Everything that's not brought into the registry, it's a different matter.
ELVIS VELEA: Okay.
SANDER STEFFANN: One question Ingrid. So, you say you do in some cases when somebody doesn't have access to the objects any more, you do verification and try to restore access for them etc. Does NCC actually then at that point take responsibility for those verifications in how does that legally work? Like, is actually the NCC certifying that the data is now correct or do you make somebody sign an agreement saying like, we'll give you access but it's all on you? How does this work?
Ingrid: We ask the person or the party coming to us to show to us that they are the legitimate party and we will verify it as much as we can. We ask them to sign a few confirmations, but also, as also written in the policy document, if we're not comfortable, then we don't. It's up to the requesting party to convince us of the legitimacy.
SANDER STEFFANN: So for a buyer knowing that the NCC actually looked at it does provide some level of confirmation, I won't say guarantee, but that it actually has been properly researched.
AUDIENCE SPEAKER: (Ingrid): Chances are much much higher. But it depends on the situation what update they requested how much access we had to give them, so... but...
ELVIS VELEA: And I think we actually started with a question whether this would be a legal issue if the policy update ‑‑ if this policy change would be approved, whether the NCC will be allowed or will it be a legal issue for ‑‑ if they update the legacy object with a remark saying this object has been updated without our ‑‑ without us doing any due diligence, without the NCC doing any due diligence of the update. Without the NCC approving, but take the approval word as a very strong word actually, and it's not meant to be like that, without the approval of the NCC. So... maybe Andrea has a word about that, or not.
ANDREA CIMA: I think this is something that should be checked in the Impact Analysis by our legal team. I'm not a lawyer. I think I would be the wrong person to answer.
ELVIS VELEA: Perfect.
AUDIENCE SPEAKER: Agnes bag err, I ACC, legacy holder having gone through the process for about 16 resources each taking a number of months to get registered properly. One correction first on your presentation, you had said that there are two different aspects. One is those who have gone through the process in our registered as legacy holders and they are outside. You said if they are inside the system and they decide that they want to do a transfer, that will give the RIPE NCC the ability and the timing to add‑on their own maintainer on the object.
ELVIS VELEA: No, the maintainer is already added when ‑‑
AUDIENCE SPEAKER: You had said differently.
ELVIS VELEA: Maybe...
AUDIENCE SPEAKER: The RIPE maintainer, the RIPE legacy maintainer is already there the
ELVIS VELEA: Exactly.
AUDIENCE SPEAKER: I don't see any value in doing this for in any kind of aspect, in other words there is ‑‑ it's just each of the legacy holders have gone through many hoops to get registered, they don't want to go through more. They don't see any benefit for statistical purposes. If you need statistical purposes you can do a diff as I spoke to you get and see exactly what changes have taken place and know exactly who has changed a legacy space if it's outside the database, I don't see any particular benefit to doing this, either for the legacy holders or for the buyer other of seller. The legacy holder either decided to go into the system or stay out of the system. For statistical purposes I see no benefit here.
ELVIS VELEA: We had this chat off line yesterday and let's agree to disagree. I think there is a value on it my opinion is there is a high value on it, especially guaranteeing to the buyer that this block has actually been transferred to them by the legitimate holder and not any other third party that may have had, may have gotten their hands on the object or ‑‑ right.
AUDIENCE SPEAKER: I have no problem with the RIPE NCC adding any kind of flag. Anything that doesn't involve the seller having to do something that needs to be verified, needs documentation, needs lawyers, needs corporate stamps, if the RIPE NCC wants to add something because they see something going on, fine, there is no problem with that. I want to minimise the amount of work that the legacy owner has to do here.
ELVIS VELEA: I understand. But the only work that the legacy holder has to do is to sign a template document.
AUDIENCE SPEAKER: Obviously you have never done this. I have eight universities, each one of them, to get all the proper documentation, that would pass the muster of the RIPE NCC, took months.
ELVIS VELEA: I have done hundreds of transfers over the past few years and I have had ‑‑ I'm an IPv4 broker so I'm part. Process for hundreds of transfers. I have had ‑‑ but, it's only happened once until now ‑‑ I have had that the power of attorney from the buyer took six months to get. So, the actual power of attorney for an employee of that buyer to be able to sign a transfer document took six months.
You're right, it could be complicated especially the legacy holders are very old corporations, large huge gigantic corporations or universities or whatever. It may be complicated, but it's still ‑‑
AUDIENCE SPEAKER: Complicated for statistical purposes. Tell me what the value is there
GERT DÖRING: I'm intervening here. Elvis please do a bit more of listening and please less talking, because we want the feedback from the room. Don't go into arguments. Listen to the legacy holders because they are the ones affected by this. I think it's very good that Hank actually spoke up for Legacy holder and not everybody else who doesn't have legacy space but thinks how we know how legacy space should be handled. This is not in our system. This is not our mandate so if they say this is a good thing. We can do this for them. If they say it's a bad thing or it's, they don't want this, it's their space. Their decision. So this is different from normal RIPE space. Please let's not forget that.
I think Hans is next and then Andrea.
AUDIENCE SPEAKER: Carlos re as I say from the Portuguesen Ron, I am also a legacy resource holder and I work for universities who are also legacy resource holders. Some small comments.
The time to sign for universities, well I have started this process with Portuguese universities somewhat two years ago, some universities didn't sign the paper yet. So, six months, two years... well, I'm not sure if everyone will sign or not.
I have another disclaimer also. I am not really interested in buying or selling, so I'm just trying to protect my constituency, which is the universities and so some of my universities wishes to sell their asset, they will have to find a different sponsoring LIR. So, be it that they already sign the papers or they are still waiting to do so.
So, the other last comment about your proposal is that I can be convinced if the optional ‑‑ well, I'm not opposing if legacy resource holders wish to sign something, so I shouldn't oppose if they see any benefit. What I really don't like is the chance that it will be mandatory, so there was this comment from David farmer, so, I'm more against that position than against the full of your proposal.
ELVIS VELEA: My policy proposal will keep this as voluntary and if at any point this is wanted to be mandatory, it's not going to be in this policy proposal, I can guarantee you that. And if the words need to be changed to make this very clear that this is going to be optional or voluntary, then well we'll do a second version.
AUDIENCE SPEAKER: Hello, Andrea Cima RIPE NCC. I have a question for you. You were discussing some points with Erik just a couple of minutes ago in this room, and you mentioned that the idea would be to have an automated remark added to the object that it has been changed, not been verified by or run by the RIPE NCC. And that then afterwards the parties could sign an agreement and inform the RIPE NCC about this.
My question is, that if the object is updated, I suppose that the transfer has been completed. You are the expert.
ELVIS VELEA: Yes, probably.
ANDREA CIMA: So this means that the moment the RIPE NCC receives some documentation, the fact has already happened. But the RIPE NCC still has to do some due diligence checks to make sure that the offering party actually has the right to do what they did and they are the actual legitimate holder. What would, according to your policy proposal happen, if the RIPE NCC was not able to establish that the offering party is actually the legitimate holder, that they would not have enough proof that. Would you expect us to close our eyes and just say okay, we'll keep the object in the database as it is and cannot accept the paper, or would you want us to treat it as a hijack because the space may be actually inappropriately be taken over by somebody else. In some other meaning, where would you expect this to go?
ELVIS VELEA: Good question. So, it's complicated because... from my point of view, if an object had been updated without going into the depth of the way you thought of this question, if an object would have been updated, then the remark would have been added and the NCC would remove that remark only when they have verified that there is a new holder. So, as long as the object is showing the remark line saying not verified by the RIPE NCC, it would mean that this has been updated and not all the documentation has been provided.
Now, the RIPE NCC may verify the document and require another document and another document and another document, this may take days, weeks, months, years. I don't think you guys should consider it a hijack per se. When people are coming with documentation, trying to provide the right documents for a transfer of a block. On the other hand, I'm not sure ‑‑ after listening to you, I'm not sure that you shouldn't consider it a hijack any more.
ANDREA CIMA: Just something to think about. Would you want to revert the object, would you want to us take any action? What would be expected from the RIPE NCC? It's just for you some food for thought.
ELVIS VELEA: Right. Thank you.
GEOFF HUSTON: I work with APNIC and part of my job description is to try and analyse the network and its behaviour with addresses and effectively report back to policy communities, particularly APNIC, but others, about what happened to help them make better policy. It's part of that feedback loop what the hell happened and area we doing the right thing is what we intended actually happening? The observation, and it sort of touches on Hank's comments, is that we have a set of transfers that are listed, but when we look deep in the routing system we see a much bicker set of changes, possibly around nine times as many, but we have no understanding of why the gap or what's going on. Now, what we do understand dimly, is that some of those changes in the database in RIPE are real transfers, and some of them are just other forms of changes. And from my perspective, I have certainly said a number of times and I'll say so here, it would be helpful for us to understand the movement of addresses to inform the policy process if addresses are even in that legacy area were indeed transfers. Now, it's conflated into a thing about your legacy holders and that's certainly none of my business and I have no comment, but it would be helpful, instead of just using the statistics of change as Hank is sort of pointing I could do, to eliminate some of the guesswork and sort of well this changed, is it a transfer or is it something else, if there was some explicit guidance for some these movements to say yeah it was a transfer, we both agree.
Now, the address brokers could do this for me too but they choose not to. There are other ways of getting this data but at the moment none of those Windows are open to us to understand this. So, we turn back to the registries as the only thing we have in common going, can we please mark it. So, from my point, I'm not there in legacy holders or any other part of that discussion, but I'm saying to the room in general, if you can allow more light into this space, you will know more and hopefully that will help when you keep on revisiting this.to I can, as v4 address space gets scarce errand scarce err that your policy it better informed about its results. Thank you.
AUDIENCE SPEAKER: Randy Bush IIJ. First, I want to say I'm really cheered that the Cooperation Working Group requires a bigger room than Address Policy. That says something about this culture. Oh it's connect. Oh bum err!
But, you know, area we here? It's accurate records.
TORE ANDERSON: Andrea and Ingrid, etc., will this improve our records at a reasonable letter of effort for all parties, but more interestingly, is there some gap somewhere ‑‑ are there gaps where... Where are our records and why are our records... have less accuracy than they might, and are there things we could do about them. And this is an echo of Geoff's question, or statement.
You know, is this helping? Will this help significantly?
AUDIENCE SPEAKER: Ingrid: I think one of the issues here when it comes to accuracy of statistics is the optional part. At the moment it's not mandatory to report every change to an object of all legacy objects to the RIPE NCC. The only thing we could publish itst actually when people do everything, which is not reported to us, we will not publish because the situation has not changed. That will not improve.
RANDY BUSH: I'm less interested in the accuracy of the statistics than I am in the accuracy of records.
Ingrid: Again, when we receive update requests for legacy, transfers do not formally exist, we do our due diligence, we ask also for some disclaimers to be signed, and after verification, there could be a higher certainty of the accuracy.
RANDY BUSH: By the way I should say I am a Legacy holder, I do not buy and sell address space and I am willing to do a little bit more work to improve what our principal goal is.
Ingrid: At this moment it's very difficult to say how accurate the current records are because they have been not been verified. They could be, they could not be. We have no idea.
ELVIS VELEA: Randy, by doing this optional, only the ones that actually take the option, will improve the registry. The rest of the records may remain less accurate.
RANDY BUSH: Thank you Ingrid.
AUDIENCE SPEAKER: Wilfried Woeber. In the past I am very much in line with Carlos, and I am very grateful to Geoff for sort of bringing up the aspect of having a look at the reality. I don't have an answer to Andrea's question but I do have an observation, and that would be that irrespective of optional or compulsory or whatever proceeds so label a piece of resource from pink‑ish to bright blue or the other way around, it doesn't make, in reality it doesn't make really a difference. If ‑‑ and that's Andrea's ‑‑ targeted at Andrea. If the RIPE NCC gets any indication by whatever path and whatever background, that something fishy is going on, I would hope that the RIPE NCC actually starts investigation.
Whether this is the full blown investigation for a suspected hijack or whether it is a sort of a more lightweight investigation by trying to correlate the data in the registry with the routing reality and that sort of thing, I think that could and should get the support from the community as a mandate to the RIPE NCC to do that on a general basis. I'm really not seeing any substantial difference in parts of PA blocks which are authoritatively administered by the RIPE NCC starting to behave an interesting thing, and then you start investigation, I don't think there is any good reason why we would want to do differently with legacy holders, whether they have been labelled pink, bright blue or green. That's just my reading, also from still wearing some sort of pointy hat from the security environment, so if something fishy is going on and you see an address block registered in Germany and it's advertised somewhere close to the Russian boarder, not picking on Russia or any country in that region, but we for effect we know that the probability is higher in some geographic areas that things happening which don't usually happen in other parts.
ANDREA CIMA: I just wanted to answer this point. That we do not proactively check whether something is happening to legacy resources which are not on the contractual relationship, simply because there is no framework for doing so. We do however, we do however investigate and we closely work with legacy holders even for resources that are not under contractual relationship in specific cases. And in such a case if somebody comes to us and says I am the holder of this resource and there are claims and documents provided to us and there we see that there is something wrong and we see that this paper is provided to us are somehow fraudulent, then we will try to get in contact with the real holder of the resource or will try to investigate the situation, try to make sure to protect the resources and the legitimate holder. So, we do this on a case by case. If we are approached, but as Ingrid said, for most of the legacy resources, we are not approached, things happen between the themselves and that's how the framework is at the moment and what the policy mandate gives.
GERT DÖRING: One request from my side. Andrea and Ingrid, I have no idea about the scope of like how much, how many percent of the legacy holders have entered a contractual relationship and how many haven't. Which might or might not influence this discussion. So could I ask you to just send the numbers to the mailing list, not right now, no precise numbers, just give an indication to the mailing list on sort of how far progressed the project is.
ANDREA CIMA: I have a number right now. It's not maybe exact. We can send the exact number. Xavier is the expert and can tell me if I'm wrong. But I think it's 42% of the legacy address space in the RIPE region has been brought under contract by legacy holder and that was after the legacy policy was set in place so I think ‑‑ it has, the policy has been quite successful in the region.
GERT DÖRING: I'm not sure exactly what conclusion to draw out of that. But more data is good.
SANDER STEFFANN: Sorry Erik I'm jumping the queue here. Now we're talking about the contractual relationship, I'm thinking about this. We already have the option for a Legacy holder to enter into a contractual relationship with the NCC. They do all the verification steps etc. What is the difference between a Legacy holder choosing to enter into that contractual relationship and the optional verification that you are offering? What's the difference?
ELVIS VELEA: I'm not sure I understand ‑‑ what optional verification?
SANDER STEFFANN: Currently in the legacy policy, there is the option for a Legacy holder to enter into a contractual relationship with the RIPE NCC.
ELVIS VELEA: Okay.
SANDER STEFFANN: When they do that all the verification is done.
ELVIS VELEA: Right.
SANDER STEFFANN: So what would be the benefit of what you are suggesting compared to what we already have there?
ELVIS VELEA: All right. So, when a Legacy holder is in some sort of contractual relationship, either directly with the RIPE NCC or through a sponsoring LIR, then they can still update the object, it's just that the NCC will be notified and they will verify it by default. They would just not publish it as a transfer. When the there is a contractual relationship the RIPE NCC will not be notified of a change in the holder of the legacy resource, so therefore, they will not verify any updates of the RIPE database. So, when there is a contractual relationship, if a change happens in the RIPE database either before the RIPE NCC is notified or after, this will automatically update the registry as well. So the RIPE database and the registry will be in sync. If it happens for a registry that the not and the RIPE NCC does not get notified and does not verify the update, then the registry and the database become ‑‑ they are no longer in sync.
SANDER STEFFANN: So, your proposal offers and optional verification step?
ELVIS VELEA: Yes.
SANDER STEFFANN: Which would be useful for people who are not yet in a contractual relationship, you say.
ELVIS VELEA: As well. Yeah.
SANDER STEFFANN: So, if they enter into this contractual relationship, the NCC does the verification, so, it seems we already have an optional way of verifying this without changing anything. I think to me it feels like we already have this option and this will just be a different wording and a different version of almost the same as we already have.
ELVIS VELEA: If gives you the option to not get into a contractual relationship but still update an object and still have it verified by the NCC but still not be in a contractual relationship. So it's not the same thing.
AUDIENCE SPEAKER: Erik Bais) so if you do a transfer for legacy space, you have the option to inform the NCC to update the registry without going into a legacy contract as a Legacy holder. It is actually one of the questions you get from a procedural point from Xavier, do you want for the new holder to enter into a contract yes or no, leave it like that, import in your LIR and do you have a sponsoring LIR?
So, that option is already in place for anybody that wants to inform the RIPE NCC of any transfers already being done. That is an optional thing and it's only mandatory to do that if you want to break up the parent object if you have a /16 and want to break it up into multiple 17 or 18s. As a legacy holder cannot delete parent objectses, you can do all the other changes but not that one.
An interesting part from the question from Andrea was, so, if there was an automatic change in the object after changes after that was not verified this would actually trigger an investigation by the NCC, what was actually happening here and do we want to remove after verification that line, it's actually an interesting part, because at that point if you do transfers, typically the escrow would actually have been paid out already, so the fraudulent trust anchors has already been commissioned and the buyer would have no money any more at that point and the NCC would actually take its resources. So, for brokers, they would actually have to say you know, there is the option to, as an escrow agent, you can proceed with the payout after the NCC actually has done their due diligence and actually updated the registry. Which is already possible. We do that all the time. We process the paperwork to the RIPE NCC. Once we get the information back from the RIPE NCC and confirmation, everything is done we remove the parent object, blah blah blah blah, then the Eskor agent is informed and then the payment is done. So it's a fully secure system already, if you want it to be like that.
SANDER STEFFANN: That is exactly what I was wondering. Like, what does the proposal add that we do not already have? I'm trying ‑‑ I'm just trying to be a good Chair, I am trying to filter and make sure we don't do unnecessary policies.
AUDIENCE SPEAKER: Wilfried again, trying to answer your question like what's the difference. If this goes ahead you get a free ride. If you do the thing that we have in place, you have to pay the annual fee per resource. That would be my first indication that's the major difference.
ELVIS VELEA: I tried to answer already, but if you do this, if we get this approved, if a hijack happens, this will be immediately notified. The object will be updated in the RIPE database to say this was updated but not yet verified by the NCC.
SANDER STEFFANN: Yeah, I understand what Wilfried says, we have the current legacy policy which says if you enter into a contractual relationship with the NCC the NCC does all the verification. If you would offer all the benefits without actually entering into a contractual relationship, this would be a free version of what we already have then. Yeah, I can see that reasoning.
WILIFRIED WOEBER: And there is another difference. Although it's inverse logic, because for all of those objects, all of those resources which are already covered by the proper procedure, you have the link to the sponsoring organisation. If there isn't any of those links, then this is exactly what you want to sort of discriminate against. So anyone who is a little bit knowledgeable about the can easily get the information whether the due diligence has been done or in process or whether this is something which is just out there in the wild. I don't think that we need to spend the resources (money) of the RIPE NCC members to support sort of that free ride more easy thing to inverse the logic, to invert the logic. Just my feeling.
ELVIS VELEA: So if you enter into ‑‑ Wilfried, if you enter into a contractual relationship with the RIPE NCC as a legacy resource holder, are you paying anything?
WILIFRIED WOEBER: Yes. Not myself. It depends on the regional agreement like in our situation, we are running the supporting local registry, and we are not passing on the annual fee to our network customers or members. I know that there are some other LIRs which actually sort of pass the invoice from the RIPE NCC onto the resource holder but there is no structural difference. Someone has to pay, I think it's €50 a piece right now.
SANDER STEFFANN: I just sent the invoice today to my favourite Legacy holder, and it's €50.
WILIFRIED WOEBER: Yes, someone pays for T but other than that, it's just ‑‑
ELVIS VELEA: We're talking about €50 a year.
WILIFRIED WOEBER: That's my feeling, yeah
GERT DÖRING: Okay. I really have no very clear guidance either way, but I have a couple of sceptical voices, so, I think we have exhausted all points of view today, and at the end of the discussion phase on the mailing list, I will do a summary and try to come to a conclusion either way.
In the discussion phase we don't consensus. Maybe we need wording changes before that. It's a complicated one. Thanks for a good discussion. Thanks to you for bringing multiple different points of view so look into this which is why we are having this.
ELVIS VELEA: One last thing to mention just before I step down from the stage is that let's not forget where this all started. This all started because there is one sort of transfers that is not being made public by the RIPE NCC. Everything else, inter RIRs, legacy or non legacy transfers are published on the RIPE website. PA, PI are published. IntraRIR legacy transfers are not published. So that's where it all started.
GERT DÖRING: But that proposal is kind of complex to get that extra line so you could have just said if it's in the system and there is a transfer, please put it on the web page. So, the implications are more than just having this line because they are two different coloured legacy spaces.
ELVIS VELEA: I tried to talk to Marco to find the best way to make this as simple as possible. So if there are other ways to simplify this, I'd accept all the feedback and I'll work again with Marco to come up with Version 2 that is simplified and still requires the same thing.
GERT DÖRING: We might actually end up with something that says if the legacy space is in the system, the NCC is asked to publish the transfer. That would be a very easy one and I think not a very controversial one. The problem is with all the people who don't have contracts and we put obligations on them which is always a bit complicated.
ELVIS VELEA: What's a transfer?
GERT DÖRING: I think the NCC knows what a transfer is. They are good at that.
SANDER STEFFANN: I think it's simple F they have a contractual relationship with somebody and that person transfers the resources to somebody else, then there has to be another contractual relationship again because it's a different entity. So, that would be a transfer.
ELVIS VELEA: That's clear, but for the ones that do not have a contractual relationship, we won't see the ‑‑
SANDER STEFFANN: I think the big question is do we want to put a burden on those people, because doing it optionally, we already have an option, they could already enter into a contractual relationship, so if we want to fix that, we would have to make it mandatory to get the full picture and is that a burden we can place or are willing to place on legacy holders. I think that's what we're coming down to now.
ELVIS VELEA: Okay. Thank you everyone.
(Applause)
GERT DÖRING: So, this proposal has been sitting in our work queue since before the last RIPE meeting. It's about the issues with the very, very strict IPv6 PI policy. It has been in discussion phase, it has been in review phase. There was not enough support to go ahead with the current wording, but in general, the idea to fix the issues that people have experienced, there has been quite a bit of support for.
Max has thought about this and tried to come up with new wording and he is here to present a new version and get your feedback.
MAXIMILLIAN WILHELM: So, a little bit of explanation what was this about for anybody who was not in the topic. So I proposed this I think around a year ago. The problem we faced, as RIPE communities, is we are not allowed to get PI space for IPv6 because we want to use this space in the public which identifies and the current standing interpretation of the NCC is that, if I put my smartphone on to that Wi‑Fi, I get a sub‑allocation, sorry, a sub‑assignment, because of SLAAC and even a /128, as a sub‑assignment.
So, many people get denied IPv6 PI space for this reason or the same reason with VPN connections and something of the like.
This is based on these two quotations from the current policy. The PI assignment cannot be further assigned to other organisations. Or they may not be a sub‑assignment to a third party.
Therefore it's declined.
So the first approach was based on the length of the prefix used. The idea was that a /64 is okay, and everything shorter ‑‑ longer ‑‑ sorry, shorter prefixes could not be assigned to anyone. So it's not possible to route a /56 or something to a customer. But there were some concerns. We had some rough consensus in the discussion phase /O though there was some support for the general idea to loosen up this restriction but there were some concerns about the fixed boundary and some RFC issues. And the Impact Analysis showed that the interpretation of the RIPE wasn't what I intended to do.
So let's drop that and have another approach.
We strike the "Cannot be further assigned to other organisations" part and replace it with this one. So "PI space may only be used on networks that are under the control and responsibility of the entity they are assigned to and delegating responsibility to third parties or assigning subnets to third parties is not permitted." Maybe it would be even better to say "Whole subnets." So that would be the idea.
You should be allowed to use it on public Wi‑Fi like here which is PI space because the RIPE cannot be a member of itself. You should be able to use it on point‑to‑point links to your customers with your infrastructure. And maybe you should be allowed to use it when you are housing or hosting server machines for your customers and the infrastructure is basically yours and only the servers are inside that infrastructure. But, it not be intended to use it if you are a DSL or cable provider and hand out IPv6 space to your customers.
So that's the new idea. I am open for questions and comments.
GERT DÖRING: Just as a matter of formality. This is not the format text of Version 2.0 now. It's an idea that might work. And we need your feedback before bringing it formally into the system, whether this is something useful or we spend another two months with a loop that's not getting anywhere.
AUDIENCE SPEAKER: Elvis. I like it. What's the difference between the point‑to‑point links to customers and the DSL cable customers?
GERT DÖRING: You are supposed to give a customer a sub‑net not a single IP address. That is actually a question I have been waiting for and you already sit there smiling. Back in the day, ten years ago when we did the v6 PI policy, people were afraid that we would be giving an incentive to DSL operators to give customers a single IPv6 address as they do in v4 land, and force them to use that. We have discussed this before, and personally I think this danger is not as big any more because we have functioning v6 providers out there that give sub‑nets to their customers and we don't have CPEs that do not do it by default. These are providers that want to do single PIP address to customers will actually find a CPE that works for that, and he will have a market disadvantage, because everybody else is doing something else, there is a BCOP document that says thou shalt not do that. So I don't think we should as strongly try to "Fix" this in policy as it might have been necessary ten years ago.
ELVIS VELEA: So I like the idea that you can use it for public Wi‑Fis, that's the reason for the policy proposal. I like that you could use it for hosting or housing servers, virtual, physical, whatever. I still don't know about the PtP things because that might still open something that we mightn't want to open. The possibility of someone offering just ‑‑ you are talking about CPEs. Romania for example have 50 or 80% don't use CPEs. They have a direct or UTP, or fibre, to their house and then that goes into their favourite router or computer ‑‑
GERT DÖRING: A router is a CPE.
ELVIS VELEA: Or a computer directly. So ‑‑ anyway... that's my personal opinion. Non about the PtP links.
GERT DÖRING: I would not worry about Romania because they have such a large v6 rollout with subnets that they are showing us how it's done properly.
ELVIS VELEA: I'm giving an example, but... okay D.
SANDER STEFFANN: It basically comes down in the past we thought people were so inexperienced with v6 that we needed strong guidance in the policy to force them in the right direction and my own gut feeling is that we have gone far enough now and set enough standards that we don't need policy to use policy as leverage for that any more.
AUDIENCE SPEAKER: Jakart .... I like this idea much better than the previous, but also the concern is a little bit about PtoP links because if you have customers, then you have to assign, out of their PA space, some RIS for the customer, so in that case, why would you need to use PI space for the link itself? I don't see like any justification for this.
MAXIMILLIAN WILHELM: If the customer might have some own PI, I could route it and have my IPSpace for the pitta filling and announce the PI space of that customer.
GERT DÖRING: It's not like you are encouraged to use that for PtP links but if you come to the RIPE NCC and say I have lots of customers with PI space, with their own address space for whatever reason, and I want to number of the inter‑connections with that, you couldn't do undercurrent policy. So, just to clarify that yes, it can be done now, be aware. It's not an encouragement to do that but if you ‑‑ if we change it that way, that could be done. You don't have to.
AUDIENCE SPEAKER: And the other thing I was going to point out. I think maybe there should be some like more general comment specifying what is exactly considered as a sub‑assignment and what is not. Maybe not only specific for IPv6, but also for IPv4, because there are some differences and, for instance, what I heard now ‑‑ well, just I noticed something that some ISP is actually assigning to their end end users some IPv6 prefix /62 which is horrible itself but beginning with someone, 67 C something something, which immediately raised my alarm because it's PI space ‑‑ Dore are Dore that's definitely a disallowed assignment undercurrent policy.
AUDIENCE SPEAKER: When I just started poking into it I get an answer like those are so‑called ISPs that have just one upstream, so they are not willing to pay anything to become an LIR, so they are operating IPv4 PI space for their customers and when they are deploying IPv6 they go the same way which is obviously wrong. But, the other option is not deploying IPv6 at all which is what I don't see ‑‑
SANDER STEFFANN: What you are saying now is illegal under the current policy and would still be illegal under the new policy. And that's intentional.
AUDIENCE SPEAKER: Yes certainly. But maybe the question is whether using IPv4 PI space for broadband pools is okay or not
GERT DÖRING: It is, it is according to current policy because there is an exception for infrastructure which this is considered to be. And it has been like that since the dawn of time. And we have discussed this here, well not here, but in the Address Policy Working Group numerous times that v4 and v6 is different in in aspect nobody ever lobbied to change the v4 policy in that respect, about you that topic is game over anyway. So... yeah, that was what I said initially, we wanted to provide guidance to v6 roll‑outs to not do the same model with single address and forcing customers to do NAT which is why the PI policy was much more strict. If small‑ish ISPs still do funny things that they are not telling the RIPE NCC about because otherwise they wouldn't have gotten the space, that's a different aspect. People lying to the RIPE NCC. This one is encouraging people to not lie to the RIPE NCC to get guest network addresses approved.
AUDIENCE SPEAKER: I am standing here because I am honest. Thanks.
AUDIENCE SPEAKER: Jordi: To be honest, I think I need more time to process this new proposal. But my fear in a quick thought is, if you go to the next slide, maybe now we believe that these three alone are enough and then in one month after the proposal is approved, we realise that we need missed something.
SANDER STEFFANN: We always miss something.
AUDIENCE SPEAKER: I know, but at the end, even if I'm somehow guilty for all this because I was the one that submitted the policy proposal for PI, I have been thinking already for several months and already commented with some people here, maybe we need to get rid of the difference between PA and PI and I'm probably going to work on that in a very short time. I am talking about maximum of three weeks from now
GERT DÖRING: Let me comment on that. We have been there. I'm not sure if you have seen the fall out of that. We have done quite a bit of work to figure out what the consequences would be, and the result was so complicated that the Working Group immediately said go away, heave the room please, don't do this to us.
We might still look into this again, but let's not couple these two. Let's solve them independently, because like, don't worry about this, we will fix it all by unifying PA and PI might not work out in a year's time and he is still waiting for his addresses.
AUDIENCE SPEAKER: I agree
GERT DÖRING: So let's try to do one piece at a time.
AUDIENCE SPEAKER: (Jordi): I also know sometimes and this happened here, you discuss something, it doesn't work and after two years you come back and it works. So...
GERT DÖRING: Of course, I understand that.
AUDIENCE SPEAKER: Jordi: To be honest, I think this should be fine right now by I really need some more cycles to process it
GERT DÖRING: Please do. And just as a comment, we are not holding you guilty as long as you bring enough beer. But formally, it's the Working Group that makes the decision, you just prodded up into it.
ELVIS VELEA: I understand now the PtP links thing and actually I think it is an acceptable idea especially because I understand that you want to use it so that you could actually route the customer's PI space, for example.
SANDER STEFFANN: Or for example you have two enterprise that is want to set up a link between them or...
ELVIS VELEA: Okay. So that's fine. And to respond to Jordi, I was the regional proposer for the PA/PI unification to only have one colour of IP addresses. If you want to revisit this, I'll be most definitely happy to work with you on it, and we could try to see if we could put it back to the Working Group.
GERT DÖRING: Marco.
AUDIENCE SPEAKER: Marco Schmidt, RIPE NCC. We had yet a little meeting and also you presented already this text to us to explain, and of course we understand that's not the final text and also we would do a proper Impact Analysis of our understanding, but we ran it already with some experienced IP As in the registration services and what we would understand currently if this text goes on, is that every sub‑net up to a /127 would not be allowed because no sub‑nets can be assigned and a single IP. We had some concerns like some people, if you go back to the first sentence, and say okay I'm responsible so I can request and later get disappointed if you tell them no actually not. And also there might be some confusion about sub‑nets versus prefixes like out of a /64 giving a single IP, how does this work? But also basically get, Sander said, we find out the interpretation that is out there right now. It's not just only RIPE NCC's interpretation, it was double checked a couple of times with the community and we got the confirmation yes please be strict because elsewhere to draw the line but also we would welcome feedback from the community, times have changed, to, yeah, to look at it, to revisit it and then find a solution also in the policy that allows us to be not so strict any more.
SANDER STEFFANN: Yeah, I was already thinking about the last sentence about the sub‑nets, maybe add a word like, to assign whole sub‑nets, like emphasise the sub‑net bit, something like that. So... we'll help Max to fine tune it.
MAXIMILLIAN WILHELM: What does this whole sub‑nets make you a little bit happier?
MARCO SCHMIDT: I have to be very political. We would need to make ‑‑ obviously everything that helps it to make it more precise is welcome and also people would need to understand right now this solution is proposed for for example, but like what other people say there, a lot of other applications and then we would always need to look into it, does it fit into the policy or not and we don't know yet even what solutions are out there, but, yeah, as I said, let's work together on it and come to something that is as clear as possible and as usable as possible.
SANDER STEFFANN: I know we already talked about it yesterday, but could the RIPE NCC please help us, and maybe we can bounce it off each other, see how this would be interpreted and maybe go through the backlog and see things, difficult cases in the past, if this would have fixed those cases or maybe if this would have allowed things that we really don't want ‑‑ you know, just maybe we should try to see how this works. And of course I know you are going to do the Impact Analysis.
ELVIS VELEA: So, I don't see Wi‑Fi anywhere in the text, in this text.
GERT DÖRING: It doesn't have to be.
ELVIS VELEA: Exactly.
MAXIMILLIAN WILHELM: That's the charm of it.
ELVIS VELEA: If you go back to the next slide. This would allow use of IPv6 PI for example Wi‑Fi PtP links, hosting, but it would not limit it to this. It would allow use of IPv6 PI for any kind of application that does not do an assignment to a cable customer or broadband. So maybe adding the restriction that IPv6 PI does not apply to broadband or mobile or any kind of connectivity, then maybe then we could include everything else. So, just exclude IPv6 PI for connectivity and allow it for anything else.
GERT DÖRING: I don't think we need to actually include it ‑‑ exclude it. Because, like, in 3G, you have 3G standards that say every mobile gets a 64, and that's a very clear statement and that's ‑‑ if I have ever seen a sub‑net, that's a sub‑net, a 64. And I don't really think we need to worry about that because there is good precedence on the market that people can get this right.
But, what you are saying is this needs to go in the rational so that the intended use after the change is clearly spelled out and the sort of like discouraged use, not disallowed, but discouraged, because there is better approaches is also mentioned, but we don't tell: This is an exclusive list of things you are allowed then, because in the end the policy text is what makes the decision, but having the rational with what the underlying thought of this change is, helps the NCC make the evaluation in cases that are not as clear‑cut. So we need a good rationale and a good text. And I think we are on a good track.
ELVIS VELEA: And I'll complicate this a big more. What's the difference between assigning a /64 to your cable customer and assigning a /56 to your virtual machine's customer? Tor Dore you are allowed to do neither.
SANDER STEFFANN: Both are to the allowed
GERT DÖRING: You are give a hosting customer a single IP address if you run the network where it's connected to. You are not allowed to give them a 56.
ELVIS VELEA: So you are not going to be allowed to give them a 56.
GERT DÖRING: It says no sub‑net.
ELVIS VELEA: But you could use a /64 for the link to every virtual machine of that customer.
GERT DÖRING: Yes. As long as you run the infrastructure, you do the IPv6 assignment and the customer just runs the machine. If you give him a sub‑net and say organise however you like, this is an assignment. This is very clear in the policy.
SANDER STEFFANN: May can you say on the first bit. So cannot give somebody else, like here is a /56 you can run your own network.
ELVIS VELEA: It's not about running your own network. Here is a /56 for your virtual machines that I'm giving you, I am running, I'm giving you 20 virtual machines ‑‑
SANDER STEFFANN: And then you check the second bit which says cannot assign a whole sub‑net to a customer. That's exactly why both cases are spelled out there.
ELVIS VELEA: Okay.
WILIFRIED WOEBER: I like the idea of sort of having this section where we explain what we want to achieve with that. I am perfectly fine with that. I do understand what the goals of the Version 2 are. And I support it. I am just being a little bit worried in this slide, not necessarily in the text for the policy, about the choice of words, because formally even a /127 is a sub‑net. So, I think we should review the choice of words like "You are not supposed to delegate a sub‑net" because even if you get the 128, this is formally a sub‑net
GERT DÖRING: 128 is not a sub‑net.
WILIFRIED WOEBER: It's not really a sub‑net but 127 might already be considered a sub‑net. That's nitpicking. The thing in that I'm less happy with is the choice of the term "Responsibility." And that's not sort of worries from the address management point of view, you but from the point of view of interpreting the policy operationally, because in many environments, the responsibility to operate the network is with the holder of the address space, but the responsibility of what is done, for example, on a virtual machine or on a website is with the operator of the virtual machine.
So, delegating a responsibility to third parties is sort of too fuzzy from my point of view. It should point at the fact that this receiving organisational entity or person is not supposed to do their own error space design and planning and they are not supposed to take this sub‑net of the PI to do a PI from a PI and decide about having it routed from somewhere else. Just nit‑picking with words, and I may contribute sort of my thoughts during one of those discussions
GERT DÖRING: What I'm hearing here is quite clear. I think you two get into an e‑mail exchange and sort it out.
SANDER STEFFANN: I want to point out that it says "On the network that's under responsibility..."
GERT DÖRING: So, if it could be more clear.
SANDER STEFFANN: Absolutely.
MAXIMILLIAN WILHELM: I think you were more talking about the second sentence, right?
WILIFRIED WOEBER: Yeah.
SANDER STEFFANN: Okay
GERT DÖRING: Yeah, but still that's why we're here to get feedback whether this is good enough or not. And establish contacts to word Smith the final bits and then put it into the machinery again.
AUDIENCE SPEAKER: Sean Stuart. Speaking only as myself. I think the easiest way to interpret host versus sub‑net is if I give you an address on 127 to connect to my network recollect it's a host F you give you a 127 connect your VM to another VM, that's a network
GERT DÖRING: Anyway. What I'm hearing from the room is general support of the direction. Some concerns about side effects, and that's why we are going to have the Impact Analysis of course. Concerns about wording, and I think we have sorted out the way forward on that. Thanks.
And we are good to go ahead. Thanks for coming. Thanks for taking the tomatoes.
And with that, we have amazingly only 15 minutes left. I expected us to finish only ‑‑ well if there is the need for discussion, that's why we meet. So we have 15 minutes left for either an early lunch break, or any other business.
SANDER STEFFANN: And I think Randy already raised some other business in the first session. Do you want to spend sometime discussing that now?
RANDY BUSH: Do other people want to discuss it further?
SANDER STEFFANN: This was the issue of the minimum allocation size which is now a /22 from the final /8, whether that should be changed into, for example, a /24 to extend the lifetime of the final /8 policy. Any takers?
ELVIS VELEA: Hi Randy. Why not! Let's talk about it. I actually have a discussion that I would like to have. A bit linked to extending the lifeline of the IPv4 life as well, but let's talk about this one first.
RANDY BUSH: I was, I believe, one of the original proposers of the last /8. The intent is that 10 and 20 years from now unfortunately you have to be able to reach, from your network, other ‑‑ well not other, you'll have to be able to reach from your network v4 networks. The Internet will not be, unfortunately, moved to IPv6 entirely. To do so ‑‑ most of my customers are large enterprises, very large enterprise, the big banks, Toyota, etc. If they want to convert internally they do to do some NAT 64 whatever that evolves to. For that purpose they need to have a little v4 at their edge, it can be very small. Raymond, I don't mean to rant on, do you have a contribution you'd like to make quick?
AUDIENCE SPEAKER: Raymond: Just a short comment sometime, but please tell your thing first.
RANDY BUSH: So, right now, the pragmatic longest routable prefix on the Internet is a /24. I assure you it wasn't always the case. It used to be a 19. There was an agreement, a meeting a minds between the operators and the RIRs on what a reasonable boundary would be and that's evolved. So you will be able to route a /24 right now and I think five years from now we're going to be talking routing a /29. And for those who are worried about TCAM, you know, I have always been worried about TCAM and it's always moved. And come see tomorrow's BoF ‑‑ no, tomorrow there is a RACI presentation on fragmentation and essentially fragmentation has remained relatively constant, in other words the percentage of prefixes has been the same. So, the routers, they'll love to sell us new routers. It will route, etc. The problem is, as you heard earlier today, we are going to run out in three or four years at the current rate. In three or four years from now, somebody entering the game is not going to be able to get a v4 address to enter the game. I don't like to raise the boogeyman of the regulators, but somebody who got their law degree is going to call this restraintive trade, and come talk to us. But the real problem is, it is our responsibility, as stewards of the numbered space, to enable people to use it and be successful entering the market. So... I'm looking for a co‑author for a proposal to lower the minimum. Preferably somebody not whose business is not buying and selling address space. Raymond?
AUDIENCE SPEAKER: Ray,ey lies a. I think that we should not try to do this. With all respect, but, IPv6 has been around for such a long time already. We can try to iron it out for the next ten, maybe 20, maybe 50 years, but the reality is it's going to run out, as we all know.
We have to face the reality. And therefore, I am not agreeing with this. However, I understand what you mean with newcomers who might need it, but I still think it should not be done. Thank you.
AUDIENCE SPEAKER: Anna Wilson, HEAnet. I hear you both. For me it comes down to I am ‑‑ I work for a service provider that routes quite a lot of IPv4 address space and I am very uncomfortable with the idea of turning around in three or four years time and saying no, we decided that because v6 is very important and we didn't do a very good job in the past, that you now have to deal with the consequences to someone who doesn't have all that address space. I don't think that's a good idea. So I think this policy is a good idea.
AUDIENCE SPEAKER: Elvis Velea: So, Randy, I already said that I think it's a good idea to have twist in the lifeline of IPv4, not because I am a broker but because the reason is lots of companies will still need to connect to the legacy Internet. I have a slide and I asked them to get it ready. I don't think it's a good idea that we do this with a current /8, but we still have a million IP addresses reserved for whatever we would think of in the future. I would say this million IP addresses may be used for the /24 you are talking about. The million IP addresses, which is what, /12?
ANNA WILSON: Why those once?
ELVIS VELEA: Because right now we already have a policy for the last /22 and when Randy will make a policy proposal about changing the last /8 policy, tomatoes, carrots ‑‑
RANDY BUSH: I'm not proposing to change the last /8 policy. The last /8 policy says use the minimum allocation. I'm proposing to change the minimum allocation across the board.
ELVIS VELEA: Which is almost the same thing. But okay, you are proposing to change the minimum allocation from a /22 to a /24. What I'm thinking is, I'm suggesting that you could think of setting up the /24 goal for the one million IP addresses instead.
SANDER STEFFANN: Elvis, one million IP address Yours sincerely 4,000 /24s. It's not going to be enough. If this is the goal, then that's not going to reach it.
ELVIS VELEA: By the time we adopt this, it's going to ‑‑ at least a year will have passed and we'll only have less than 5 million IP addresses in the free pool, in the /22 pool. By the time, if it ever gets adopted, will still have only a tiny bit of IP address. Anyway...
AUDIENCE SPEAKER: Marco Schmidt: I want to quickly respond to the Elvis to the one million reserved address space. Just one /16 of this one million is reserved for unforeseen circumstances. A big part of this one million is set aside for a pool of temporary assignments. So hacking into that one would have consequences in another policy. I just would like to ‑‑ if the community would decide to go that way, to keep the side effects into account.
AUDIENCE SPEAKER: Rob Evans: So I'm a glutton for punishment. I am not sure that I am enough of a glutton for punishment to say let's discuss this for a /24 now and then a /25 in another six months after that, and then 26, 27, 28 and then 29. Maybe we could consider something like a sliding window based on the amount of address space remaining, so it can have, decide the allocation according to what the address space is. There is also, I guess there is two bits of the policy is the allocation size and there is also a maximum amount of address space allocated to a customer after the 12th September 2012 or whatever, being a /22. So, do both of those go down in tandem?
GERT DÖRING: That's paperwork to be sorted out. Which bits to change where. But as long as the intention is clear, the NCC will help us with the text.
RANDY BUSH: First of all apologies, you are not not Nick. The reason I was saying a 24 now is I would like to get the reduction soon to at least a /24, but I think we're going to take a couple of years of experimentation and promulgation through the ops community to route anything longer. I think having a sliding scale would also achieve that, because it would send the message it's going to get longer and we'll all go back and start letting it into our routers and buying stock in the companies who make TCAMs. So, I don't think that's unreasonable. Carlos.
AUDIENCE SPEAKER: Carlos Reyes: A small comment and a question. The small comment is I'm also worried about the routing table size. And the question is, is this ‑‑ well will other regions play along with getting, by doing the same and going even beyond a /24?
RANDY BUSH: I think there already have been experiments and I think is it ARIN, is somebody here who can speak with some authority for ARIN, has already done an experiment in this space?
AUDIENCE SPEAKER: (Rob Seastrom): I am actually not here to speak on behalf of ARIN.
RANDY BUSH: Then you should get your badge changed. But, Raz, introduce yourself.
AUDIENCE SPEAKER: Rob Seastrom, speaking on my own behalf. I have noticed that lamp oil smells bad and smokes when it is burned and it is fairly hard to get, compared to LED light bulbs and batteries and nobody is getting their panties in a bunch about this, and the X.121 annex that listed the available DNX has not been updated since 2011, and I'm not sure that updating routing to route successful longer prefixes of IPv4 address space actually serves any particular purpose just so we can carve it up smaller and smaller and smaller the thank you.
WILIFRIED WOEBER: That's slightly autagonal to the merits of person prefix lengths. I was just again hearing ‑‑ I was just hearing again the worries about the routing table size, and I keep hearing those worries for how many years, 15 or 20 maybe, and for about so long a time frame we have the networks relevant, not the networks relevant, weekly or monthly statistics about the potential savings in the set. Nobody cares about the routing table size from that aspect for the last 10 or 15 years. So my feeling is we should certainly worry about the potential explosion of the routing table, but this should be not the guiding argument when we think about this policy. Because we have got more than enough slack for a couple of years if there is a real problem then we go after the most, the worst violators.
RANDY BUSH: A historical note the the agreement on the /19 is the longest routable and that the RIRs would allocate 19s as the longest prefix was in 1995 at the IETF, and the reason was that sprints routers were falling over. Not so much because of the number of prefixes, but because of churn, that CPE processing on AG Ss. We're past those years. But routers have ‑‑ the restrictions of routers have caused policy and so I'm not ignoring that and I run routers, but I also have grandchildren, and I want them to be able to get on the Internet. They already have actually.
ELVIS VELEA: I was asked to make this very short. Last time we tried to do something about the IPv4 policy, this community was almost torn apart, especially because of a few people that had special interests on the last bits of the IPv4. So, while I think your idea is very good, I think that going there, it's going to be a long and complicated road and it's going to take longer than we might still have until we actually run out completely.
RANDY BUSH: Especially with you and I at the mikes
GERT DÖRING: But that shouldn't stop us from trying. I have a thick skin, I have been called about everything that you could possibly be accused of, so there is hardly anything that would surprise me in the next round of ‑‑
RANDY BUSH: Somebody new wants to speak.
AUDIENCE SPEAKER: Tomas from DFN. From an operator perspective, I would suggest that if we opened the can of worms to accept smaller prefixes than a /24, we should restrict it to some well known prefix ranges and not to allow it for everybody, because that would really potentially swamp the routing end and make prefix sessions dropped and so on and so forth.
RANDY BUSH: Good point
GERT DÖRING: And now we actually made good use of our time, the time is over. It's lunch time now.
SANDER STEFFANN: I think Randy, you are still looking for authors.
RANDY BUSH: I hope to have found one...
SANDER STEFFANN: If not, we have a mailing list
GERT DÖRING: Thank you all. Thank you for the input. That's the reason why we're here.
(Applause)
Enjoy your lunch and see you around.
Lunch break.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
