These are unedited transcripts and may contain errors.
Address Policy Working Group session
14 May 2014
11 a.m.
CHAIR: So, let's get back to work. We have a pretty full plate for this time slot. If we are going to have lively discussions on every proposal, we are going to run full into lunch break, so, let's start, so we can make the best use of the time we have.
I don't see a much larger attendance so I'll skip the introductory part and just say welcome back. And with that, we just jump to the first presentation by Jan Zorz and Marco Smith. This came out of a discussion about ambiguity in the language in our policy documents at the last RIPE Meeting with shoulds and musts and well, Andrea actually brought up a nice example of a policy text that says "should" and the NCC is reading this as a must, so maybe we have some work to do here. Jan please.
JAN ZORZ: Good morning. My name is Jan Zorz and with this, I am completely with no hats, no affiliation, random Jan from the community that happens to listen what people is saying in other Address Policy Working Groups in other regions.
So, let's see...
So, in Athens, for those of who you were there, may be remember I innocently shared ?? the story what happened to me in Zambian when I was sitting at the Address Policy Working Group there and they were talking about the sentence that said "An LIR should plan to announce a block as a whole to prevent the splitting it" and they were saying that they need to remove it, because it's too hard and it's too binding because they need to do the traffic engineering. And I said, hey, guys, there is RFC 2119 that defines the usage and interpretation of the words should and must. Should is you do it unless you have a really good reason not to. Must is a must. So, read the sentence again. "An LIR should plan..." right, that means you plan it unless you have a really good reason not to. And this then resulted in some discussion with RIPE NCC staff and Sander and Gert, that this might be a problem, so I shared this story with you and said do we want to look into our policy and see how many ambiguous shoulds we have.
So, feedback last time was, we must, we must not, and we absolutely should. So, what's that? What that even means. So Gert asked the RIPE NCC staff if they could go back and read the policy and find the ambiguous shoulds and Marco did the hard work, did the heavy lifting so I'll leave it to him to present his findings.
MARCO SCHMIDT: Marco Schmidt, again the RIPE NCC policy development officer and yeah, I would like to show you what we found of ambiguous shoulds in RIPE policies. But, before I go to it, I just want to quote here the actual wording of the RFC 2119 about the definition of should and of must, because that's probably quite useful to keep in mind when we talk now, or when I present the different findings.
So "should" basically says that "There may exist valid reason to in particular circumstances to ignore the particular item, but it must be carefully weighted before choosing a different course." And must, on the other hand, is an absolute requirement, no exceptions possible.
I have to warn you in the next slides there will be quite some quotations, because obviously I had to look up policy text but I will keep it as short as possible and just mention the necessary parts. That's the first finding that I have, I decided to ?? or we decided to group these findings via a RIPE document, via a policy document, I will start with the RIPE document 606 which is the IPv4 address allocation assignment policies. You can see in the right corner a number, so I have given a number of all these findings so in case later after this presentation you want to comment on some of the findings, it would be easier for you to you can see. I want to say something about should number 3, for example.
First one?off is in section 3.1, confidentiality, that says that "Internet registries have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR." So, as already, this text allows, to pass on the information if necessary, there is probably no other valid reason that why it should be passed on so we find this as a quite ambiguous should.
Next one is same document in the area of supply allocations, that says "LIRs holding allocated PI or allocated unspecified allocations may be able to convert them to PI allocation ifs there are no assigned PI networks in it." Later it says "LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by e?mail."
That's a bit of a special case, technically spoken there is no other way, there is no other way to change the status of an allocated object, you have to contact the RIPE NCC.
Policy textwise, RFCwise, using the word "must" might be sounding too strict because it talks about something kind, a kind of service that is needed. So why should is confusing a wording, something like can might be more clear.
Next one of still the same documents, the type of address space when it talks about PA space, it says "Clear contractual arrangements are mandatory for PA space. And End Users requesting PA space should be given this or a similar warning."
As clear contractual arrangements are mandatory, actually the warning also must be, or should be ?? must be mandatory ?? that's the thing ?? I knew it would happen.
Next one is still in the same section, 7.0, types of address space. We have two types mentioned, LIR partitioned PA and LIR partitioned PI. Both times it says "When address space is used a more specific I neat numb should be registered." Address space doesn't use, must be, just in an assignment, that's one of the main necessities, main requirements of the RIPE registry.
Now I'm moving on to another document, RIPE?589 the IPv6 address allocation and assignment policy. I go to section 7.1. This section seems to be a kind of a boomerang, it will come back and back, or it came already
TORE ANDERSON: Ray a mentioned it earlier in his presentation, I'm pretty sure that later in the discussion of proposal 2014?04 it might also be mentioned and, here I would just read it out.
"When an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.
"The LIR must return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.
"If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both."
So, basically, in the same section we have two times the term "Must" and one time "Should." While actually, it describes the same situation just in a different order, what was received first, and even the requirement to return address space if the criteria is lost, was also a "must." So we find this one of our ambiguous findings of the term "Should."
Another document, IPv6 address space policy for internet exchange points. That says "Addresses needed for other purposes should be acquired through the appropriate means." And it is ambiguous in our point of view because the policy seems to indicate that it's assignments for IXPs is to be used for the peering LAN for example in the IPv4 policy it's much nor strict, it only can be used but here the word "Should" is used.
Same applies for this finding in another document, RIPE?233, "The IPv6 addresses for Internet route servers in the RIPE region" where it also says that "... and these organisations should not use the address space to provide any service not related to the route servers." As I said, similar situation, also in the IPv4 policy when it still had the section in it, it was removed with the acceptance of proposal 2013?03 but in the past, IPv4, as I said, must ?? it was stricter.
Then another finding, we are almost done ?? that's the second last ?? it's in hype?452, the contractual requirements for provider independent resource holders in the RIPE NCC service region.
And then with talks about the contract that is necessary between the end user and the sponsoring LIR that says "The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts 'should' include... " Well, actually when you say you already say there is a minimum requirement, what other reason might be there to have something different, or at least not this.
And last but not least, we are returning to something that directly to the RIPE NCC itself, document 476, allocating an assignment resources to the RIPE NCC and that says "The RIPE NCC as a resource holder should fulfil the same basic requirements also expected of normal LIRs" we think the RIPE NCC must be a good example, and ?? must fulfil the same requirements than our members.
That's from my side. My findings, and I give the mike back to Jan. Thank you.
JAN ZORZ: So, thank you Marco, thank you RIPE NCC for all the hard work, reading all the policies. 10 minutes, is that a should or a must? It's a must, okay.
My question here is: What do we want to do with this? We pointed out the problem, we have some results, they found the ambiguity. So, we might define this as a non issue, do something else instead, or we could realise that we need to fix these possible ambiguities and have better policies. So if we don't care is selected, then exit 1. But if the community decides that there is some action of fixing, then we need to find a procedure to change all the documents, we need to find which shoulds are actually ambiguous for the community. We need to understand that changing shoulds to must might make the policy more strict, that the non defined ?? might. But we need some consensus from the community what we want to do and maybe if we decide on this path, I don't know, we had the cosmetic surgery project, maybe we to probe to clarification project. So with this I would like to thank you for your attention and all the feedback and comments would be very, very much appreciated.
AUDIENCE SPEAKER: I have a question from the chat room. This is James Blessing from Keycom asks a question on number 6: Can an IXP guess IP addresss from RIPE without becoming an LIR for other purposes?
GERT DOERING: I consider that to be off topic specifically. I'm sorry to do that, but we have very limited amount of time today for the individual discussions and I would prefer not to go into the individual "shoulds" and "musts," but focus on the general direction of this project only, and then do the individual "shoulds" and "musts" on demand on the mailing list or at the next meeting. But this time only the overall focus. Sorry for that.
AUDIENCE SPEAKER: Hi, Elvis. So, I think first thing we should do is to realise that this may actually confuse the NCC as well and it has already done it for years, so, I think we must change it to make it more clear. Coming to the community and trying to get consensus on whether we should have should or must will be quite a difficult task I would say, and my point of view is, I think we should do something similar to cost metric surgery, maybe language clarification, come back with a revised version, explain exactly what's the difference between the two documents and see whether then we actually start talking about consensus on changing everything.
JAN ZORZ: So your question is actually raising another question in my head, and this is the question for RIPE NCC and for Working Group Chairs. In a new policy, are you considering, and taking care of the clarity of the shoulds and musts or is the new policy going in an old way?
SANDER STEFFANN: I think for all new policies, we have to realise what we are actually writing down and make sure we don't run into these problems again. It would be silly to work on solving the problems on one hand and introducing new ones on the other hand. For new policy, we definitely think about this when looking at the text.
GERT DOERING: For new policies we have the Impact Analysis in place now which pretty much guarantees that if we have ambiguity in the text, the NCC will tell us we are not exactly clear what you want from us.
JAN ZORZ: Okay, so we achieved something.
SANDER STEFFANN: I think the most difficult problem here will be when a should is implemented as a must and was actually meant as a must, then it's just the language is unclear but the implementation actually matches the expectations the some cases maybe a should is implemented to strictly and if we start changing the language of the documents, which case is which, and it gets tricky from there.
JAN ZORZ: If, we are doing for the new policy then, it's probably good idea to go and revise the old policy to match.
SANDER STEFFANN: Yes yeah, but we have to see it what we do here, let's listen to the room.
AUDIENCE SPEAKER: So my name is Gegory curbey, I'd like first to comment on your second bullet, shoulds to musts, might make the policy more strict. I would say you have, in fact, two questions there changing "shoulds" to "musts" when we want to or keeping with "shoulds" where we want to. And when, today, we current actions from the RIPE NCC are must, I think it's not getting the policy more strict. It's just clarification at the end, so, to me, it's not a problem. Clarification is definitely something we must achieve to avoid confusions and to avoid ?? if the implementation today is a must, then we have to read the "must" and if it's a "should," we have to read a "should." That's my opinion. Then if it's clarification, or whatever the process, I don't have really an opinion, but clarification is definitely something I would like to see.
AUDIENCE SPEAKER: Same thing for me, clarity is good when ambiguity is not in terms in particular when it comes to policies, so, I'm in all favour of this activity to go through the policy documents that has been done already. So, I think we are half on the way to the goal or aim already, so, I am all in favour of that.
AUDIENCE SPEAKER: Short version, I am in favour of going through this and making these changes. Slightly longer version: I think that in the strict sense of the word "Strict" changing should to must does definitely make the policy more strict. That doesn't necessarily mean that it changes the outcome, it may make no sense in practice but it certainly does make it very clear and strict as to what it should be. So, the one looking at the ones you picked out, it seems very plausible to me that these are all cases where what was intended was must and that what we should be doing is going through and may going sure that the policy actually reflects what was intended so the suggestion on how we go forward would be go through for those, bearing in mind that it does actually make it more strict, I would treat this as an exercise in correcting to where there is already really a consensus that must is really what we want. If there is any controversy about that drop a particular one for consideration from this project and ones, that's a nice easy one go through, nuns flag this up, this is to the merely cosmetic, this is flagged up as a policy change.
AUDIENCE SPEAKER: We definitely need to get consensus from the Working Group that this textual change is what is actually meant.
AUDIENCE SPEAKER: Yes indeed. But approach it in that way, assume that what we were attempting to do is to make sure that this actually reflects what's meant. It's not an argument about really trying to effect real change in it but correct to what was intended and if there are others ?? if it turns out that there is controversy about some of them then it doesn't fall into this so drop it from this proposal in this particular case, that would be my suggestion.
AUDIENCE SPEAKER: From the chat room, a follow?on comment from James Blessing again from Keycom. If we are going to look at must, should for some examples, we must look at must and should for all cases.
SANDER STEFFANN: Definitely.
AUDIENCE SPEAKER: Kurtis Lindqvist. I think I agree with Malcolm but I lost him a little bit half?way there. I think that we had ?? I mean we had an ago at each of these policies and look at what actually has to be changed, what you listed to me it's pretty obvious that the text is correct in some of them. I am worried a bit, I can't make up my mind on this whether this is simply a cosmetic surgery, I actually think it's not it's not a cosmetic surgery, it's policy change. But do we want to a policy discussion for every policy document? No, we want to have a discussion to change that we think are ambiguous. But that itself is a policy change and should be Teredo as a policy change because it will be for those policies. What I worry about is that how do we handle the case where some of us will agree with one part of the change but not all the other ones, so maybe the easiest thing is to split them up from as separate changes from day one.
SANDER STEFFANN: That would make it easier to manage because otherwise every objection would mean another cycle through the whole process.
KURTIS LINDQVIST: Also I think that I know that we as a community has had a tendency to think that everything is important, and has to be changed but I think that when we do this we should ask the NCC if they think the next is unclear, not necessarily ??
SANDER STEFFANN: It's not just the NCC C but people who are not experienceed in this, who misinterpret the policy.
KURTIS LINDQVIST: I think we need to get IP input from the NCC.
MARCO SCHMIDT: Yes, that's our findings is that they are not clear for us, not all of them cause operational problems, I don't recall that there are any real big issue, but we want to avoid the situation that we run into an argument into an argument with somebody about should and must and so on, so we see this definitely as somebody that should be clarified.
SANDER STEFFANN: Last comments and I think we really should move onto the next subject.
AUDIENCE SPEAKER: A last subject a bit on what Malcolm said. Indeed, we should look at what the policy was meant to say at that moment ?? by the way Elvis ?? I think that would be somehow a difficult exercise, because some policies are years old, and even the proposal might not even remember whether this was supposed at that moment to be a should or a must. So what I think we should actually do is to talk to the NCC and see do you implement this as a must, do you implement as a should right at this moment? Because if you implement it as a must, changing it to a must in the document is just a cost cosmetic surgery.
AUDIENCE SPEAKER: Nurani. Just a first very quick reaction to whether or not it's cosmetic surgery or not, I do see that you need to treat these cases individually, some cases might be very simple but some might actually involve discussing the policy again, painful but I think that's what we need to do.
Three comments. One is that I think we should try to be Prague Mick about this, the aim is to clarify the document, not to create this huge new exercise, let's be pragmatic.
Second, let's try to make sure that this document doesn't, throughout ?? through this procedure, turns into this bureaucratic difficult document that's hard to access, because the policy document, for many new LIRs, is actually the entry world into the RIR world and they need to kind of understand not only the exact rules, whether this is a should or a must, but kind of the intention behind the spirit of some of the proposals or some of the policies.
And three, is that I also think we ?? that you know we have a history of trusting the RIPE NCC in doing the right thing, and clarifying the language should help them in that and not make it harder for them.
GERT DOERING: Thank you. Yeah, I think that's a good wrap?up actually. So, what I hear from you is you actually want us to do work on that and not just leave it as it is, that was quite clear. You want this to be treated as a policy change, which is it is, which I agree with. And I think we will now have to sit together and decide how to do the mechanics of this, like, who is going to be the proposer of a formal policy change which can not be you, you, or you.
JAN ZORZ: Or me?
GERT DOERING: You can, you are random Jan.
GERT DOERING: We will find a way to handle the the man IX of that and we are not going to solve it in this room right now, because we are running short of time. Thank you for bringing it up. Thank you for going through the heap of paperwork to find the "shoulds" and "musts," and give us something to think about.
Now we go into the individual policy proposals on our stack.
We start with 2012?02.
That's the usual reminder slides that whatever we discuss here helps the proposer and helps the Working Group Chairs to see which direction something should be going, but the actual decision at the end happens on the mailing list. So, the mailing list is open. Everybody is welcome to contribute and if you are not contributing to the mailing list, it's hard for the Working Group Chairs to actually decide on consensus or not. If you come up to the microphones, speak your name, but you all know that anyway. The session is webcast and yadda, yadda, yadda.
Policy proposals, 2012?02, that's the transfer policy to other RIRs which wasn't met with very much interest from this group and lay dormant for well over a year now. Also, the no need policy 2013?03, sort of like changed the policy field, so, it wasn't clear how to go on. And well now ?? Sander as the proposer has decided that you want to go on with this and brings you new text. Sandra please.
SANDRA BROWN: Good morning. As Gert said, we decided to bring the policy back because of the no needs being resolved and it kind of changed the landscape a little bit so this is some new text that I'm bringing forward today and I kind of have a bit of a feeling of day gentleman view. I don't know if Geoff Huston is here but I thought I'd kick things off with a bit of a Geoff Huston approach to the policy. I kind of thought it was funny. No chuck else, so that's a bad start.
Okay. So, as Gert said, this is a new take on the inter?RIR transfer policy. And the reason we're doing it is the time is right. Meaning of course that we have finally resolved within the RIPE region the issue of no needs. And there is kind of four points here that the policy will address.
So, it will allow the transfer of IPv4 addresses to and from other RIRs. It's going to increase or supplement the pool of IPv4 addresses in the RIPE region.
Provide access to IPv4s from other regions.
And ensure that the RIPE IPv4 database accurately reflects IPs in use in the region.
I thought it would be useful just to show the transfer volumes happening globally right now. Now, this is my count based on what I'm seeing in the databases. So, first of all, inter?RIR: So the only two regions that allow inter?RIR transfers today of course are ARIN and APNIC, and by my count there have been 34 so far between the regions. The number of within RIPE transfers so far is 342 by my count. The number within APNIC is 542, and the number within the ARIN region is 144. And to my knowledge, neither LACNIC or AfriNIC have policies yet to allow transfers within, so, those numbers are zero.
So the body of the proposal. First of all, transferring from RIPE. When Internet resources are transferred to another RIR, then the RIPE NCC will work with the destination RIR to allow the transfer to the receiving entity.
Pretty straightforward statement. And then transferring to RIPE from another RIR. So, first of all, the RIPE NCC will work with its member LIR to fulfil any requirements from the sending RIR.
And secondly, I wanted to make a specific statement about legacy resources, then the RIPE NCC will apply the legacy policy when accepting those resources.
So the rationale behind this, three points.
The policy for transfer of Internet resources outside of RIPE should be the same as the transfer policy within RIPE.
The RIPE NCC creates an operational procedure in cooperation with the RIRs to and from the RIPE region.
And in all cases the registries of the different RIRs must be consistent. So we don't want to create duplicate entries, we don't want to create inconsistencies.
The path forward is that I intend to formally withdraw 2012?02, the original policy. This is completely new text. And I'm hoping to get some feedback from this room on the general direction that I propose today. And we'll get it written down formally as a policy. And Marco will hopefully give me a new policy number, and as Gert said, we'll throw it into the policy machine and go. So, I'd be very pleased to take some questions.
GERT DOERING: Thanks for picking this up again, and ??
SANDER STEFFANN: I think it was a good summary of the intentions of the policy. The devil is always in the details, but...
AUDIENCE SPEAKER: Elvis: We have had off?line chat as well and as I told you Sandra, if needed, I'll also jump in and try to help, if needed. If you can do it yourself, wonderful, wonderful.
I think the idea is good. I think it needs working on it because the body of the whole idea is good. Not sure if it's the best idea to just drop 2012?02 and start with a new one because I think this is a follow?up of the 2012?02, but that's just administration work that you'll do with Marco, so, it's up to you.
Just for the history, I think again, this is the follow?up of what has been done already, some work has been done already for inter?RIR transfers, mainly by you and some of the community. I think it's a very good idea to move forward. As you say, the time is right. The time is right to actually have an inter?RIR transfer policy with the other regions and as far as I have heard from Marco and from other people, ARIN is moving forward at a slow pace, but it's moving forward to no need as well. And I'm 99% sure that once ARIN will have no need for up to a /16 as well, or that's what I understand, I'm again 99% sure that APNIC will revert to no need because they were actually the first ones to have no need.
SANDER STEFFANN: If you look at ?? I mean, we dropped the no need name for a reason, but there is actually a check box that says I need these addresses so it depends on how you even interpret no need. To let's not get into those details especially about policies in other regions because we can't second guess what they're doing.
GERT DOERING: That's actually why the text says the NCC will work with the LIR and the sending RIR to fulfil the requirements. So if somebody wants to transfer from ARIN and ARIN requires that the receiving LIR documents there need, it's ?? well the burden is on the NCC to come up with a procedure to.
ONDREJ FILIP: That, like have a voluntary audit that says we have audited your resources, you are at 90% utilisation, here is the stamp that you have need. But that is actually not in the text because it depends on the policies of the other regions, and ?? well it puts the burden on you but that's all we can do here, I think. And we trust to you get it right.
AUDIENCE SPEAKER: It's very clear ?? this time it's really, really clear, at least to me anyway. So thank you for the work.
GERT DOERING: Okay. Any other comments on this? Somebody who thinks that we should not do this?
AUDIENCE SPEAKER: Olive Ray Martine, I have a question. What is the size of this IPv4 market? Is it marginal? Is it booming? Is it undermining the transition to IPv6?
SANDRA BROWN: Sorry, I think this slide best characterises the size of the market. Now, these are all block sizes and by and large most of the block sizes being traded are probably 80% of the blocks on this slide are /20 and smaller. And probably 20% are /19 and larger. That's my approximation.
GERT DOERING: One comment from Jabber.
AUDIENCE SPEAKER: Hi. Another comment from James Blessing. What was the methodology for the moves calculation?
SANDRA BROWN: On the slide, I assume. The methodology for determining the counts basically was to look at the respective web pages that each RIR publishes and to exploit the transport into Exel and just count the real numbers.
AUDIENCE SPEAKER: Elvis again, just to answer a bit the previous question, I have done some numbers for the previous meeting and the presentation is there, the transfer market has seen over a /8 of transfers in total up until now and those are the official recorded ones, not legacy transfers, so there have been, since the beginning of transfers in ARIN in 2009, APNIC in 2011 or 12, and RIPE region, in total there have been more than a /8 transferred.
SANDER STEFFANN: So there is a demand for transfers, and I don't actually hear any comments on the proposal itself, so I think it's time to put the text to the mailing list.
GERT DOERING: Exactly. Work with Marco to finalise the text and get your number. Thanks for bringing it up here. Thanks for facing the questions.
And we have actually made up some time, which is good. We used to be five minutes behind, but by my schedule we are now just one minute behind schedule and that's really perfect. This is a short one, Carsten.
CARSTEN SCHIEFNER: Hi. Good morning. My name is Carsten she have another, for this proposal I'm not wearing any particular hat. The proposal itself is essentially hardly only editorial I'd say, although it's still a policy change of course, it's about getting rid of the notion of the minimum allocation size in the ?? I need to read this off ?? in the current IPv4 address allocation and assign policies for the RIPE NCC service region, which is currently RIPE 606. The policy proposal itself is RIPE 2014?01. And currently on the website it's still Version 2, but ?? excuse me, it's still version 1, but I have just say send in the Version 2, which also is meant to get rid of the notion of the suballocation minimum size. And the idea behind essentially is to align the policy with the last /8 policy idea behind it because there is no need to have a minimum allocation size on that any longer because the allocation size is fixed at a /22. So, to have a minimum allocation size just doesn't make any sense any longer.
But, keeping the notion or keeping the idea, keeping the concept in the current policy would mean that at least two things are not that easy to happen, one is the transfer of allocations that are smaller than a /22, and also converting PI space into allocated PA space, where the former PI space is smaller than a /22 as well, and this kind of policy change would help to ?? well would essentially allow for the conversion of PI space into allocated PA space as well. And that's pretty much it from my side. I would sort of ?? as I said ?? call it a no?brainer or something like this, it's rather an editorial than a real policy change, because it would help LIRs sitting on PI space to convert this into PA space in particular and also it would help LIRs to transfer PA space smaller than the current minimum allocation size to other LIRs. That's pretty much about. Questions? No, okay.
GERT DOERING: Well just a few words on the mechanics. It was in discussion on the mailing list. There was enough support to go on with some wording changes. It's in the policy machinery to have its Impact Analysis and I think Marco promised that it will be ready tomorrow. So, it will be entering review phase with the Impact Analysis this week or so, and then it's back to the lists to receive some more comments on whether we should do this.
I need a few more comments to actually move forward, even if everybody agrees, yeah, this is fine, please say so.
AUDIENCE SPEAKER: Marco Smith, policy development officer. It's correct that I expect that by tomorrow we are going to publish the Impact Analysis but I can already, even if it's not completely finalised yet, I can say there is no big surprises to be accepted. We see there is a pretty straightforward towards implementation because all the changes that we have to do is just adjust existing procedures towards small allocations sizes and, there is ?? just to also mention maybe a number about the potential of converting smaller PI assignments to PA. We talk around a number of 2,000 to smaller PI assignments.
AUDIENCE SPEAKER: Wilfried Woeber following up on the Impact Analysis. Is the aspect of filtering part of the Impact Analysis? Because, from the old PA blocks, the RIRs had documented the minimum allocation size and this might have found some sort of way into filter lists. As soon as we start to transfer sub blocks from this PA space, you are probably going to see routing announcements which are smaller than this minimum allocation size, which is not a comment against this policy, not at all, but just sort of this might be one of the impacts which is not directly policy related or related to RIPE NCC internal procedures but it might have an impact on the the routing reality.
AUDIENCE SPEAKER: I had a comment but just to respond a bit to Wilfried. Indeed the NCC had several each /8 had it's minimum allocation size, but it all got changed a couple of years ago to /29, so they all got changed quite a few years ago and if people did apply filters ten years ago when the first /8 was, well, whatever, and they should have updated those filters a couple of years ago when the RIPE NCC announced everything to change.
Now, my comments ?? sorry ?? this is Elvis ?? my comments, you are saying that version 11 on the website. Version 2 is not yet there.
SPEAKER: I don't know if you want to comment on that one. Tomorrow.
MARCO SCHMIDT: The second version will be of course published together with the Impact Analysis very likely tomorrow.
AUDIENCE SPEAKER: My question was you said that the Version 2, because we're not talking about Version 2 but we haven't actually seen anything, we are just talking about what your idea of it. Have you done any diff between the two of them?
CARSTEN SCHIEFNER: Yes, I got word that people would feel it to be helpful to also have the suballocation minimum size being abandoned essentially, although I personally only felt it's rather loosely coupled, then I again said okay, if there is strong, a strong position in favour of getting also, getting rid also of the minimum suballocation size so I put that in, that's essentially the only difference.
AUDIENCE SPEAKER: As you had my support for version 1, you have my support for Version 2 as well, but let's see it on the website.
GERT DOERING: Thank you. We are doing perfect on time. Now it's Erik Bais on, I think, PI transfers. That might be a bit more controversial.
ERIK BAIS: I hope not too controversial. Morning everybody, Erik Bais, so ?? in Athens, we, you know, talked about allowing IPv4 PI transfers, and I was the one raising my hand saying well, I want to write one up. So, this is where we stand currently.
After the discussion on the mailing list, it was just a couple of weeks before this RIPE Meeting we decided where will there is still discussion going on, let's extend the discussion phase to include the RIPE Meeting and see what kind of feedback we get, maybe get some for feedback on the mailing list which, because of the other policies that actualliey were announced after that, there was a lot of discussion, but not on this policy unfortunately, so, I hope to get this concluded with the feedback here in the room, and maybe some more on the mailing list, the discussion phase ends on May 23rd.
So, the policy in itself is basically go through the PDP process and basically get the PI space for IPv4 on paragraph with transfer for PA. The reason for that is, you know, there are people that have PI space and actually say well, can we transfer this? I want to buy a certain block from you know, a company that I know. How do we do this? And I have seen actually people using side letters because the process didn't allow to actually transfer PI from one entity to another. And that doesn't help with the accuracy of the registry.
As I said, you know, it still happens. Whether we allow it in the policy as a direct transfer, and this is not something that we will be able to stop. People will basically, you know, they would do an agreement and say, well, you can have exclusive rights to use it, blah, blah, blah. They don't update the WHOIS database. They don't update the registry. It's basically, you know, this is a side letter, you own it but it's still in our name. Those kind of things. And it's something we need to avoid. The registry needs to be accurate, you know, it has different issues if we don't get this sorted out. I'll point out later how the work rounds are and what people are doing to actually get this done. And some of them are not pretty.
And that's actually, if you look at here, which is, I think, some of the most pressing issues within policy where, and also from the feedback that I have heard in talking with people from the RIPE NCC. People lie. They'll lie on whether they use it or how they use it or what the intentions are, what they actually did, is this a merger? Is it an acquisition? Is this a transfer? And did they actually bought it with the infrastructure or not? And as soon as, you know, money is involved, people have a scarce resource, you know, they will lie their teeth out to actually make sure that they'll make sure it gets done. And for policy to actually not allow this, will actually make matters worse instead of solving the issue.
The other thing why we wanted to do this is people don't understand the difference. They have no idea. Well, I have IP space and I can transfer IP space, you know, that's current policy. We say, well, yeah, this is a different colour. Well, they don't understand it. They have no idea what the difference really is between PI space and PA space. And that's also one of the reasons why we ?? during the process that I did with Andrea and Marco, is to get it on paragraph exactly the same as with the PA space.
So, a short recap on the discussion from the mailing list. I think the overall feedback was positive, although there was, through some of the e?mails, people stating, well it's a bit of... yeah ?? envy, if that's the right word to use, people actually got cheap IP space in the past, you know, they only paid â¬50 per year to actually administer it, and they are not contributing to the overall administrative cost of the NCC and now we are allowing them to transfer it and somebody will make big bucks on it and I'm actually going to do some calculations and I'll show you that later in the presentation, but the current ?? and one of the proposals, or the options that they said, you know, how can we actually solve that in in actually forceings people to actually become a member, converted from PI to PA and then being able to transfer it, or you know, at least have that kind of stuff?
So, the actual goal of the resource holder is basically, you know, simple as that, they want to move a resource from A to B, and they want to monetize unused resource. They have it, they have the space, they are not using it, they have somebody else they know from the field or somebody they met online, wherever, and basically, they want to see how can they do this? One of the things is will tell them it's an M and A. That's where the lying to the NCC comes in place. They can set up a new LIR, import the IP space, convert PI to PA, transfer it as PA, and they are done. Especially when the block is big enough and minimum allocation size is not an issue any more. And then you have the last option, which I stated is writing the side letter, and then you know, don't ask, don't tell.
And I don't think that we should approve that we have policies which basically encourage people or that they feel that they need to lie to the NCC to get them to do what they want to do or want to accomplish, the NCC is not the IRS, they are not the police, and there is only one thing that we actually need to keep an eye on and that's, you know, the database must be properly maintained. The registry needs to be updated. That's the only goal that we need to have. With that in mind, I think that's, you know, that should be the reason to actually get this through.
So, for those that missed the discussion on the mailing list, the proposal on the mailing list was not to not allow PI space to be transferred but to force people to actually become a member.
Or at least, you know, contribute at some way in the administrative burden and cost for doing those transfers, because, you know, God forbid, people might actually make some money on it. And this will actually make things worse. In the administrative hassle at the RIPE NCC side because they need to set up an LIR, they need to sign an SSA, you know, the whole process, and bottom line, the resource holder for PI will actually make more money by doing it, let me show you.
If we look at the alternative. Currently it's allowed for PI resource holder to register as an LIR and convert PI to PA. This is basically the process that you need to do.
So the cost is â¬2,000 set up. â¬1,550 yearly maintenance fee. So for â¬3,750 you are done. And this is the catch. Because, the PI holder, not only has let's say a /23 in PI space, now he has a /23 and a /22. Which basically means more money. So, if you look at the current price for IP space and on average you know, let's take â¬8 as a price for IP. This is for a /23, if he would actually directly transfer, this is the typical price, and so he would, you know, make 4,000 bucks. But after import it go to a /23 PI to a new LIR, it becomes a /23 and a /22. So it's possible now that the benefit will be â¬8 times 512 plus 1024. We actually get a more interesting number and this is the way some of the people actually proposed on the mailing list. So, we're actually, you know, increasing the burden, you know, from the administrative side, and for, you know, disallowing people actually you know doing a transfer directly, we actually give them additional funds. I'm sure people will actually find out one way or the other.
And this is the actual difference in that hole between the two. So, we actually ?? you know, instead of â¬4,000, they actually make â¬8,500 in this particular example. And that because the policy does not currently allow direct transfers.
So the goal of the proposal is to actually get PA and PI space on the same track and allow them both to be transferred. We had, in the document you can see that, you know, we actually copied the text within the PA blocks and actually imported them into the PI block in the same policy. And we don't want to make any differences, no different fees or different things, and the reason, and that's the goal where I'm looking forward to actually, once we actually have this, all the colouring differences out of the way, we can actually move into a version where we actually strip out the transfer policy sections and actually go and dump that into a different document. But that's, you know, after ?? so, there is a reason why we want to have this as simplified as possible and have a single set of rules for the transfer to be allowed here.
And I think the last one is probably the best. We need to avoid to work the system or ways that actually encourages that, and we need to have policies that basically where the registry is accurate and that is the goal and that should be the goal to actually get this implemented.
So, there is some time to actually put input on the proposal. Any questions here in the room, and specifically, please state your support on the policy if ?? or questions on the policy on the mailing list.
AUDIENCE SPEAKER: I have a couple of comments on the chat room from ?? and I hope I pronounce it correctly. ISP re a /TPHAOEBG an I B /PWROBG elements limited, and the comments are: If someone doesn't obey the law should we change the law so it fits what people do? This creates a bad precedence. And the second comment: Is there are hijacking of IP space happening, should we also create a policy to allow this since it's already happening?
CARSTEN SCHIEFNER: No.
ERIK BAIS: In this case we need to actually have the policies in place to actually allow this. And hijacking is going on wrong intent. The policy is to make sure we have an accurate registry and the policy will actually allow us to do, to actually be able to do that.
WILIFRIED WOEBER: Just an observation on the topic of working the system. I do not disagree with your assessment that becoming an LIR, getting additional resources would actually provide an opportunity to make more profit. But the observation is obviously that this is autconol to PI address space transfers because following on your line of reasoning, if the cost or if the value per IP address is big enough, we are actually offering an incentive with the /8 policy to sell that with a profit. If anyone is clever enough to seize this business opportunity, they would just install an LIR, get a /22 and sell it off and close it down. It's the same line of argument. It's just an argument.
ERIK BAIS: I don't disagree. I have actually, on the mailing list, I think last year somewhere, I have actually asked on the mailing list if we should disallow merging of LIRs that already have the final /22, or actually disallow transfers for the final /22 if an LIR already has received their /22. So, at that point, on the mailing list, it was considered not an issue, and people do what they do. Let's get rid of it. So, I didn't, you know, proceed in making policy for that, but I did notice the loophole. Yes.
WILIFRIED WOEBER: But we could also think about trying to close that loophole on a more general level by revising the last /8 policy. I don't know, whether of this would have an attraction but just...
ERIK BAIS: It's definitely ?? it's a different discussion than what we're trying to do here, but ?? and I'm more than happy to take that off line, but yes, there are some gaps there.
GERT DOERING: I'm going to actually take up the ball on this one and play to the NCC to ask you to check whether you see sort of like indications of that, not maybe right now, but go through your records. I think that should be pretty obvious, registries being registered, receiving their /22 and transferring it away four weeks later. If you already have numbers or non numbers.
ANDREA CIMA: We are keeping a looking ?? we are looking at this already, concession is that it happens rarely so far, we haven't seen many cases but we have seen cases where an organisation opens multiple LIRs and we have also seen that after a while some of those have been transferred. But it's very limited phenomenon so far but we're keeping an eye on it.
GERT DOERING: Thank you.
SANDER STEFFANN: One thing that always surprises me, if you talk about starting an LIR to sell oft resources, I mean, how can you make a profit on that because the buyer can just start an LIR by themselves. So... anyway...
ERIK BAIS: Do you want an answer on that or was it ??
SANDER STEFFANN: If you have one.
ERIK BAIS: Yes. The thing is, there are some people that are actually, that know better how the policies work, and if a company actually has their own LIR and they have their final /22, they think we're out, we need to go to a broker and at that point, you know, they will find a /22 if that's what they need. And the difference between you know setting it up and selling it, is 37 hundred and 50 euros to set it up and sales price is â¬8,000. You do the math. So it's definitely profitable and it happens.
SANDER STEFFANN: The sales price sounds a bit silly then, but yeah, if that's what people are paying.
ERIK BAIS: That's what it is.
AUDIENCE SPEAKER: I have a number of comments on the chat room.
First is a follow?up comment again from ISP re a /TPHAOEBG assaying that the wrong intent is misusing PI space.
Next I have Randy saying is the goal to have an accurate registry or to prevent people from making money?
And ??
ERIK BAIS: Can I answer on that? Because that's going to be a very easy one. I have stated that multiple times. Accuracy of the database and accuracy of the registry, that's the goal. That's the only goal.
AUDIENCE SPEAKER: Jabber: And the last comment at the moment from James, I think, is that I think we're the only ones within the UK with two /22s from the last /8 but only because we bought another company.
ERIK BAIS: And actually, to give you an indication, I actually know an LIR that has four or five /22s from the final /8 in the same LIR. So, it happens. But then again...
AUDIENCE SPEAKER: Elvis: The /22s that gets set up just for the sell are public.
ERIK BAIS: Yeah.
AUDIENCE SPEAKER: You can just browse through the transfers list and you'll see LIRs that have been set up, transfer the /22 and closed. It has happened. I have seen at least one of those. And I don't think it has taken more than a quarter between the setup of the LIR, because you can actually see in the history of the LIRs, when they were created, when they got the will allocation and when it was sold and when it was closed. I'm not sure if that LIR is closed. I have just seen it that it has happened and people to do it. To respond to Wilfried, I don't understand why people are not doing this more often. I really don't understand why people are not setting up companies for £50 or euros, set up LIRs and then sell their business or the allocation for a 4k profit in a few weeks. And it's weird that it's not really happening a lot, but ??
Now, going back to PI, just asking someone to become an LIR in order to transfer that is inviting them to use loopholes and inviting them to basically ?? teaching people how to use loopholes, and just teaching people oh you can make even more money if you start setting up this on and on. So... I really disagree with the idea that let's just help PI users become an LIR and be part of the registry system, pay your fair, pay your fee, and then you can sell it. On the other hand, we had an offline discussion and I did propose something to you and I don't know if that will make any difference or if it will work in the end. But it wouldn't be a bad idea to actually ask the Working Group, the ones that have raised objections, whether they will keep on raising objections if the policy, maybe a revised version, would say, or would propose a fee for a PA transfer, an NCC fee for a PA transfer. But this would then again not be, according to your plan, having PI and PA on the same road.
ERIK BAIS: Exactly.
AUDIENCE SPEAKER: Those are my comments, I now support your policy proposal. I had some comments about it as well. I now support it fully. I'm just saying that maybe those that were thinking about the financials, now are changing their mind, but if not, maybe in order to get this moving forward and get it accepted, maybe we could just see if they would accept that.
SANDER STEFFANN: Let's not try to second guess reasons of other people. Let's take this to the mailing list.
ERIK BAIS: Right, so, to answer to Elvis, we really wanted to have the policy exactly the same, or as much as the same as we could with the PA and the PI transfer, and I'm not a big fan of actually making policy that would mandate, you know, different charging schemes for different things. I am glad we have the charging mechanisms that we have. And I would like to keep it as simple as possible, because I think that if we have a clear policy also for this and allow direct transfers for PI, you know, it would actually be a minimal administrative burden on the NCC to actually, you know, provide actually cost to it, so... so it would make things easier if we have everything at the same.
GERT DOERING: Yeah, to wrap it up. I think I'm not seeing massive objection, so, we'll go on the mailing list. We should send a reminder to the mailing list that the discussion phase is still open and we need more input on that, more clear guidance. Thank you for bringing up all the details and the possible ways people can wiggle around this and ?? well, I think we agree, we don't want to encourage people to use loopholes. So a clear policy I think it always good. Let's see what the mailing list has to say about it and thanks for bringing it here. And then we'll jump to the next policy proposal:
We are going to eat into the lunch break, but I think it was important to give this enough time for discussion.
Job Snijders ?? we have in the AS number policy we require multi?homing and well, some people think that this is not a useful requirement, and here is the man to present the reasons.
JOB SNIJDERS: Let's start without slides. Currently the policy states that in order to acquire an AS number from RIPE NCC you have to be multihomed and I personally think that's not appropriate reason or method to measure whether somebody should get an AS number or not. The proposed policy text, as it starts today on the mailing list, is in order to get an AS number, you have to have a technical reason that can not be satisfied with either your existing AS number or a private AS number. And this will allow people that might not be multihomed today to get an AS number and start multi?homing in a couple of months or not or they gain mobility in the MPLS free fee context, it is very useful to just assign globally unique numbers to your customers so they can switch providers or start peering with other enterprise customers you are hooking up. But the come to this proposal would be that somebody could start hoarding AS numbers by just going to the RIPE NCC and saying I want and AS number, I want an AS number, I want an action then. Then again there are 4 billion of them. 4 billion. So that's the proposal in a nutshell.
SANDER STEFFANN: You are too fast. It's still not uploaded.
JOB SNIJDERS: I think the multi?homing requirement as it stands today is something of the past that we wanted to make it more complicated for newcomers for unknown reasons.
SANDER STEFFANN: If I am paraphrasing you correctly, basically you are saying there are more technical reasons to have an AS number than multi?homing that we should recognise.
JOB SNIJDERS: Yes.
AUDIENCE SPEAKER:
WILIFRIED WOEBER: Just to use the time I fully support your proposal because I was feeling very, very uncomfortable for years with these funny old artificial requirements. Not just because of the technical reasoning behind it, but also because of the fact that the RIPE NCC was expected to double check and to verify this requirement BIS intrinsically impossible to do from a certain vantage point and secondly the pointing fingers at private AS numbers is just as cumbersome as it has been in the past at RFC 1918 and it has bitten quite a few people. Certainly while you can do some stuff with private AS numbers there is good reasons to use unique AS numbers which are not visible in the DNSSEC.
JOB SNIJDERS: It might be slightly related. I have seen people lie to the RIPE NCC to obtain AS numbers. They just e?mail their current upstream plus a random route collector for instance AS 199036, you can you'll use it to request AS numbers, and to prove, it's multi?homing, there is a BGP session, I can show you the commands. Jan.
JAN ZORZ: I fully support your proposal because I have seen in the past many people actually lying to RIPE NCC to get an AS number, because usually when you build a new network, people is buying the hardware, they are investing lots of money and they usually, at the very beginning, they don't have enough money to buy two or three upstreams, so they connect over one, build the network and try to do something with it. And then usually they do the same thing as you said, they go and lie. They ask somebody ??
JOB SNIJDERS: This is not lying if you peer over a route collector, right? Web.
JAN ZORZ: They go and say maybe we will connect in the future and we can use your contacts as a contact in ?? so I think this was, this should be ?? this must be removed. So, thank you for this proposal.
AUDIENCE SPEAKER: Nick Hilliard, I mostly fully support this proposal.
JOB SNIJDERS: What percentage?
NICK HILLIARD: A hundred percent for ASN 32s, mostly for ASN 16s, but my foot is really sore at the moment so I'm not going to say anything more.
AUDIENCE SPEAKER: Jabber: Another comment from Randy on the chat room. Could you give some examples of other needs forecast numbers other than multi?homing?
JOB SNIJDERS: There is, for instance, a concept in the telco world where they will, they call it peering, but exchange control plane data with each other which is not visible on the Internet but it requires a globally unique AS number to set up the BGP sessions amongst those telcos.
Another use for a globally unique number would be just being present on the Internet, but not yet have decided whether you want to multi?home or not. I think getting multiple vendors to supply you with a service has no correlation with running a service. You don't need to multi?home to be present on the Internet.
AUDIENCE SPEAKER: Full support, first of all. Second, multi?homing, what does it actually stand for? Is it multi?homing to different I numbers? Is it homing to the same I say number? Is it ?? even if connecting to one ISP by various ways, so connecting only to one IS numbers number, might actually require an AS number for yourself. Now, I have seen a lot of requests coming when I was working for the NCC after I ?? before I was working at the NCC, when and after, most of these that I have seen have been for basically independence. You don't want to hang on to only one provider announcing your address space. You might want just for sometimes example you have an AS number announcing it and then that AS number fails, you have someone, a back up that could be enabled within minutes or within seconds to pick up and keep you online. There are tonnes of reasons why someone would want an AS number. As Nick said, 32?bit, go wild. I'm actually wondering why are you saying, why are you proposing in the new policy text to actually put a reasonable technical reason for requesting it, because that would just put a burden on the NCC to actually understand and evaluate what is a reasonable technical reason.
JOB SNIJDERS: Wouldn't the burden be something they would self impose, because another way of viewing the text is just rubberstamp everything that comes in.
AUDIENCE SPEAKER: You are not saying rubberstamp everybody. You are saying you have to provide a very technical reason with the RIPE NCC will have to understand and that the RIPE NCC will have to evaluate and then rubberstamp. So, I really don't understand why you are putting that because it's only adding ?? if you really want rubberstamp, just say rubberstamp, really... that's it... thanks.
AUDIENCE SPEAKER: Dave Wilson, HEAnet. You are looking for examples of problems with the status quo and I'll give you one which is no longer extant but caused me a couple of sleepless nights about a decade ago bus my own network was in a position where we were clearly multihomed, we were peering with many other networks, and we were visible to many other networks, but as far as the commercial world was concerned, non?enrons were concerned, they only had one route to us and therefore as far as one in the neutral position like the RIPE NCC was concerned, getting a BGP feed, it would look like which were single?homed. Tun unambiguously not the case and I'll argue with anyone who says otherwise but that's how it fell out. And that that was perfectly sensible arrangement for us at the time. The problem is those little words, "visible on the Internet." And the Internet looks very different depending on where you stand. I fully support this proposal.
JOB SNIJDERS: Thank you for your comments.
RUDIGER VOLK: Unique AS numbers should be available and they are ?? well, okay, anybody who installs a network of a certain complexity and cannot preclude in advance that he will interconnect with more than one external party quite obviously should have a chance of doing the right thing right from the beginning for current technical constraints, it probably makes a lot of sense to ask that parties that do not currently have specific plans for doing homing, well actually multi?homing is not the right term, the term is multimultiple AS peerings, and that may be peerings to AS that are not visible like Dave was referring to. The 16?bit AS numbers probably should be secured for parties that are short?term doing something with them in the public Internet.
AUDIENCE SPEAKER: Randy Bush, IIJ, first an apology to Laura for carrying my water because the Chair in the other room is better for my back.
Read RFC 1930 on which this discussion is based, whether it knows it or not. The purpose of autonomous systems is connecting to each other and running BGP and all that stuff. If you are going to do that, of course you want an AS number and I wouldn't encourage private AS numbers for most occurrences of that. Although you will see it used widely today, private AS numbers in certain date certainty err architectures.
JOB SNIJDERS: They are cheap, right?
RANDY BUSH: Private AS numbers and in fact they just expanded the space ridiculously. But I'm sure we think 32?bit AS numbers are infinite and we thought every number space sin iPhone ate and we are shepherds of the Internet and the resources, and I just don't really sympathise with randomly rubberstamping and giving them away but I do believe that somebody actually has a technical need for them, of course you give it to them, but every example I have heard here, and which is why I ask give me some examples, was indeed whether you want to call it multi?homing or whatever Rudiger's expression was, you are connecting to two other ?? or two or more other autonomous systems. That's fine. And whether they're visible easily or not, moc nicht.
JOB SNIJDERS: We could go back two slides. I have seen used cases today where private AS numbers are used to ?? are assigned to the CPEs of enterprises that connect to a free layer VPN provider that spread around the globe, and that is a valid case, I think personally, where you're not multi?homing, you only have one provider, but you're recycling a certainly integer across a lot of sites and why would you recycle that integers across multiple customers, you can give them a globally unique integer per customer and never have a conflict.
GERT DOERING: We are fully out of time and we have one more proposal to discuss. So, I'm ?? I'm apologising that I have to close the line here. What we have heard is good feedback and this gives us material to work with. So, what I have heard is strong support on the general idea. Some worries about just rubberstamping but at the same time, having criteria that the NCC actually can evaluate. And also worries about the 16?bit AS number because they are, well, few of them, few of them left. So we might need to work on the text. But that's what the discussion phase is for, to get a general direction which we have received now here and on the list, and we can go forward and work with this. So, thanks for bringing this up. Sorry for cutting short the discussion. I think ?? there would have been many more things to be said here, like reclaiming unused stuff and so on, yadda, yadda, but we are already at lunch time.
I have one more proposal on my agenda and I apologise for that. But it was important to actually use the time. That's Martin Pels. I think this should be a short one, present the idea, gets a few notes from the room and then leave everybody to go to lunch.
MARTIN PELS: I'll be quick, because you're probably hungry and some I, so...
The idea of this is, this was an interesting interaction between two policies, the IPv4 last /8 policy and the IPv6 policy.
So, the last /8 policy says you can get an IPv4 allocation, a /22, if you have an existing IPv6 allocation. Note the word allocation here. And then we have the v6 policy which talks about which we heard earlier, that if you have ?? if you receive a PA allocation like v6 and you have an existing PI assignment, you have to give back the PI assignment if there are no different routing policies.
So now suppose I am an LIR and I request space from the last /8, I happen to have v6 already, I have it deployed but it's in PI assignment, it's not an allocation. So, actually, now I cannot get space from the last /8 IPv4. I have to get a v6 allocation first. So, well, okay, I don't need this, but fine, I'll request it, and then what happens then is I request the v6 allocation and then the RIPE NCC tells me okay, fine, but you don't have a different routing requirement, so you have to give back your PI. So, in order to get v4 space I have re?number all my v6 deployment which seems to me not the desired effect of these policies.
So, the fix for this is that we cooked up with, Aleksi and I, is pretty simple. We changed the requirement for getting space from the last /8 to also include the option of having v6 assignment and not just an allocation.
AUDIENCE SPEAKER: Nick Hilliard. There is a bug. You don't seem to accept IPv6 assignments or allocations from other RIRs. Is that intentional?
MARTIN PELS: We figured that doesn't really matter, because there is no reason to ?? if you have an allocation from another LIR, you can ??
NICK HILLIARD: Not another LIR, another RIR.
MARTIN PELS: Another RIR, you can still get PA from the RIPE NCC without any problems.
NICK HILLIARD: It's just a bit pointless then having an assignment hanging around ??
MARTIN PELS: Yeah, it would be ?? yeah... it would be an allocation that you wouldn't be using, but other than that, no...
AUDIENCE SPEAKER: Hi. Elvis, as already said on the mailing list I don't see the reason why we shouldn't just say if you have IPv6, you get the last /22, because maybe someone will get IPv6 PA from the LIR, an assignment, not the sub al /KAEUGTS allocation, a parks, yeah, they get an assignment, they start using it, they /TOEPBT want to re?number, they become an LIR, they don't need an IPv6 allocation because they are already using something from an LIR from the RIPE NCC but they won't be able to get a last /22, that's why they would have become an LIR. So, I think ?? I support it as it is right now. I think that if you would go back to the drawing board and say any IPv6 in use would be acceptable, I think that will really help a lot.
MARTIN PELS: So that would include saying a tunnel from a random provider?
AUDIENCE SPEAKER: You are using IPv6. I don't know, my point of view is if you are using IPv6, you can get your /22. I mean, you can get your /22 just by sending a line to the RIPE NCC. Why force someone to get that IPv6 allocation?
AUDIENCE SPEAKER: Jabber: I have Aleksi in the chat room here who is the co?author of the proposal and he wanted to make a comment back to Nick. That you did think of the other RIRs before publishing the initial proposal, and you didn't want to make the initial proposal too over complicated.
AUDIENCE SPEAKER: Dmitry. I would disagree with the previous speaker at this mike, I do think that the real LIRs should have a real v6 space from upstream LIR or direct RIPE NCC. I don't think any of the channel space would qualify. I don't think that's in the spirit with ?? well, being an LIR.
GERT DOERING: So, you are supporting this but you are not supporting the change Elvis proposed.
AUDIENCE SPEAKER: Yeah, and maybe we should qualify that upstream LIR means upstream LIR of the Rick or any other RIR, that may be useful just in the text, but I think by default it means upstream LIR of RIPE NCC.
SANDER STEFFANN: Watch out for your definition of LIR, because LIR does not always mean ISP.
AUDIENCE SPEAKER: I am saying here LIRs should probably imply RIPE LIR, not any LIR. That probably should be qualified in the text.
AUDIENCE SPEAKER: Nick Hilliard. Can I just take a step back here and ask area we even mandating that organisations and LIRs have an IPv6 allocation or assignment? This is entirely pointless.
SANDER STEFFANN: I think this was historically meant for educational purposes.
NICK HILLIARD: It's stupid. Can we just like, change the proposal and just remove the requirement altogether. If people are going to use IPv6, they are going to use IPv6. People are going to use IPv4, they are going to use IPv4. But I mean, let's not pretend that putting some codicil in a RIPE policy proposal is going to make any difference, it's not.
MARTIN PELS: Personally Nick, I agree with you, but there have been ??
NICK HILLIARD: Good, so you are going to change it then. Excellent. This is good.
SANDER STEFFANN: I think there is some support in this room for this change.
MARTIN PELS: There has also been suggestions in the other direction that people should send mail to the RIPE NCC from an IPv6 address in order to prove that they are using v6, so I'm not sure if your change would get consensus.
NICK HILLIARD: We have the historical precedent before. Look at the OS I wars. This is entirely pointless. Let's just withdraw the proposal, remove the requirement for IPv6 completely and just let's be done with it. It's much simpler. Simple is good.
GERT DOERING: We need to to technically withdraw this. It's still solving the same problem. This needs to be Version 2.
AUDIENCE SPEAKER: Rudiger: I disagree it's not necessary. On the other hand, it doesn't really hurt, and not using the opportunity to push someone's head at the issue of, well, okay, you should be considering at least v6 seriously, well, okay, not using that opportunity in this place is just also a bad idea. I hate it when I see customers connect right now and ?? well, okay, our administrative procedures seem to force them to give IPv6 data and nevertheless, new customers with new 32?bit ASs show up and they don't do anything in v6 and I find that extremely annoying. And I think down the road they are going to haunt me sometime.
GERT DOERING: Okay. We are well over ten minutes into the lunch break. What I have heard from the room is nobody who wants to keep the old stuff, this is good, this means we go on with this. What I have also heard that there is not full agreement on the specifics. So that usually means take it back to the mailing list and see if sort of like a majority can agree on specific wording, bounce the thing around a few times, and then come up with the final text for Impact Analysis review phase and so on. At this point, it's easy to change the text to whatever it is, or just keep it as it is. Let's ask the mailing list.
Thank you, thank you for standing between everybody and their lunch. Thank you for bearing with me taking away your lunch break, or at least part of it, and thank you for helping shape policy, as usual, thank you, enjoy your lunch.
There is one last announcement, but this is just taking ten seconds.
SANDER STEFFANN: I already, the last RIPE Meeting there was a proposal to unify PA and PI. And I heard rumours that there are people restarting that effort, so there seems to be some interest in it, so, keep an eye on the mailing list, if anything happens, it obviously will show up there. Thank you.
(Lunch break)
