Address Policy
Second session
LEO VEGODA: Hello everyone. Thank you for coming back from coffee. We have a jam packed session today. We have got three presentations, we have allocated them each 25 minutes. 15 minutes at the end. So, we do want to encourage people who are asking questions to wait until the presenter has finished speak and then ask their questions, and we might have to cut off the queues if there are a lot of questions, so we can get through the agenda.
But, the mailing list is always open. So, if you are in a queue when it is cut off so that we can move forward, we still want to hear from you.
Our first speaker is Tobias.
TOBIAS FIEBIG: Welcome everybody. I'll be looking a little bit over there because apparently that screen doesn't have the slides.
So, I'm going to talk about 2024‑01, the revisal of the API assignment policy for IPv6. First of all, this was published in August, 13th, the discussion phase has been extended until typo, it's not‑01, it's 11, so 22nd November. On the mailing list there were several points brought forward. So, concerns about the charging scheme implications, which are relatively easily addressed because they are out of scope for this Working Group. There were some detailed suggestions about formulations, things that be parsed better that can be more clarified.
There were some concerns about the creation of relatively large assignments versus the needed or the creation of arbitrarily large assignments which was also addressed and the revisions I'll be talking about, and I am sorry, can I maybe get the slides here?
Can I get a microphone I can carry? Better, thanks.
And then there were of course several questions about how to attribute PI which I think were relatively extensively answered, and I'm looking forward to an extended discussion about that.
So, the goals of the proposal.
We want to reduce the registry space fragmentation, so we want to have more unblocked assignments for a single end user instead of having multiple sparsed out throughout the registry space. We want more flexibility for end users to do things with assignments they receive. We want to clarify some of the interpretations of the policy which led to issues when requesting PI for end users. And what is permissible and not permissible use. We want to make growth easier to handle. And we also want to make it easier for the RAs to evaluate what kind of PI fits the needs of an end user requesting it.
And in the end they should all converge to more assignments that actually closely fit to what an end user needs.
Going into the text and how it has changed. So, first, 2.6 of the policy, how to say sign.
We clarified a bit a thing about sub‑assignments and what is and is not a sub‑assignment. It's not allowed to do that, but we cut out the current text about providing another entity, etc., about sub‑assignments, and added much more clarifications on what is an what is not possible. So for example, in the current policy, there was a discussion about giving for example a prefix to a server you have in a rack of your friend, like imagine you have a /48 for your rack and you want to put a server in there, if you read the impact assessment of the last change that was intended to allow that it says, well it must be dynamically assigned, it must not be aesthetically assigned. If it is it is a sub‑assignment with router advertisements or dependant and regulate changes it is not, it doesn't distinguish between /128. Technically if you use a /56 ‑‑/674 that's dynamically assigned that would be fine. If you use like aesthetically assigned 128 for wi‑fi, that would not be fine. A bit muddy. A lot more text to clarify that.
Also, like the split of into different end sites having exactly one prefix per end site has been a bit lifted. If you are an organisation that would have a larger PI prefix like a 44, you could actually use parts of it in different end sites.
Which brings us to our old favourite topic: End sites.
So, what the proposal does it is changes the definition of end site to distinguish between end sites for PA and end sites for PI the reason being that PA and PI had handled different as PA usually is not independently routed while PI is by definition independently routed or not routed at all. So different definitions so you do not make things the same that necessarily are not the same.
For the allocation side it's basically still the same end site definition we had. For PI assignments, we made clear that this is about a topological location in the RIPE NCC Services region. With he had this topic about the out of region registrations which we are getting rid of a bit here. And we are re‑emphasising this thing about the routing policies, which in the current version of the proposal, well of the policy, is lacking an Oxford comma making it a bit difficult to see what actually means different routing policies and whether there is an independent criteria for assessment.
We also define how different routing policies can be realised, we make clear that a Layer2 connectivity between two sites does not make than one end site. There was a lot of discussion about this on the mailing list because why would you want to treat Layer2 different if you have an L2 VPN, is that really different from an L 3 VPN? And the reason is pretty simple: It's something the RIPE NCC did so far, and we want to stop doing that.
Also, there is additional clarifications about placing CPEs in customer locations that doesn't really make it an end site of yours. And there is a clarification by Anycast deployments that if you do Anycast that is basically just bun additional end site you have.
Then, change to 5.4.2, it's again in the same vibe to distinguish between assignments made from PA and assignments made from the RIPE NCC to an end user, and a bit more clarification about this notion of what does size mean? So, there were in the past a couple of discussions about what does it mean if it's the smallest assignment is /48, is that the smallest prefix or the smallest total network size? So additional words in there to actually make clear like what is meant by smallest.
Then the bulk of the changes is of course section 7, so the provider independent assignments. It opens now with a statement that more specific policies may deviate from this policy. Which is due to the IXP PI policy allowing the handing out of /64s at the moment, while at the moment the PI policy does not permit that because depending on how you read it, you can only hand out 48s. So, explicitly allowing that over write is essentially just fixing something that was already there, and allowing for these policies to deviate.
This is the exact sentence that was the matter of issue, like minimum size of the assignment is a /48.
Well, a bit more expanded also adding the example of the IXP LAN which is the current clear conflict. And of course, explicitly allowing shorter assignments, because that often was an issue discussing with the NCC whether a shorter assignment or multiple assignments of 48 would be indicating if an end user needs more than one single 48.
So the operational example here is one end user, I know that has four 48s, equally spaced over 44, which of course is not really ideal.
Concerning the size, we are basically going for a thing that is basically counting end sites. So, one end site, one /48, and we are actually planning to do this by nibble boundary. So, that's 711, meaning that if you have one end site you get one 48. If you have two to 16 end sites you get a 44, if you have 17, 256 end sites you have a 40 and if you have more than that you get a 36, with that being the maximum PI size because as I said in the previous paragraph, PI is always smaller than the smallest allocation at the nibble boundary, with the smallest allocation being a 32, we just have like a ceiling now, relatively hard, PI is not PA, it's always smaller, and let's be honest, if you have something that means that you need a 36, you can just become a member.
Anyway, also, there is a suggestion in there, not a strong requirement, because that might be operationally difficult to quickly implement, to leave the next nibble unused. So in case of growth, at least once there is easy growth because you can get the next nibble which covers the prefix you already have so you do not effectively have to re‑number if you grow. If you grow again, you may have to re‑number. Which is part of somewhat conscious introduction of cost there for assignment holders, to not go for larger and larger PI, but if they have such a gross mechanics that they should actually seriously consider becoming a member.
Also, these assignments made at the nibble boundary cannot be split and transferred. But they may be independently routed. And I have heard the argument that this would blow up the routing table. Well the thing is at the moment these people are getting independent 48s for that need, and those are definitely independently routed anyway.
So, if you are then requesting a larger assignment under the revised policy, you basically just ask for "can I have more"? And if you meet the requirements, which is basically you have an enough end sites, you will most likely get it.
If you have prefixes already, it should ideally be extended. If you have multiple on a previous policy, you should ideally get the choice of well if one of them can be extended I would like to keep that one and give the others back.
And for that we have a six month renumbering period, which is relatively strict for prefixes assigned under the proposed policy. That might sound a bit harsh. But it also works in this mechanic of well we plan for enough growth, you can reasonably grow, if you grow significantly more than what is considered reasonable, you most likely are better off to become a member, like think twice before you impose costs on the community.
Of course, we also have to deal with legacy, in one form or another. Well legacy in this case PI assignments made before this policy was put in place will have been been put in place. You can of course always then ask like if you have now like these four /48s and a single 44, you can go to the NCC and be like, hey, I have four end sites I would like to have this revalued and they will most likely end up re‑evaluating you to a 44 because you have more than one end site and then you most likely get the current prefix and everything is fine.
So, of course, if there is like a covering prefix, you should get this without having to re‑number. If that's not possible, well, you might have to re‑number. And the crux here is that all previous issued PI assignments must be returned to the RIPE NCC after a renumbering once a new PI assignment as been issued or an existing one has been extended. And for assignment made under this policy that is a hard six months and after six months you give it back. If it comes from before the implementation of this policy, you get an initial renumbering period of twelve months which can be extended. And people might be like if we allow eternal extension, that's a bit odd, it's Like they don't have to give it back. Well the trick is that this means that this is still mandated to be returned to the RIPE NCC, which is the only blanket exception from transferability we have in the transfer policy. So, as soon as you reach that state, you can continue to use it. And you can no longer transfer it.
And then we have a provision that if you are, if you are receiving a transfer, you are also reevaluated, which is kind of what we are already doing for PA since the last meeting. And if you end up having to be reevaluated because of something you do, like you receive a transfer, or you like, ask for something bigger and have already like, well more than you need, you once, once, have the ability to actually withdraw your initial request. Which means if it's a transfer, it's not ‑‑ it's like you never asked for that transfer. Just to reduce the impact of bad surprises for operators. Right, because not everybody closely follows the policy development procedures, so, we don't really want to put people into a difficult bind.
If this is a case like if you would like if the NCC would need to reduce the assignment size, and the assignment holder is able to still withdraw the request, they should actually be made aware of that.
So, onward:
I heard the point that this is a bit complex. Yeah. It has to deal with a lot of complexities, and inconsistencies which we already have in the policies. And if you change really tiny things you all of a sudden might end up with really serious implications, because what about those people who already have, the classic thing when I talked about nibble boundary, the first question was what if you split that assignment and want to transfer 48 out of 44, because all of a sudden you do no longer have an assignment at the nibble boundary. So, that needed a lot of additional things being put into this policy. And finally, to the why? Why are we doing this? Well, to address the operational challenges in PI which we discussed since Rome, and to facility aggregated registration.
And what I would like to do now, what I believe is really, really important and what we had in a limited fashion on the mailing list, is have an actual discussion. By the way, if we discuss here and you bring out point, please also take your words, put them into an e‑mail and also send them to the list, because if you just speak here, that does not help the PDP. It gives me a better perspective of the community thought on the state of the proposal but it is not relevant in the context of the PDP, so if you have a point, please say it at the mic, let's discuss it here, but thereafter summarise it and post it to the e‑mail.
LEO VEGODA: We have five minutes for questions, and then we need to move on to our next agenda item. So, I see Gert moving to the mic
GERT DÖRING: I think this is the first time I actually took my laptop with my notes to comment on a policy proposal which implies too much text and that's the main comment, too much text. And my main objection to that is too much text. To qualify that a bit more, all policies need to be workable. And this is adding way too much text to an already complex document. This is not a computer algorithm where a machine will just walk through the steps relevant to it. It's for humans to read. And I can see what you are trying to do, and that is, I might go along with that, but the way it's currently written, it's so complex that I didn't comment on the mailing list yet because I couldn't really find time to make up my mind on the individual bits of it to actually write that down, and that means we need to really look into it, what are you trying to achieve and can it be achieved with less words.
TOBIAS FIEBIG: That is the exactly the problem how this evolved. This used to be shorter and then also in discussion with Angela, there were these things popping up, but what have you thought about, have you thought about? And I agree with the general point, but my proposal there would be to, in the theme of the current policy, which has grown over years, address the PI problem and then do to a complex growing system to a solution to make it workable again, which is we call a clean slate approach, and I think that is the only approach with which we can actually get rid of this too much text.
GERT DÖRING: That is not going to comply because if you add all that text now you will never get rid of it again. I have some particulars that no like, like the end site. The end site is a topological concept. There's no end site for PA or PI. There is an end site that defines what an end site is. So why duplicate that for different purposes? If Layer2, Layer2 is like a very, very particular specific term, what does it mean? Does it mean if they connect their ethernet networks or if they have an ethernet between their routers and so on?
TOBIAS FIEBIG: Yes. So the second point what we say is that thing doesn't matter any more, because those discussions, what you just brought forward is some discussion you now have to have with an RA. And they will ask you trick questions whether it's L2 or it's L 3. And if ‑‑
GERT DÖRING: Than the wording needs to be like if they have an interconnected network, it is considered as this or something, what does Layer2 mean? Definitive a fiber, it's not on Layer2. Or if I have a Layer3 routed system it's not Layer2. So, we had that in the past. If we were too specific technology wise in the policies, somebody came and had a very similar use case but using different technology and all of a sudden the intent did not apply any more because the wording was very specific on a particular technology like US L ‑‑
TOBIAS FIEBIG: L2 is not an inclusive wording, it's like this also doesn't matter.
GERT DÖRING: Yes, but what if it's not Layer2, what is a fiber? Fiber is a layer 1.
TOBIAS FIEBIG: Well, if you would have that argument with an RA now they would say that a fiber is in layer 1. Layer 1 implies Layer2 because duck and your request gets rejected.
GERT DÖRING: I don't really care about current roughness in dealing with the RAs. I care about clear and understandable wording in the policy. If there is friction in dealing with the NCC, this is a particular different thing, and it might be addressed with text change or with arguing with Marco and Angela about how they implement things.
TOBIAS FIEBIG: But the result of the arguing is that.
GERT DÖRING: I think that did go into the wrong direction. The intent is good but the current wording is I think unworkable.
TOBIAS FIEBIG: So do you have any text suggestions? Like, not right now, but I'll take them via e‑mail.
GERT DÖRING: Not prepared right now.
TOBIAS FIEBIG: As I said, I'll take them via e‑mail.
GERT DÖRING: Since whatever happens here is in the room and everything needs to go to the list anyway, I will send suggestions to the list.
TOBIAS FIEBIG: Like concrete text would be greatly appreciated.
GERT DÖRING: I'll try my best.
LEO VEGODA: Thank you very much. Alex, do we have any relevant questions online? In that case, thank you Tobias. Thank you.
(Applause)
Okay, it's time for our second presentation of this session. Jordi and Rinse are joining us online and will be making a presentation of over Meetecho.
JORDI PALET: I don't see yet the slides. So I can move them.
Okay, so, this is a proposal 2024‑02, Version 1. Basically, this proposal comes from the work done in the last two or almost three years, we had a couple, if I recall correctly, a couple of interim meetings, and the idea was to simplify the allocation of IPv6 because one of the problems that many LIRs have expressed is that they cannot really justify so easily their actual needs, and well there were other inputs that you will see across the next slides.
We got some statistics from the NCC, thanks Angela and the rest of the team. Basically what this is relevant ‑‑ this is just a part of the statistics that we got. What is relevant for this proposal is that from a total of 22, 482 allocations, IPv6 allocations, there are 22,614 smaller or equal to 29, I am not going to read all the statistics, but the important point here is that about 91% of those can be extended to a /28, which is what we are proposing in this text.
There are also interesting things like that starting in January 2023, the NCC closed 331 IPv6 additional allocation tickets and extended less than half of them. These basically tell us, at least what we can infer, that approximately half of the extensions are not accepted, okay. So, this proves one of the problems that we were discussing in the interim meetings and along the last couple or three years.
What are the changes we are proposing? We have, in the next couple of slides, we have two columns. The column on the left is the actual text. The column on the right is showing in blue what we are proposing to change. As you can see, it's very, very small changes, but there are important changes. The first one is instead of having an initial allocation of a /32 up to /29, we are suggesting either a /32 or a /28. And then again a greater initial allocation instead of from a /29, of course it must be from a /28, so meeting the recommendation that justified the request and so on.
Now, existing IPv6 address space holders. We are proposing that the existing holders can request an extension of each allocation up to /28, and the wording of this paragraph has been, let's say, developed together with the NCC to ensure, and this is one the discussions that we have in the list, is that, for example, those people that got a lot of /29, cannot breakdown each /29 in multiple /32s and then request a break for each of them. This is one of the discussion points we will see in the next slides. Arguments supporting the proposal, while it's a regular update of the policy, because we have now better deployment experience and we have the information about the justification for an extension being difficult in most of the cases and in many cases, a /29 is not enough. We are trying also to reduce the overhead and complexity for both the NCC and the justification by the LIRs, whereby flexibility simplified DNS operations, increase reducibility of addresses, etc. Some people don't agree with that, but that's our experience as authors. And also, we are trying to have the allocations as a single prefix to avoid the views that I mentioned in the previous slide.
We confirmed with the stats that 93 percent to be extended and we don't see in principle arguments opposing the proposal.
This proposal was initially suggested to the NCC and the Chairs a more complete proposal. Our idea was not just to do what this proposal is suggesting, but also we had a draft text combining this with nibble boundary allocations, so, after a /28, we will get a /24, a /20 and so on. Replace the HD ratio with a table to match the nibble boundary and then simplify all the process. And in fact, this was presented already in Rome by Jan, Gert and Sander. So, we had basically the same idea. We initially had a different perspective about how to do this replacement of the HD ratio but we agree with what they proposed in principle.
Again, this can happen if we have a follow‑up or a couple of follow‑up proposals once the community reaches consensus with these, but it may happen also that the community don't reach consensus on this and we work in the next steps anyway.
So this is something that we need to see. And this is my last slide.
I have tried to collect here the discussion in the list. There was a question about the justification of the policy change. The policy change was coming from, as I mentioned already, the interim meetings and experience that we have requesting allocations to the NCC. There was a recent discussion, I responded I think yesterday about this, in, at the point of if we want to allocate only a /32 or a /28, or if we want to allow as well something in the middle. So this is something that we, as a community, we need to decide. There was a question about if this is a problem because we have an IPv6 shortage, I mean in the sense to allocate everyone a /28, definitely there is not a shortage, I am convinced that this can not create a problem. There is also the point about aggregation on top of conservation, which is contrary to what we have more IPv4, so I think that's one of the goals of this proposal, and also probably the follow‑up ones.
There was a discussion which basically is out of scope, it's about the billing scheme. If everybody gets a /28 and then the billing scheme is changed, and it was responded by the, I think the Chairs of the billing task force explaining that they already look into the policies before suggesting new billing schemes. And then the other discussion which I think is very important is what already Marco presented in the previous meeting and also today about how the stockpiling.
I am not sure if this is really related to this proposal, and we can make some changes in the testbeds to make a bigger limitation of those stockpilers to extend only one of the allocations or only one per organisation or something like that, to a /28 instead of all of them. For example, there is one or a couple of them that have hundreds of allocations and then there are several that have more than ten allocations, so that a problem? Now, if we don't do that, the problem is also that they have a space reserved. So, how that space will be used. They could only use that if they justify an extension of each of those allocations.
So, I think with that, we are done. Rinse, my co‑author is also online, so any of us can provide any additional inputs or respond to questions. Thank you.
LEO VEGODA: Thank you Jordi.
JORDI PALET: I don't know if you want to say something I forgot already or...?
LEO VEGODA: Have you completed your presentation?
JORDI PALET: Yes.
LEO VEGODA: Okay, we have a good amount of time for questions. Rudiger, I saw you in the online queue, but you are also in the physical queue, which one do you want to use?
RUDIGER VOLK: Well the online queue mechanism is meant to be available to all participants. This is supposed to be a hybrid meeting. Sorry, in the last session I actually raised my hand and then had an urgent call for something else, so that may have caused some confusion.
So, I am Rudiger Volk, I am retired, no affiliation any more. Can we please go back one slide? One more.
I really, rarely look into the Address Policy things and I my involvement in Address Policy goes back to before the RIPE NCC actually was founded. I distributed IP addresses back then. When I looked at this proposal without having the benefit of all of the previous meeting and discussions, I felt that a proposal that says well, okay, here are the arguments for and there are no counter arguments, that makes they always very suspicious, and thinking a little bit more about it, if you want to have me propose a counterproposal ‑‑ a counter argument, well, okay, the proposal quite definitely works against conservation. Whether that is actually an important and serious weight, well, okay, one can think.
The other point that I stumbled over is up there, the first bullet, you are saying you are referring to deployment experience. Actually, what I would like to see is, is there any report that actually tells very specifically what is the observed deployment use of a /29 over a /32 that we had initially. For doing the 29, we had very specific reasons to start it. We did not list the specific technology that we had first in the official policy, but there was something very specific, and kind of claiming deployment experience and having no summary of what actually has happened there, I think is pointing to a real gap, and for thinking a little bit further. I would also suggest that we request from the RIPE NCC some summary about what the experience with handing out larger address blocks beyond the initial 32 has been so far. Without clear reports and documentation of that stuff, I would argue that the goal of conserving the address space should not be defeated. Reports may actually very well justify to go forward but without quite specific reasoning, I think that's not acceptable. Thanks.
LEO VEGODA: Thank you, Rudiger.
JORDI PALET: Very quickly. When we say arguments opposing the proposals known? Obviously from the perspective of the others and also with the discussions with the NCC staff. This is an open discussion, so I perfectly understand your points, and I also think that in IPv6, and probably many people will agree with that, its much more important aggregation than conservation, we are not trying to waste the space. The people can still request a /32 if they don't need more than that. And my experience is basically the problem that if you are a very small ISP, you have for example less than 50,000 sites, a /32 is more than enough. But if you have a medium sized ISP that have 400,000, 500,000 sites, depending on also how is your aggregation scheme, you don't have enough with a /29.
LEO VEGODA: Rudiger, I am going to cut of off here because we need to hear more voices
RUDIGER VOLK: One point. The offers are proposing something that is supposed to get the consensus of the whole community. It does not make sense to put in something there where you say: Well, okay, this is the offers and the rest of the world we don't care.
JORDI PALET: I am not saying that.
REMCO VAN MOOK: I have two observations. One of them is, so in your proposal you are basically replacing the /29 on the initial allocation with a 28 and that's pretty much it. Now if I'm looking and link to your rationale in your presentation, which is basically /28s are simply better and everyone should be using them, actually then we should prevent everyone getting initial allocation from shooting themselves in the foot and just give everyone a /28 and drop this whole /32 notion, because apparently aggregation is so important, so if people think they only need a /32, then in the long run they are probably wrong. So, let's just help them and just take away that choice.
Second is, this has been a long, long time ago, but I think I was involved with the text that added the up to a /29. And one of the main rationales behind that was that behind the scenes for every /32, that was being allocated to LIRs, the RIPE NCC, in the interests of aggregation, was already reserving the encompassing /29 for future growth. And we then thought, as co‑authors back then, well, if the address space is already basically reserved for that LIR anyway, why not just give them the option to take it right now rather than at some potential point in the future and then when this current policy got introduced, what then happened was the RIPE NCC then very helpfully decided well, so what if aggregation comes into play and people run out of their 29? Let's increase the reserved block to a 28. And my concern right now is, if we're going to do this, the RIPE NCC might be helpful again and take the reserve block up to a 24, and then if five years from now we're going to have the same policy proposal again saying well, why not take the whole 24? And I think that's a cycle we need to breakthrough. If we are going to do this, let's also be very explicit that the instruct the RIPE NCC that aggregation beyond that block is not necessarily a requirement. Whether I am in favour or not of this proposal, I currently have no opinion.
LEO VEGODA: Thank you.
JORDI PALET: I think it may be a point to have some additional text to say that the reservation from the NCC should be like that, I don't know what figure, but something to break that possibility, as Remco said.
Regarding the /28 versus the /32 or versus a /29, the first point from Remco, I think we can ‑‑ one of the open questions is, if the people want to have only those two choices or anything in the middle as I already said in the slides.
RINSE KLOEK: Maybe to add, is that currently RIPE is insuring in 2016 the /25, so you get ‑‑ already the space is not given out anymore and can not be allocated. The second thing is that already 90 percent of the people, if they have a choice, go for the 29. So we have a very small amount of people that choose for the 32. So I expect also the same to happen if we go for 28, and the only difference at that we want to stick to the nibble boundaries proposal and not having the option to have something between. So we like to go for only two, the 28 or the 32.
LEO VEGODA: Okay, we are closing the mics now. If you are not in the queue, you are not in the queue, but you can always write to the list. If we go to the rear mic.
AUDIENCE SPEAKER: As I am currently understood, for example, if one LIR has /29 and the other LIR has /29 and do some acquisition or merge, they will lead to some big LIR that can have 2028? Am I understood correctly?
JORDI PALET: You mean if there is a merger on that decision? They will ‑‑ each LIR has, or each organisation has a /29 at the moment with the current policy they will get two /29, because they have two of them already in the separate organisations. If we accept this proposal, then they will be able to break each one to a /28.
AUDIENCE SPEAKER: We have two online questions. One from Sergey ‑‑
LEO VEGODA: Could you wait, I was asking for the rear mic first.
AUDIENCE SPEAKER: Richard Petterson from Sky. Having been responsible for that statistic, at least one of those tickets closed, my request for additional space. I, in general am supportive of the change. My only main concern I guess is the /32 or /28 thing. I am keen for the /28, I just don't want that increase to /28 and making it an either or. Make it harder for somebody to get that 28. So if they just breached the requirement for /32, I don't want the NCC to say well, you don't quite have enough to justify a 28 now, so you are only getting a /32. In my experience it seems like that is a very real possibility.
RINSE KLOEK: What what is the question to the RIPE NCC is to ask to the LIR?
AUDIENCE SPEAKER: The question for them to ask. I guess just make it clear that as soon as an LIR can justify one point over a /32, than it's instantly a 28. Make it no grey area in the middle. If you are going to keep the either or option. Or open it up to as you suggested, everything in between.
JORDI PALET: The point of the current text is it's a decision of the LIR if you ask for a /32 or a /28, it's not a decision of the NCC. That's the idea.
LEO VEGODA: Angela has a clarification.
ANGELA DALL'ARA: Just a clarification, nor the initial allocation, there is no justification in terms of having to document the needs for the network. The justification is to have a plan to implement IPv6 in the next two years. So it's a choice currently of the LIR to say how many ‑‑ how big the size of the allocation he wants to receive, between 32 and 29, and this proposal would be just a choice between 32 and 28. But still without documentation only with the intention to implement it within two years.
LEO VEGODA: Thank you Angela. I think we need to move along and we don't have time for responses now. So, we can make comments or ask a question, but the questions will need to be answered on the list because we are running up against the clock. So...
AUDIENCE SPEAKER: Sure. So Dominic. Cisco. I have a short question because this is regarding what has been asked before, so, with regards that we previously increase to /29, it was one the arguments was like aggregation, right, do we actually have the evidence that it's helped with aggregation and now if we will also see aggregation benefit before in this proposal, right? Thank you.
LEO VEGODA: Thank you.
AUDIENCE SPEAKER: So we have a comment from Sergey. "Stockpiling should be considered as the argument against the proposal."
And then we have one from Sebastian Urgess: "There is a middle ground here for every requested /32 allocated in a way that's aligned with a /28. Nibble boundary as long as we have enough space makes extending EC while conserving for a possible future."
LEO VEGODA: Thank you very much. And thank you Rinse and Jordi for presenting, and I hope that we can see you in person in Lisbon.
(Applause)
Remco.
REMCO VAN MOOK: This is a beautiful slide, but it's not the start of my presentation. Can we go to slide number 1 please:
Good morning everyone. My name is Remco van Mook, and I am here to talk about simplifying the assignment status.
Previously on this show, back in RIPE 82, I presented ‑‑ I had a presentation called Y PI, which is a bit tongue in cheek because it's a question on the very, very, very old IP requests form that you had to fill in if you wanted to have PI space.
Then, in Krakow, I did the new version of that, updated the 2024 numbers, and the threat of a policy proposal.
So that is where we're now.
But actually, much longer ago, we had a policy proposal 2013‑03, by Tore and Malcolm, which was a clean‑up of obsolete policy text and aligning procedures with policy objectives. That resulted in RIPE 604, which is, at least 12 versions of IPv4 policy ago, in February 2014.
One of my ‑‑ what am I trying to do here? I am trying to improve accessibility and simplicity of our policies resulting database. What am I trying to achieve? The thing is that our Address Policy has a global audience. Actually it's not so much the Address Policy, thank God we're not being observed by 8 billion people in here, but the result of it, which is our database and what's in there, has a global audience, and a lot of the arcana that are in the database and in our policy have local relevance to us, because we all care deeply about colours of address space and nibble boundaries and everything else, but the rest of the world ‑‑ so this has local relevance and no global significance. The result the rest of the world really only cares about, who do I kick and where are they? And the rest of the world doesn't necessarily have the vocabulary that we are using to describe things, like legacy. I mean what does legacy mean? Is that actually still valid? If you don't know, if you don't have the history of how we got here, that's an entirely valid question, because legacy typically doesn't mean something very good.
What else? I mean, so how much training do you actually need to use a phone book? How much training do you need to understand what's in the RIPE database, and inet‑nums, and understanding what we are putting in the database already isn't easy. Understanding policy, as we're all finding out here is hard, but actually contributing to policy development is super complicated. I mean I have been doing this for the best part of 20 years at this point, which is, which gives me some life choices to reconsider maybe. But even with 20 years of going through this, it is hard to figure out what goes where and why did we do things. In the preparation for this presentation, I have been trawling through archives of RIPE policy documents, some of them are only available in postscript and files and text, to figure out what we intended and what was going on.
So, I tried to summarise, okay, what do ‑‑ what should we strife for in Address Policy? I have come up with the three Cs for Address Policy.
It's concise, complete and consistent. And I mean, I think that in general, and I mean we are failing on all three counts right now. I'll try to demonstrate to you how and why.
But, really, my more fundamental problem is that a failure to clean up after ourselves with stuff that's left in there, stuff that has relevance to a point 001% of the world at some point in the past, really amounts to gate keeping. It makes it harder for this room, for this group, for the community to actually get people involved and start participating in a process. If it takes two decades to stand up here and try to make a sensible statement and have something that fits with policy models that we sort of understand together, that's no good. So, moving back to sort of where I started.
I figure let's start off with something simple. Let's look at one piece of the database and try to sort of unravel what it means and what we need. And that's the status field of an inetnum or an INET6 num. You think that's trivial, right? I mean, how hard can that be, a single field in a table?
But the current status field is sort of a conflation between a contractual state and an operational state, and I think in order to evolve policy, but also the wider organisation, the wider structure, splitting those two up is probably a good idea, because we shouldn't have lawyers writing engineering documents, and at the same time having engineers writing contracts is also maybe not the best idea in the world.
So, let's look at that.
Going to my through the Cs: Completeness:
So, a question for the room, but I have been under instructions to not open this up to Q&A. So, show of hands for who knows which policy document defines the status field for IPv6? Tobias of course, he has been in the middle of it. It's cool, right, we have one person in this entire room and we're the leading expects in the world on this topic.
So let me help you out a little bit.
So AGGREGATED‑BY‑LIR is covered by chapter 5.5 of the IPv6 assignment and allocation policy. Assigned Anycast is covered by chapter 6. Assigned, gets mentioned in chapter 5.5, but actually is not defined. And every other type that we have in the database right now, in the database documentation, has never been identified, discussed or accepted in policy.
When is a tree not a tree?
The short answer: When it's a table. You can turn a tree into a table, it's pretty much irreversible process, it involves saws, and chisels, and trees have an apparent hierarchy, because every element of a tree has a parent.
Tables have unique keys, but data can and will overlap, and that makes it problematic. If you want to see how problematic, I would encourage you to read up on the saga of numbered work item number 4, which happens on the other side of the fence in our, we have our dear friends of the Database Working Group, which led to the introduction in May of this year of the new status of "Allocated assigned PA". And at that point when I read that in preparing my presentation today, my head exploded.
What does that even mean?
Well, what it means is the structure in which we store our data is so broken that we need work‑arounds, and this is a very big ugly work around.
Address space is hierarchy, but the way we currently register it does not. If you think of number resource records as a tree instead of as a table, and I understand where the table thing comes from because back when we started doing this stuff we had a couple of hundred entities and of course the only thing you can do at that point is stick it in a table, put it in a database, that's it.
But actually if you look at it from a tree perspective, that makes mapping it back to reality, aggregation, conservation, blah blah, RPKI has hierarchy in it because PKI has a hierarchy, and actually using a table for work‑arounds like NWI‑4, but there is more I'll show on later.
So, what would that tree look like? So, here is your notional inetnum. There is a unique identifier. Interestingly, we also have a net name in there, which turns out not to be a unique identifier currently, which is interesting. We have the block which is the address space that we're talking about. That block has a parent, which is the unique ID of one further up the tree. Status, is this a stub or is this not a stub? Can this thing have leaves or not? Who is the holder? So who is responsible for this block? And then some additional data like maintainer records and all the arcane stuff that we like to have on the administrative side.
So, notionally, what would that look like? I mean, probably pretty obvious, but I thought I put it on a blackboard anyway. So, here is the root, and heave the blocks that have been allocated to RIPE by IANA, and there is a bunch of them of course. And then out of that block, and my apologies to workday in Ireland, who happen to be the random lucky winner of my trawling the database. So, yeah, out of 37 /8 the first walk out there is 37 /21, and there in the next block is 3708 /21 etc., etc. And if you look and so on and so on. And then what happens inside a 37 /21, there is a bunch of assignments that are made to end users or infrastructure that have particular roles if. I used green and purple to mark allocations verses assignments. So there should be nothing underneath the purple. And low and behold there isn't. But you can see you can see how can basically just stack green on top of green on top of green.
So in terms of on the same level, you can't have overlap. But overlap in here, is absolutely fine because that's simply how trees work, because you have the inherent hierarchy of a tree that already tells you where you are.
So, all the types of status records that I have been able to find, all the animals in the zoo and what they do. And I decided to add a picture of a Tardigrade in there, if you don't know, they are microphono, sort of really tiny animals, they are not bugs, they are tiny animals, and they are resistant to pretty much anything. They are cool. They can stand vacuums, they can stand radiation, they can stand heat, they can stand being boiled, they can live through almost zero kelvin, pretty much like our status records.
So so what do we have? Let's go through some of the familiar stuff first. Let's go through the assigned part of the tree.
We have assigned on v6, assigned PA on v4, which indicates that a block of address space has been assigned to an end user by an LIR. Pretty straightforward. Covers 90 odd percent of the records in our database.
And exist equal in v4 and v6. And for v4, it was defined in RIPE 140, which is the first IPv4 allocation assignment policy we have had, which was coauthored by a certain Hans Petter, you may have seen walking around. And I didn't put a definition time in for IPv6, because we never did.
Assigned PI. Same thing, but instead it's address space assigned to an end user by the RIR via a sponsoring LIR, which has been there forever.
Legacy, which indicates that we have a block of address space that was assigned previous to the existence of the RIR system, which of course only exists in IPv4.
Here is an interesting discrepancy. If you look at policy, our policy documents they assigned. If you look at the database documentation, it says allocated. I don't know, does it make a difference? I guess...
Then we have AGGREGATED‑BY‑LIR, which was first introduced in IPv6 by Marco and myself in 2011, 2012, which indicates that a lot of address space was assigned to a group of end users. So instead of having to do like an assignment for every single end user that you are handing out a 48 to, you say okay this entire block is end users and they all get a 48, then that's it, which radically simplified documentation.
So, that was introduced in RIPE 513 for IPv6. And in RIPE 822, which is actually this year, as a sort of feature parity in IPv4.
Moving on, assigned Anycast, this is one of my favourites. Anycast is a block of address space was assigned to an end user by the RIR in line with the Anycast assignment policy.
Now, I have talked about this before, and there's multiple problems with this one. It's a misnomer. The problem is that most space that is in use in the world as Anycast actually is not assigned to Anycast because the Anycast assignment policy only allowed for top level domain operators to get a block. At the same time, the policy actually does not require that space to be actually Anycast. Unicast is just fine as long as you are still using it. It hasn't been part of IPv4 policy since early 2014, in the same clean‑up that I mentioned before, by Tore and Malcolm, and it is still part of IPv6 policy. Does it get any use? I couldn't find any traces of new assignments in pretty much the last decade.
Then, on the allocation side, we have allocated PA/allocated by RIR. Which is an interesting one, because again, it's called allocated by RIR, but there is no paper trail on who actually decided that this is what we're going to call it and why. Then we have allocated by LIR or sub‑allocated PA, which indicates that a block of address space was allocated by an LIR to another LIR, or downstream operator, which is a term that has no further definition for further allocation or assignment, which we do have in v4 and v6. Then we have LIR paragraph tradition PA, which is space that an LIR allocates to itself, which makes ‑‑ I mean I guess is useful for very large organisations with multiple maintainers that are not allowed to touch each other's stuff, which have defined in RIPE 234, which is ancient.
Then, this is the, this is so good. Allocated unspecified. And it indicates that a block of address space was allocated by something to an RIR for further distribution and existed in IPv4 only. And it is defined in RIPE 140, the very first IPv4 policy document we have ever had about allocations and assignment with this literal text. "This type of allocation is obsolete and will not be applied to future allocations."
This is from my presentation last time. The 36 hundred is a number in early 2024, and the plus 941 means the growth since the presentation I had before that. Actually, I had a chat with Marco Schmidt yesterday to validate some of my numbers and I think we were 39, 40 something at this point. So, from early this year on, we have added another 400, which actually makes this one of the more popular statuses that we're using right now. And we shouldn't have been using this literally since 1994. And I have my suspicions on what this is, and I mean this is a whole different issue all together, because who is using it? It's used by the RIPE NCC. And with the best intentions, because they are using it to document address space that was part of the RIPE address space, the allocation that were handed to RIPE by IANA. But have been transferred out with the inter‑RIR policy to somewhere else, which, in my view, actually is not unspecified at all. It is extremely specified, and I think we would do well to actually make that specification revisible, very clearly documented. Because if you look at an allocated unspecified it adds some generic links to, here is some of the other RIRs, try your luck there, we don't know.
And then we have the monstrosity of allocated assigned PA which indicates that a block of space was allocated to an RIR by another RIR for allocation or assignment and indicates that that same block of address space is assigned to an end user or infrastructure by that LIR. That only existed in IPv4 and it was introduced in May of this year.
Summarising that in a nice little table. So, we have PA assignments, PI, legacy, you can see what the role is of the status and what address family it belongs to, who holds the address space and who has done it and to whom.
So ‑‑ and I didn't add allocated assigned to this table because it would just make this table blow up. Because it's all, it's just everything.
And what my policy proposal, or draft at this point, aims to do, is take all of this say: Okay, what's the contractual stuff? That's the whole legacy, and just focus on the role, what is the role of this object? And it's either you assign something to someone or you allocate something to someone. The firm who to who is apparent from the structure, and the contractual stuff should belong in a contract database and not in an operational engineering database.
So, turning that table, this table into this, which is, I have things that are allocated, and there is one small, the LIR in there and they are doing it to some other RIR we have assigned, which is to an end user, or we have aggregated by LIR and the version you should scream at if there is something wrong with it is the LIR and the end user is using it.
In summary: The proposed policy is an attempt to move closer a little bit to the goals of concise, complete and consistent. I will freely admit that the rationale I wrote in the initial draft was a bit rushed, and didn't do a good job describing why I want to do this. I think good stewardship requires self‑reflection in a more stringent way than we have been doing. And I think we really need to have a long hard look at what we are inviting people into and what we are leaving behind for other people who try to fill in after us.
So I think as a working group, we have a choice: We deal with the inconsistencies. I mean I have just ‑‑ I mean this is ‑‑ I pulled up the carpet and I found the mess. So we are going to deal with the inconsistencies and clean it up for this proposal. In terms of if we actually simplify the status or we add a simplified rendition visualisation, if you will, of what that status actually means to the records, I'm open to, or, we decide on a wider approach on the whole policy stack and maybe Arran's style, take all of our pieces of policy, take it to a single manual with some solid editorial control and review and move from this there?
And that's all I have for now. Any questions and comments would be greatly appreciated.
LEO VEGODA: Thank you very much. It's great to have problems explained in an amusing way.
So, we have 13 minutes for comments and questions on this proposal and for our Open Mic. So, I'm going to say we're closing the queues already, and please keep your comments or questions really concise.
TOBIAS FIEBIG: I think that this proposal suffers from the same issue as trying to revise the PI policy which is if you lift the carpet a bit then you have all these implications crawling out, and you might have heard some really rattly noises outside, I heart that that was our legacy holders which are feeling a bit antsy about the removal of the word legacy from the database. I do have some ideas of how we can accomplish what you want. I think that the proposal too big to be done before something like that, and I discussed it a bit with Alex and I think your proposal actually falls into the same bracket but that should be discussed offline, but essentially we need to go more towards a clean state.
AUDIENCE SPEAKER: Nick Hilliard: As Tobias already said, this is an elephant‑eating proposal. And I made a comment in Krakow that I really didn't understand what your proposal was going to do. I don't think I still understand it enough, but I do think that this presentation is what you should have started with, but it only goes a certain portion of the way to explaining the downstream consequences of what you are trying to do. So I'd encourage you to continue on this road of trying to tease out what you are trying to do, and then split up this policy proposal into smaller more byte size chunks that we can actually swallow without getting that elephant stuck in our throats.
REMCO VAN MOOK: I appreciate that.
AUDIENCE SPEAKER: Tina Maher, I am actually in support of this, not going back and removing entries that are already there without careful consideration, but going forward having that limited selection of states. Because, you know, there could be implications to things that already exist. I am also for going through all of pathologist and thinking about it from an outsider's approach and how difficult it is to understand and clarify, I think we should revisit more sections and more areas of policy here and clean them up and make them friendlier.
REMCO VAN MOOK: Thank you.
GERT DÖRING: As proposed on the list, I didn't agree because it would take away information that's useful. So, thanks a lot for explaining more the thought process behind it. I do fully agree that making the explanations for the things we do easier and accessible, like calling them documentation and actually having a complete documentation is welcome. Simplifying the status values is also a worthy undertaking, but I, as I said, I do value seeing the contractual status behind the status. So if we make the status field very simple, which might be a good thing, having that sort of information still accessible, I would see that as a bonus. I don't really have a clear road how to get there though. But definitely looking at what we do, why we do it and what we did in 30 years and why it's all so complicated is also worth the undertaking. Thank you.
AUDIENCE SPEAKER: From Jordi Palet: I always thought that a single consolidated policy manual is better than phrase documents as we have the only RIR that has it that way. It will be a lot of work probably needs a DF, but I think it will make a lot of sense and happy to participate.
REMCO VAN MOOK: All right. Thank you Fallen and Jordi.
LEO VEGODA: Thank you very much.
(Applause)
LEO VEGODA: Okay, we still have a couple of minutes for an Open Mic session, and then we will close. So, we had Marco's presentation at the end of the first session about the recap on personal ASNs and there was a question there at the end which got a little bit of cushion about whether we even need to have multihoming or unique routing policy requirement, and I'd like to invite anyone who want to talk about that to come up to the microphone now. But there might be completely different subjects that people want to raise, and they want to say hey, this is something that's important to me and I would like to express it. This is an opportunity. Nick?
NICK HILLIARD: I have some opinions on the multihoming thing. And partly because this is something that I have tried to make proposals on many years ago. There is no particular resource constraint on ASNs these days, and the important thing from the point of view of the RIPE NCC as a registry is not to try to tell organisations or people what they can and cannot have, it's to record that information correctly. So, if there is no particular restraint on a resource, you know, and if people want to have a private ASN, there is no big deal. That kind of gets back to the issue of garbage collection, and I have made the original €50 per resource assignment was something that was put into the old 2007‑01 proposal, which was the contractual requirements for assignments. And that was put in there very specifically to implement a style of garbage collection, and that is critically important to the entire process of maintaining an accurate registry. It was very unfortunate that the RIPE NCC Board shot that down on the recommendation of a previous pricing task force, but they did. But now it's back again, and because it's back again, I don't see any particular reason for maintaining the multihoming requirement. We have accurate registration, we have garbage collection, we have adequate resources. No big deal after that.
(Applause)
LEO VEGODA: Thank you. Lee, if you could keep it relatively quick.
AUDIENCE SPEAKER: I think so. Lee Howard. The temporary transfer policy, in rem co‑'s terms of wanting to clarify it for people who are reading things from outside without context, it does not make clear that a temporary transfer does not trigger the hold period, which I had to ask staff, and it does not trigger the hold period. After that follows other kind of transfers. It also isn't clear that it's temporary transfer can only occur for a maximum of one year. That's an important detail that ought to be in policy. So, that's, we're going to have to come back and work on that. I just wanted to raise that to the team.
LEO VEGODA: Thank you.
AUDIENCE SPEAKER: Silvan. I would like to ask everyone to still join us on the first proposal, because I believe the IPv6 PI assignment policy will also clean up the current fragmentation of PA space being used as an alternative for PI so this should be worked on please.
LEO VEGODA: Thank you very much.
Okay, so we have a lot going on at the moment. We have got three active policy proposals, and we have got an idea for a fourth or a fifth. So, we're going to be busy. We have got a mailing list. I would appreciate if anyone has reflections as they travel home and they want to share them, please write into the mailing list, share your reflections. It doesn't have to be in response to someone else. You can just go and comment on a policy proposal. That is all very helpful. And with that I'd like to thank you everyone who joined us online on Meetecho, everyone who joined us in the room, it's been a really great session today, and now it's time for lunch.
(Applause)
Lunch)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
