Address Policy Working Group
Second session
RIPE 87
29 November 2023
11 a.m.
LEO VEGODA: If people could take their seats we'll start with the second session, and I will get on stage and just guide you through our agenda.
Thank you for coming back for the second session of Address Policy. We will have a discussion of 2023‑04, which is the proposal for Add AGGREGATED‑BY‑LIR status for IPv4 assignments. And then after that, we will have a discussion on the future of IPv6 policy. We have some proposals coming out of the interim sessions that we held, and so we'll talk about which ones we want to do first in that discussion. And then of course there's the open mic at the end.
But before we get to that, Erik and I wanted to just remind people a little bit about the policy development process because I think there was some discussion on the list which suggested that not everyone is familiar with the process, and the way that it works.
So, there was a suggestion that when a decision has been taken to move from one phase of the policy development process to the next phase, there should be immediately documents published and impact analysis, and so on and so forth.
So, I think things moved a little bis faster in the past and estimation in the past things were a little bit more vague, but we are moving towards more insure processes and that means that sometimes when we move from the initial proposal phase in the PDP to the review phase, it takes a little bit of time. And the reason is that we genuinely have a conversation with the proposers for a policy proposal and say, do you want to move it forward? And we make an agreement on what's going to happen next. And that's when the work starts on preparing those documents and putting together that impact analysis. Putting together the draft document, even if it's not much text, that doesn't mean that it can be done in half an hour.
Firstly, you have got to think through very carefully what it is that you want the text to say and how other people will interpret it, and the RIPE NCC very kindly helps with the development of that text to make sure that the text does mean what everyone wants it to mean.
And then for the impact analysis, Angela, I believe it is, goes to each of the groups within the RIPE NCC and says, how will this impact what it is that you do? And all of that goes to the Board and the Board considers that impact analysis, and that then comes back as the document that is published on the website.
If we were to have that ready at the instant that we communicated the decision to move from the first phase to the review phase, that would suggest that we had already done that work in the background, and that would either mean that the RIPE NCC and the proposers were putting in a lot of work that might not be necessary, which would be wasteful, or it would suggest that maybe we weren't really properly listening to the community. So, we know that there is a gap between these two things. It's not necessarily a bad thing. It's an opportunity for significant reflection by the proposers and by the RIPE NCC on what this proposal would mean, and that's why it takes a little bit of time.
So, that is the first item on our agenda. At this point, I think I have hopefully made that clear, and I'd like to hand over to Jeroen and he will be here in the room, Tore will be joining us by video I believe. Thank you very much for volunteering to put this proposal together with Tore.
JEROEN LAUWERS: Good morning everyone. Tore is on the screen and we would like to give an update about our policy proposal we want to introduce the AGGREGATED‑BY‑LIR in the IPv4 poles. I want to first start with a little recap from our proposal, to show what the proposal is about.
And after that we want to talk quick about previous phases and what we did so far.
The last point we want to go talking about the review phase in the impact analysis, and then lastly is some space for discussion.
So, Tore and I tried to introduce the IPv6 aggregate by LIR status in the IPv4 policy. It would allow registering multiple assignments with identical purpose and contact datasets as a single aggregated assignment as an inetnum object. The primary goals are to improve assignment coverage in the database, to reduce the work for the LIR, and to improve the alignment for IPv4 and IPv6 policies.
So, at 4 September, 2023, we made the official proposal. Then a discussion phase started immediately. That ended on 27th October. We proceeded to the review phase in order to get an impact analysis that we got at 21 November.
So, in the discussion phase we mostly received positive feedback. But there were some concerns that this policy change would indirectly modify contact registration requirements. So, after this discussion phase, we discussed about it and we decided to go to the review phase in order to get the impact analysis for more clear result about the RIPE NCC, if it definitely would change it or not. And then we asked the RIPE NCC to pay extra attention on this to the registration requirements.
So the impact analysis said so far that the RIPE NCC does not anticipate any significant changes or impact in the address and Internet number resources and the consumption, the fragmentation aggression and the registration services.
I would now let it go to Tore.
TORE ANDERSON: Thank you. As for ‑‑ I would also like to add that for engineering the documentation and training material, there is ‑‑ the report does small impact and low impact. There is stuff that needs to be updated like some code and the database schema, but it's probably mostly copy and pasting of the stuff that's already there for IPv6.
So for the legal impact, that's also now no significant impact expected but there is some kind of an important reminder that the legal department put in there that I hadn't thought about up until I read that, and that is that LIRs can't put the personal data of the end user into the database without obtaining their consent first. And that even goes for the staff of the LIR themselves. So, you know, self made assignments. And this obviously follows from the GDPR Article 6 which says that you need to obtain consent. This means that if you make an assignment to a customer, and you told the customer's contact person that I'm going to add you to the RIPE Database as Admin C since you were present at the site where this network is located, then if that contact person says, you know what, I don't consent to this, I'm already receiving more IP transit offers than I can stomach, please I don't want any more. Then you are not allowed to put that in the database, that's against the personal conditions and it's also again EU law.
So this is not really relevant for this proposal, because this proposal doesn't change the terms around conditions of the database, and it does not change the GDPR obviously, but I think it's an important thing to keep in mind when we are discussing this broader topic of changing a ‑‑ possibly changing the contact registration requirements in the policy.
So, next slide. So, as Jeroen mentioned, we asked the RIPE NCC to pay extra attention and double‑check if there was any impact on the contact registration requirements currently in the policy, if there would be any change. And of course, that was not our goal in this proposal to change anything here, and we got the feedback through the impact analysis, and also from Angela who elaborated on that on the mailing list afterwards that the proposal would not change the contact registration requirements. So whatever you can do after this proposal passes, or fails for that matter, you can already do today.
So, we hope that this dispels the concern that this proposal will make any changes in working through the policy and how LIRs are obligated to register contacts in the database. However, there is a follow‑up question there, and that is like what if the RIPE NCC, as of right now, misinterpreting the policy? As in that I should have been enforcing the requirements on the LIRs differently here? And that's maybe, maybe not. It's not really for us to say. It's not something that we, as proposers of this policy proposal, authors of this policy proposal have any opinion on. We are saying that this is something that's a broader discussion that touches on possibly more than IPv4 policy. And if the community wants to change the contact registration requirements, which we are well within our rights to do if we so want, then we would need to run a PDP on that and have a policy proposal that can assess we want the RIPE NCC to do it this way, and then we can make an opinion and possibly gain consensus on making the RIPE NCC change their procedures.
But that's not this proposal. This proposal is about something else.
So, we hope that we can kind of keep those two issues separate.
And I also wanted to add at the end, which is something that we actually forgot to add a slide about, and Angela mentioned, that the main difference between AGGREGATED‑BY‑ LIR for IPv4, the one that we are proposing and the one that is already in IPv6, is that we are making the assignment size variable for attributes optional; whereas in IPv6 it's mandatory. And the reason why we did this change is that there are some properties in the IPv6 policy that kind of independently justifies the mandatoriness of this attribute that does not exist in IPv4. For example, in the IPv6 the assignment slice attribute is used to calculate the HTH, its variable that goes into the calculation of the HTH ratio and that is in turn used to justify additional allocations if the LIR requests that. But in IPv4 policy there is no ratio and there is no additional allocations so it doesn't make any sense in that regard.
And also, in the IPv6 policy, there is a cut‑off point at /48 that if the LIR wants to make an assignment that is bigger than a /48, it needs to actually submit text or at least gather extra documentation and possibly submit it to the NCC on an audit, and for that reason you cannot aggregate an assignment larger than /48. So I don't know if the database will actually reject the creation of an AGGREGATED‑BY‑LIR object larger than /48 in IPv6, or if it accepts it and you can expect a phone call from the registration department asking what you are doing here.
But in any case, there is no such cut‑off in IPv4. LIRs can assign a slash assignments as they want without any documentation required. So this doesn't have an equivalent thing in IPv4 either.
Finally, in IPv4, as you all know, it's scarce, so you can't do this, or it doesn't make sense to do it this one‑size‑fits‑all type of approach to making assignments that we can do in IPv6. So, because you really want to right size the assignments that you make to your customers to that you save as much as you can and as much per customers that you can possibly fit in your allocation. So those are the kind of differences between the IPv6 policy and the IPv4 policy that ‑‑ making it so that there is actually no independent justification for making this attribute mandatory before that we are aware of. As a final note, there is a technical difference as well, and that is that in IPv4 assignments don't have to be side ro aligned. So you can assign, say, ten addresses, a bunch of ten addresses to your customer and in IPv6 the assignment size variable is a side row prefix length, whereas if you did the same in IPv4, you can't capture an underlined assignment into an aggregated object. So then you have to ask yourself if you are going to change the semantics and say that in IPv4 it's a count, IP address count, and in IPv6 it's a prefix size, or not. And it's kind of a technical thing that we thought it was just best to let go, since of course we didn't see this independent justification for keeping it mandatory in IPv4.
So, that was the end, and I can move to the next slide I guess.
So, final word I would like remind a bit about what Angela also said before the break, that comments, good or bad, from the discussion phase, and also comments in the room right now are not counted as far as calling for the consensus is concerned, so if you have an opinion on this proposal, then please send it to the mailing list, good or bad, and make your voice heard that way. So thank you. That was it.
(Applause)
ERIK BAIS: Any questions? Do we have questions online?
LEO VEGODA: Nothing online
GERT DÖRING: Thanks, Tore, for the summary, and good to see you again. I'm not going to comment on the actual content of the proposal. I do have an opinion. I have voiced it. But then at this point in time I refrain because of, for some reason people seem to think I have more say in policy than I should have. But what we need to really do is very, very carefully look at the arguments that have been brought forward on the mailing list and actually answer it to them explicitly, because the PDP requires us to do so. So whether we agree or not with everything is not fundamental but objections need to be properly fully addressed, and I think half the reason why there is upset on the mailing list is because people feel that objections have not been really answered to, even if we do not agree with them, it needs to be answered. And I think that needs to be one of the next steps. Really go back and read up and see what to do about it. And if the outcome is we actually need to sort out Admin C and tech see definitions first and then come back to this proposal, that is one of the possible outcomes I can say.
TORE ANDERSON: What I can say about the Admin C and Tech C is that in the proposal, and of course I canned send this to the list as well, in the proposal it says that throughout the aggregated assignment, the contact information must be consistent.
So, if we kind of accept that current policy, assess that an assignment in Rome and an assignment in Milan cannot possibly have the same Admin C because they are in two different locations and they need local stuff in each location could be registered in those two unaggregated assignments, then according to the proposal as in the policy text that we are proposing, those two assignments cannot be aggregated because they don't have a consistent contact details throughout the assignment, the aggregated assignment. So I can point that out on the list as well.
GERT DÖRING: This is technically correct. But then if you follow that line of argument, it sort of makes your proposal obsolete because if you investigate stuff and you are technically required to have different admin C's and you cannot aggregate, then the question is why do this in the first place?
I agree with you, but it's a bit more complicated.
TORE ANDERSON: Yes, but to add to that, is that this procedure that you accept this definition of Admin C as being a policy mandate and if you accept that definition of Admin C as being mandated in the policy, then that that has implications for more than the IPv4 policy, it has implications for the IPv6 policy where AGGREGATED‑BY‑LIR is also already a fact. Aditionally, this definition of Admin C has to do with the location of the assignment, and if you think in some cases for example like our managed data centre provider you can have multiple customers in the same location and none of the customers have actually access to that location, only the data centre provider/LIR has access to that location, and in that case, which happens to be the situation I am in, then it would be appropriate to put the LIRs that were corporation staff as the Admin C for the customer assignments, because only the LIR has physical access to the location, and in that case you can aggregate. And there is also the case of assignments made to personal individuals. There is an expressed permission to replace the contact information with the LIR. So those could be aggregated as well.
ANGELA DALL'ARA: Thank you, Tore and thank you Jeroen for the introduction of your proposal. I just wanted to correct one thing that the latest modification of the policy, it is the limitation of assigning a /48 is not so strict any more because there was a correction that it requires now to keep records of the reasons why a larger assignment is given to a single site in case of an audit. So in case the utilisation of an IPv6 allocation has to be checked for the request of a subsequent allocation, you do not need to request our approval to assign a larger. So, for example, you could have an assignment size that is larger than 48, but in case of an audit you have to justify to give the reason why this assignment for each end site is necessary. Just a clarification.
TORE ANDERSON: Thank you.
ERIK BAIS: Thank you. We have Elvis online.
ELVIS : I just wanted to say that in IPv6 the AGGREGATED‑BY‑LIR has an assignment size because it was made that way. It was made to basically aggregate a bunch of similar assignments into one large object. And that's also pause in IPv6, you no longer collect connect one customer with one IP address you make an assignment of up to a /48 to a customer with no questions asked. So, the AGGREGATED‑BY‑LIR in IPv6 makes sense when you make a lot of assignments that have basically the same size and maybe even the same designation, like these are my customers for DSL or for fiber or stuff like that.
When you want to aggregate by LIR in IPv4 and then also remove your assignment size, I don't know ‑‑ I no longer see why you are creating that aggression and not just an object that's called an assignment? What's the difference between an assignment of a /24 where you say in the description these are all my customers of various sizes and, or you make an object with a different status AGGREGATED‑BY‑LIR? I don't see the purpose of it any more.
TORE ANDERSON: Well, the thing is that you're not allowed to make an assignment to multiple customers, either in IPv4 nor in IPv6. In IPv4, there is one narrow exception and that is if all of the assignments in that ‑‑ in individual assignments, in that aggregated assignment is used only for connecting to the ISP. So if it's point‑to‑point in the example that's given, if it's used for something else, then you can't use this exception. And so, so this is in order to differentiate between an assignment to a specific customer or an assignment of point‑to‑point linking, as opposed to a multiple assignment to multiple customers that could, for example, have in a data centre, then it is necessary to ‑‑ you could also, of course, have expanded what is permissible by the assigned PA status, but since the AGGREGATED‑BY‑LIR status is already present in the IPv6 policy, it kind of works, it's tried and true, then we're thinking that it makes more sense to bring parity between the two policies in this way and having the same thing in both places.
LEO VEGODA: Okay, I am going to read out a comment from Peter Hessler from Globalways GmbH.
"In the IPv4 version of AGGREGATED‑BY‑LIR, if one was to use assignment size attribute, would that refer to the number of addresses assigned or to a cider size?"
TORE ANDERSON: I guess that's undefined, not mentioned by the proposal at all. The RIPE NCC has its impact analysis has said that it would make the assignment size attribute optional. So, LIRs could use it if they want. But the definition has not been mentioned if it is a number of addresses or if it's the prefix length, so I guess that question would go to Angela maybe if she actually knows what the answer is, or if not, I guess we would just have to wait and see how the implementation actually ends up.
ANGELA DALL'ARA: I think that this is also open to what eventually is decided by the community, the syntax for the assignment size is just the number referring to the sub‑net in IPv6 that is distributed to each assignment in the AGGREGATED‑BY‑LIR, but I think that this can be changed if so decided for IPv4.
LEO VEGODA: And I have another comment, this one from Brian Story from GAMA.
"Hi, Tore and Jeroen. Thanks for your all efforts in putting this proposal together. I can see the reasons and objectives you are trying to achieve. One aspect I don't quite follow is the optional aspect of PA assignment registration versus aggregated, and how we can approach this in a consistent fashion between LIRs. Is there an expectation of consistency of approach or just down to how each decides to consume the policy?"
TORE ANDERSON: Well, yes, it's up to the LIR. We do not have a use of this new status is in no way mandatory. Just like it's not mandatory in IPv6. So, if you want, if you are an LIR you can still register every single assignment individually, just like you have been doing so far, if that's what you prefer. And you can, of course, include in those assignments any amount of contact information or other optional attributes that you would like to put in there.
So, if you are an LIR, you can completely ignore this proposal after it passes, you can just keep doing what you are already doing. However, if you want to aggregate a bunch of assignments that are ‑‑ that have.the same purpose and the same contact information, and you feel that will actually be convenient for me because maybe I am already doing it in IPv6 and it's convenient there and I'd like to do it in the same way in IPv4, then you can do that. So yes, I guess it's up to the LIR if they want to use this new status or not.
ERIK BAIS: Okay. I would like to thank everybody for participating in the discussion here in the room. We need, due to agenda constraints and time, move this back to the mailing list. Do send your comments, questions, and support or opposition and statements to the mailing list, and I would like to thank Jeroen and Tore for their presentation time. Thanks.
(Applause)
LEO VEGODA: So, this is me introducing a discussion rather than me making a presentation. So, just so everyone who wasn't in attendance knows, during the break between the last RIPE meeting and this RIPE meeting, we had a couple of interim sessions and they are recorded and there are minutes online, and we had discussions about which aspects of IPv6 policy really needs some improvement. Now we have some proper proposals, and we can probably only handle one of these at a time. So part of what we want to do in this next bit is we want to get your feedback on where should we focus first? And then also, what is the scope for a proposal. We could do something that is a little bit grander or we could do something that's simple and then we can improve on it at a later date.
So, I know we have people who would like to speak. So, I'm going to get out of the way now. But I just wanted to make sure that we had some context so that people aren't surprised as to what is happening and why.
Which of you wants to speak first? ?
JAN ZORZ: Can you pull up the presentation from before? So, we have been discussing this at the interim Address Policy Working Group call and we figured out that simplification of things may make everybody happy. So, here it goes.
Why are we doing/29? I know I'm ‑‑ me and mark were responsible to go from is /32 to /29, but back in the time that was because the reservation was /29 from /32, and this is a little bit ticking to everybody's OCD a little bit. Why /29? Why don't we keep it simple and go to the enable boundary of /28, right? And we think that the LIRs that meet the initial Chris are eligible to receive an initial allocation of /28, no additional documentation needed, we think that keeping the allocations to a Nibble boundary is much simpler than the current way of allocating IPv6 space. And also we would like to make sure that we distribute down the tree comfortably enough space, so people can make their addressing plans as they wish. And if LIR needs more space, next possible size is /24,/20, /16 and so on. And we know that the RIPE NCC is reserving the space for possible later extensions, so in this case it should be /24 for everybody. And all current /32 and /29 allocations probably can't be extended to /24 in case of additional allocation, but majority of /29s could probably extend it to /28 and for those who can't, you should probably, if you want /28, you should probably return your space and get one continuous allocation. And that's from my side.
SANDER STEFFANN: So, I know this room is full with people who love MAT and love the HD ratio and all that involves, but just in case you don't, this actually provides some extra simplification, because instead of having an HD ratio, we do have a table in the back that says what exactly the numbers are. The table would get a lot shorter if we just do nibble boundaries, would you end up with a table like you can see here.
If you have at least one end site to connect, you can get a /28. If you are more than 2,97,152 /48s, you could get a /24.
Now, the thing is, like, when I was learning about physics, like the more digits you specified, like the more accurate your whole analysis becomes because you have to check everything to X decimals behind the comma. So maybe this is not the best idea.
So, we could also just make it simpler: Use nice round numbers, powers of 2, don't be too precise. If somebody has 1.99 million end sites, that rounds to 2, don't make it too complicated. We could actually put it like this and make the numbers understandable and easy to read.
Now, from TTL, from this we had some people ask but we still have like 48s, 56s, what do we ‑‑ how do you count them if you have a combination like you give your business customers one and your home customers another? So we could even stop talking about prefix sizes and say okay, how many end indicts do you have? And just not even care about what size you give and this would actually be an incentive to just give everybody a /48 because you are getting the space anyway, if you want.
So, these are all just ideas that we have been have been discussing, and we were like nibble boundaries make it all nice to read the addresses, one nibble, one character in hexa decimal, that we can simplify the HD ratio and just put some nice round numbers in there. We could go even further. So what we're interested in is to see, okay, how, how does this community view this? How far would you like to go?
.
So, there will be some questions. I am giving it to you very shortly. So, we have these steps like where do we want to end, where do we ‑‑ what is too far, and that is actually the bit that Gert wants to talk about, because especially this one, do we actually want to stop this thing between what sizes you give
GERT DÖRING: So I got volunteered into this. These people keep ambushing me and asking me stuff and I said no, no, no, don't go there, and then they say okay you go on stage and explain why not.
So, fast forward back 20 years. We had an IPv6 policy that says every customer gets a 48. And then Geoff Huston did some math and said, maybe not. If you really do this with aggregation process all the way, everybody gives out 48, every provider gets a huge block, people have multiple ISP accounts, we might actually run out of v6. Geoff does the MAT, I am not so good at MAT, so we said yeah, maybe there is some point to it and this is why the policy was changed to give the ISPs the freedom to assign whatever they want up to a 48 to their customers.
So if you want 48s, you can do this today, but the policy is sort of nudges you to do 56s.
And most broadband ISPs seem to do 56s today, and that brings complications in dealing with the NCC of course. Because what do you mean with how many 56s have I given to my customers? I gave out 48s. What do you mean how many 56s? I give out 52s, I have not given out a single 56, so is my block full or not?
.
The policy is actually clear on that, so if you give out a 48 it counts as 256 56s given out, but maybe it's still not so clear.
I think we should maintain the difference giving people ‑‑ giving ISPs the option to assign 48s if they think that's a reasonable thing or 56s. But that, of course, means we cannot just count customers, because if you do customer counting, you either have too much space or too little space, depending on what you give out.
Jan wanted easy and just count customers which of course makes dealing with the NCC much easier.
I think the math doesn't really permit us. So, I would opt for saying with the 56s and maybe reword to make very clear that you can do 48s, and then for the purpose of could you think things, a 48 means 256, 56s. Done, math. And keep these two tables there like this.
JAN ZORZ: We should ask for feedback from the community.
SANDER STEFFANN: As you can see, this is a topic for discussion. Like, even we cannot agree. We need your help.
ERIK BAIS: So. Before ‑‑ because I don't see anybody at the mic, I'll post a question here.
Could you go one slide back?
So, what happens if an ISP does request an initial allocation for a 27 or a 26? They have the customers on that side ‑‑
JAN ZORZ: No.
ERIK BAIS: Why would you, at that point, because that falls within the reservation up to a 24, they still can grow, why would you not?
JAN ZORZ: Nibble boundary.
ERIK BAIS: Okay.
AUDIENCE SPEAKER: Jordi Palet. First of all, I agree with this proposal, and of course as many can guess, I will go for this one, so not could you think the size of the prefix but number of websites. I don't agree with the maths done by Geoff, but that's a different discussion, we can stay forever with that discussion.
However, I am not sure if you want to close this before going to the discussion of other possible proposals. Or already go on ‑‑
ERIK BAIS: So this was one of the topics we'd like to discuss. There are other options that we would like to discuss during this session. They just had a couple of slides to make it clear what their position was. This is not a decision at this moment on which one now. The idea for the Chairs is to get a feel out of the room which of the topics that we want to talk about is going to be most interesting for the Working Group, work on that first, and then, you know, so that we stage the different topics, because there are multiple topics that we would like to address.
So this is one. And I know Tobias has one and I am very sure you have topics as well.
GERT DÖRING: If I may inject a bit of math in between. I did some rough calculations on allocation sizes yesterday, and given the amount of v6 space we have, given the amount of regional registries, we have some leeway here and there, we can afford to give every LIR a 24 just fine. We can barely afford to give every LIR a 22. We cannot afford to give every LIR 20, because there is not enough space. So, be careful where we are going. 28 is easy. 24 is okay. 20 is not. By default.
ERIK BAIS: So I'll start with Raymond. We have Peter online after that.
AUDIENCE SPEAKER: Raymond Jetten, again as a provider. I like this very much, thank you for doing it. But I was expecting the next slide where SRv6 is taken into account. Thank you.
ERIK BAIS: Can we put Peter online?
PETER HESSLER: I, one, very much like the concept of nibble boundaries, it makes life much easier from the operational perspective and trying to allocate things. I don't have a strong opinion on the HD ratio versus /56 and /number of end sites, except for I do think we need, whatever we end up with, has to involve the size of the network we're giving out to the end customer. If I gave every end customer a /40, or if I give every end site a /40, then I will burn through my allocation extremely quickly. Whereas if I gave out a /56, then this allocation will last for quite a long time. I think that needs to be part of the justification for getting more or a larger address space.
ERIK BAIS: Thank you, Peter.
AUDIENCE SPEAKER: Jordi Palet: So, there is a very big difference between the way RIPE and the rest of the regions work, and I think that means that it's really, really, really difficult to believe that something like this could work, at least at the moment, in other regions, because in other regions you pay the membership based on the size of the address, and here it's not the case. So I don't think the situation where we can afford a /20 for every LIR in the world is not a problem in that sense, because I really think it's not going to happen that all the regions will work the same
GERT DÖRING: I am just talking about RIPE.
JORDI PALET: Or you are just talking about RIPE?
GERT DÖRING: I was doing the number of LIRs in the RIPE region and how many bits do I need for that and play around with that.
JORDI PALET: But RIPE can go to IANA and request additional /11 ‑‑
GERT DÖRING: No, that was based on RIPE getting a /6 from IANA, how much space do we have in there and there is only so many /6s, so it was really like ‑‑
JORDI PALET: But ‑‑ /3s in IPv6 as well.
GERT DÖRING: But staying inside the first 001, this is what we can do. If we have to go to a next form of prefix, then the discussion is much larger.
JORDI PALET: But it's not a real problem. You can have seven additional /3s.
GERT DÖRING: Getting the IETF to agree on anything is a problem.
ERIK BAIS: So we do need to keep this discussion short because we have two others that we need to discuss, and time is of the essence here.
LEO VEGODA: So, Leo, speaking personally and based on my experience working in the IANA team, there are 512 /12s in the current /3, that essentially means we could give every RIR a /12 every year for a century. So, I mean, I'm not taking a position on what we ought to do, but in answer to your question, how many /12s do we have? That's basically the answer. We could give every RIR a /12 for a century. I don't think we could realistically do that without the Internet melting, but, you know...
AUDIENCE SPEAKER: Or bans a, speaking for myself. I really like the idea of the nibble boundary, but I would like to point out that I think that ISPs and other networks and network designers, like the best practices when it comes to giving IPv6 to end customers, for example Magenta in Austria, gives a /60, if I'm not mistaken and would I like to take that, if you are giving at least a /56 or giving a /48 into account in this, so we do encourage good practices of IP allocation in the sense of giving a reasonable amount to a customer to like ‑‑ that goes together with let's say IPv6 philosophy of what should an end customer get. Thank you.
SANDER STEFFANN: So, there is two bits to that one. There is like the policy shouldn't limit the ISPs in doing the right thing. And I think the BCOP Task Force also has a big part in educating. I think there are two sides to that.
AUDIENCE SPEAKER: Sorry, just to follow‑up, I don't want ISPs to do the wrong thing. And just like because I do see that some would go like they already don't have ‑‑ like we have a policy that you can give more /48s or reserve more space for let's say business customers and so on. That is not followed. Like, at a certain company that I know that I do design IP space for ISPs, they don't even know that this exists from RIPE that may be giving extra space exists. So I'm just going for this that, you know ‑‑ yeah, look into this because I think some would be like yeah, we'll give ‑‑ the same we had at the beginning, giving /64s and they are just wrong. So, encourage that ‑‑
ERIK BAIS: We'll have a complete discussion at the mailing list on this topic. Don't worry. I need to cut you guys short. Well not short. But we do have some other proposals that we need to discuss as well.
JAN ZORZ: I think we got pretty clear feedback from the community that we need to work on this.
ERIK BAIS: We'll decide later after the other options which one we'll take to start with.
LEO VEGODA: I have three comments to read out and they are just comments, so they'll be quick.
Elvis says: "I love your new HD ratio, it looks perfectly, simple and clear." Followed by Rob Evans from Jisk. "No every ISP is a domestic broadband provider. Some provide connectivity to large multi‑campus educational institutions and one end site/customer might need more than a /48." And Elvis then responded "when it comes to customers that need more than a /48 per site, there is the tool of the sub‑allocation."
ERIK BAIS: As I said more discussions on the mailing list later. Thank you. To be eye as can you pitch yours quickly.
SPEAKER: I can be quick. So, my personal issue is PI allocation policy, or assignment policy. The issue you are facing is that it's close to impossible to get anything bigger than a /48, that is mostly rooted in the somewhat unclear of the end site. What I would propose is to do similar as proposed previously go to a nibble boundaries for IPv4, sharpen the definition of the end site to make it more clear that, well, what an end site is and how many you have. And also introduce strong suggestion to do continuous allocations, so if you have two end sites, hence qualify for at least a /47, you get the next nibble boundary. And you get that within a single prefix because what I have seen in the past is that if you qualify for more than one /48 you actually do get multiple /48s with their own reservations etc., causing fragmentation. That's basically it. Making PI a little more tractable, a little bit more feasible.
Short and done.
ERIK BAIS: Thank you. That was quick. Jordi?
JORDI PALET: Two years ago I presented the Chairs a policy proposal to review all the IPv6 policy, and I was told at the time that, wait, because we are going to have some discussion and, in fact, we had sometime after the interim sessions. After the interim sessions, I waited a little bit, I was already working on reviewing that policy proposal that was never published, and also asked in the Working Group in the mailing list for other people that were going to participate. Actually I got three people willing to participate. Only two of them responded to my mails. It was rinse and Tobias. We prepared an updated review of all the policy proposal, I think basically the policy proposal was looking for some original needs, that's the easy parts ‑‑ well not always so easy. The PI thing, very, very close to who Tobias already explained, and also the allocation based on already rinse mentioned I think it was this morning his problems to get an allocation, and I got the same feedback from other people in the community. So we were working in basically, let's say, three main ideas, which were covering all the points discussed in the interim sessions. So we had changing the allocation, he's easy and subsequent, change the PI and of course removing the HD ratio. We were not looking into the same that was presented before by Jan, Sander and Gert. We were looking into something different. I ‑‑ basically it was their idea, I think it's a very good one. Our perspective at that time was looking for the same as IANA has towards the registers, which is utilisation, 50% utilisation, you get more space. Okay.
We were also looking into nibble boundary, so in that perspective, it was the same, but we were not fixing how many sites or how many assignments for each step in the nibble boundary.
My complaint here, basically, is I think the proposals that we have already submitted should have been published. I agree that the Chairs suggested that a single proposal for everything is too complex to discuss, etc. Fine. So we split the proposal in three parts and actually submitted two of them. One was the allocation part and the other one was the PI part. And then we decided the rest, which is more literal, will come at the end.
I am fine which order we work on, but I think the point is that according to the PDP, if somebody submits a proposal, it should go through. And it didn't happen.
So I hope this discussion gets again towards the correct utilisation of the PDP and we have those proposals published. I understand that maybe discussing the three proposals exactly at the same time is not good. It's too complex for many people, everybody has his own job, but I suggest that we should decide which order, which priority we want for allocation first or PI first for example, and then probably stage a little bit the proposals. So one proposal starts the second phase, the discussion phase or whatever, we start then the following one because we understand that the initial discussion is always more ‑‑ let's say, faster, more heated and then we go down with less and less inputs in the mailing list.
ERIK BAIS: So, as, you know, within Address Policy, we encourage people to have the discussion and the feeling with the Working Group at the meeting here. This is also why we have structured it this way and we have asked you not to submit, you know, a full proposal with all the changes. It is also to prioritise what is most important for the Working Group to initially start with, and based on that, moving forward.
So this is basically what, at the end of this session, I would like to get from the room, which of the parts does the Working Group feel let's start with this, and then as Jordi also suggested, that's also the intention from the Chairs, you know, do the other parts a couple of weeks later so that it doesn't collide with each other and have discussions mixed so that we can either do this one or that one first. I have a personal thing, my suggestion would be to start with the proposal from Sander, Gert and Jan. It just makes most sense I think at this point. But I would really like to get the feedback from the room, whether we start with the one from Tobias or the other one, and take it from there and then basically go ‑‑ see what's ‑‑ that's when your ‑‑
JORDI PALET: But my point here is that I don't think the PDP is being followed. For example, if you remember the previous session, Marco presented something about the ASN and exactly 28th October of 2020, I submitted a proposal to solve those problems. And I am still waiting for your confirmation because you told me no, no, no, we are not going to set up this proposal at this time, we will discuss in the mailing list and what I suggested also when you said that one single proposal for resolving all this was too much, I said okay, let's go to discuss this in the mailing list and it was not discussed in the mailing list. And also, when I saw the last change in the agenda in this slot because one month and a half ago I asked for a slot for presentation the proposal before going into formal proposal I was said no, we don't have enough time. And also, two days ago when I saw in the agenda the last change I asked Leo, should I prepare some slides? No, no, no, we are not going to use the slides but we have got the slides from another group. And again I agree with what they are proposing, but I don't think this is being done in a fair way.
ERIK BAIS: Okay.
GERT DÖRING: You wanted feedback in which order to start. I think we should start with Tobias' proposal because simplification is good, fine, but Tobias has real issues to solve.
On the people that could not get big blocks under the current policy, I think that's an operational procedural problem that needs to be looked into, but the current policy does permit big allocations, and if you have the customer numbers, and if you have the documentation and the NCC is being disturb on, this needs to be looked into because I think there is a procedural problem not a policy problem. So what Jan volunteered me into proposing is good, but Tobias seems to be more urgent.
PETER KOCH: Maybe I'm confused, but I think we clarified at a previous occasion that the PDP is a vehicle for the community to formalise a discussion after there is at least a certain understanding of a problem statement. To that extent, the community looks for to actually do the work. My understanding was that we did not develop the PDP and use the PDP as an entry ticket to a discussion, and also that the PDP should not be used to surprise the community with ideas whether or not they might be right that's something, so there is a conversation first, and then we conclude, there is maybe something to do and then we start the PP D P. To that extent I would support the judgement of the Chairs as presented so far. Thanks.
ERIK BAIS: So, Peter, to answer on that. You're right, this is not the IETF where the process starts with submitting a document. The process starts with a problem statement in the Working Group actually acknowledging this needs to be addressed, and then it could end up in starting off the PDP with an actual proposal. Thank you.
JORDI PALET: And that's why we had the interim sessions. So, I think we follow the process in that sense. The point here is that rinse and myself already submitted a proposal for the PI as well, so now you have a problem, which one you choose, because it's two different proposals actually not too much different because Tobias started working with them and they started to go on their own. If we follow the PDP and when you get a proposal you don't publish it you don't have this problem, now you have a problem of which one you choose.
TOBIAS: I would not make a suggestion towards what we start with but what we stop with. I would suggest we stop with the suggestion on following the PDP, not following the PDP and things about the process also going into the context of tonne numb questions. Instead I would argue that we should focus on bringing policy forward and making a positive change for the RIPE community.
LEO VEGODA: I have a comment from Peter Hessler from Globalways GmbH. "I like the proposed schedule of working through the proposals. I have no strong feelings on which order for the proposals. I trust the proposer and the Working Group Chairs for scheduling them. That all being said, I would like to see a short summary of what is incoming."
ERIK BAIS: Thank you.
AUDIENCE SPEAKER: Rinse speaking from Delta Fiber. I agree with your proposal going for nibble boundary, so I fully agree with would solve a lot of problems I had in the a previous request for larger block space, so ‑‑ but also I, together with the majority about the proposal to enlarge the initial allocation size to 28, and also refresh for 24 of the discussion about if you go, reserve a /24 why don't you hand out initially is /24 because you do reserve it so you can't do anything with it. Maybe we can have a discussion about it because it is reserved and, you know, you can do something with it.
I'd like to hear from other people if they agree to start with this larger allocation size instead of the PI. That is my opinion from my company. So I'd like to hear from other people
GERT DÖRING: Let me comment on the reservation bit.
Not handing out space right away that you are never going to need is good stewardship. So, the NCC has a /12. At some point it will be sort of full, and there is a small ISPs like us that are still on a 32 because we never needed a 29. So we got upgraded to a 29 but we still are in the first 32. So we don't need a 24. We will never need a 24, so if the NCC would push a 24 on us because they say, oh, it's reserved for you anyway, take it, take it, it's not responsible stewardship. If I don't need it, I don't need to be given it. So, I think reservations, in case you grow and have a contiguous allocation is good, but at some point the ISP says I don't need it. Somebody else can have that space and that's also a good thing. It might not work out but that is why we have reservations.
ALEX LE HEUX: Reservations also work at one time a thing in IPv4 and they expired if they were unused at some point and got reallocated to someone else.
ERIK BAIS: Thank you. So, I would suggest that we take this back to the mailing list. Do a summary on, you know, the options that we have. I do want to take Jordi's time ‑‑ I'll take that offline and we'll include that in the discussion and then we'll take the feedback from the mailing list as well before we proceed. And then we have part of time ‑‑ where are we? How are we doing on time?
.
So, 15 minutes left. Any other business? Topic? Any questions or issues that people would like to bring up for policy? Jordi.
JORDI PALET: Question: Should now I resubmit the ASN policy proposal that I submitted three years ago?
ERIK BAIS: We're going to have a discussion on this afterwards.
JORDI PALET: I can informally send it to the mailing list or the basic ideas to see what the community thinks before another formal proposal? Yeah? Okay.
ERIK BAIS: Any other questions? I hear we're going for lunch earlier this time.
(Applause)
.
So, I would like to thank the scribe, thank you, and see you next year.
(Lunch)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
