Part 2 of Address Policy session
RIPE 91
23 October 2025
2 p.m.
.
LEO VEGODA: Good afternoon everybody. Welcome to the second session of the Address Policy Working Group. We are three co‑chairs, Franziska, Alex is modelling participation via Meetecho, and I am here, Leo. We have three big meaty agenda items in this session, and we also have some time reserved for the open microphone. You will notice that we are in a different time slot than usual. If you want to talk about that in the open microphone, whether that is a good thing for you or not, that is just as welcome as other input that you might want to discuss, including follow‑ups on topics discussed in the first session.
Just as a reminder, we have a Code of Conduct. The Code of Conduct is essentially that we should treat everyone with respect, be polite. And now, it's time to move on to our first agenda item of this session. Jordi will be speaking about proposal 2024‑02 on expanding initial allocations to /28. So, if Jordi is ready.
JORDI PALET MARTINEZ: Rinse is presenting, not me.
RINSE KLOEK: Hello everybody. I am on stage now.
Thank you everybody from stormy and rainy Netherlands, I hope the weather is much better in Bucharest. Unfortunately we can't be there, Jordi and me, but we will do the update of this policy proposal remotely.
This proposal we started a year ago, it's the IPv6 initial allocation /28 and extension to /28 and I will give you a short update.
First of all the motivation for this policy proposal, the motivation is that we want to have a revision of the initial IPv6 allocation to foster IPv6 adoption in the RIPE NCC region and it's an update of the RIPE‑738 document. The main thing about this proposal is that we would like to change the initial allocation size for a PA from a 29 to a /28, that's a so‑called Nibble boundary, because the whole Nibble is dedicated to an LIR, and also for example, it refers GNS delegation will be easier, you can have one single delegation and don't need to create a lot of delegations if you have a /29.
Another thing that currently for all initial allocation the RIPE NCC issues a /26, so, there is still space reserved for enlarging the current allocation from /29 to /28. I think it is already been done about ten years ago, so, in this case 90% of the current allocation can be extended to a /28.
The current status of this proposal. It's the fourth version. So, we have had some comments and some input and we updated according to this input. Thank you for that from the community. And also thank you from the RIPE NCC. They also made some impact analysis and gave us some feedback on version 3 of this proposal, so that's the reason we are now on version 4. This version 4 only changes to chapter 5.7, that's the part about the extension for the current allocations. Also we updated the title, the time has been changed to also add the extension to /28 in the title.
Then the policy text on the left side you see the current policy text about the initial allocation size, the only thing that is changed in this chapter, 5.1.2, is that we changed the /29 to the /28. So, LIRs that meet the initial allocation criteria are allowable to receive the initial allocation up to /28. It's possible for an LIR to choose that the only want to have /32, if they have not so large v6 requirements. They can also choose to have a 31, 29 or a 28. So it's up to the LIR doing the request what they would like as an initial allocation. Next to that if you can submit documentation that you need larger than a 28, you still can get an initial allocation. So if you have for example, you need a lot more address space you can prove that you need it for your deployment, that you still can get it. That also stays the same only it changes to a 28.
Then the next part, chapter 5.7, it's about existing IPv6 address space holders. On the left you see the old version of the document, that LIRs that hold one or more allocations are able to request an extension of each of these allocations to a 29 without providing further documentation.
What we did is we changed the 29 to 28, but also added an extra sentence that "Only the allocation that are originally issued directly by the RIPE NCC as a single prefix can request an extension of one of these allocations...". So only allocations that are directly issued by the RIPE NCC, so for example you can spread out an allocation and transfer that, and those are not eligible to get extended, only those are directly issued by the RIPE NCC to an LIR can be extended, and only one of those. So for example if you have multiple allocations because of some transfers you have done, you can only choose one of these allocations to be extended to a 28.
Then also the change from the previous version, version 3 in this chapter, we made it a bit more simple. The main changes that we went back from, the member to the LIR in version 3 we decided to use the member that only a member that host its one or more allocations, but we got a lot of feedback folks from the RIPE NCC that they didn't like that change from LIR to member, so we switched is back to LIR. I will explain to you later the reasons we did that.
The explanation for this version change. Like I said LIR instead of member to strongly advised by the RIPE NCC, they made an impact analysis for version 3 of the document, they stated removing the LIR to member reference is likely to lead to technical and governance complications and therefore considered to be a high impact and a high risk change that will have significant impact on the the systems and processes that we use to implement policies.
First of all, they are, the RIPE NCC states this could be precedent for further policies currently in the policies we always you use the LIR for technical entity. So, the member is more the administrative entity and the LIR is the technical entity. And they like to keep that separate. This is the reason we stick back to LIR.
Next thing also very important. If we used the word "Member" then the LIR portal, like the name said, is always based on an LIR. If you have a LIR portal you manage one LIR, and if you have one prefix per member, one exchange per member, then you need to check, for example, if you have a member with a lot of LIRs and one LIR extends their 29 to 28, then you have to have some extra checks to see if other LIRs under the same member have done that already. So, it can create a lot of issues in the current process that NCC uses to manage resources. So that it will create a lot of complexity and also needs to have extra changes. Also last but not least, impact on governance and policy enforcements.
So, this is the last side. We like to make it very simple, so, we went back to LIR. We also made the text a little bit more easy and now it's just very ‑‑ so the policy for new LIRs is for the current LIRs, yeah, it's more the same. So, if you start a new LIR, you can just get a 28 and if you are an existing LIR, you can always request one extension to a 28. So it's a bit on par we think.
Also, there was a lot of discussion about stop dialling, and last year RIPE NCC also made an extra document about currently if you have an LIR and want to transfer 29 to another LIR, then you always get the question if you really need it so they applied the current policy about that you need to provide documentation that I need an extra 29, so currently RIPE is also asking that if you do a policy transfer, no merger allocation, so it's only for policy transfers. And you also see the effects in the graph about the number of policy transfers per year. So in 2024 it already went a bit down. And this year it's currently way lower. Although maybe we'll have the end of the year transfers will be still expect that this extra check of the RIPE NCC will have the results and will also block the stockpiling.
Okay, this is the short update of my presentation. If you have questions or comments, feel free to come to the mic and Jordi will also join me and also be able to answer the questions. Thank you.
FRANZISKA LICHTBLAU: So, do we have questions in the room and/or online? Nothing online yet. Anything, anyone in the room who wants to comment? Everyone here is fine with what has been proposed. No comments, no additions. We don't have anything online. We don't have anything here. Then I think we continue this on the list and we'll jump to our next item. Thank you Jordi and Rinse for presenting.
(Applause)
The next talk now.
URBAN SUHADOLNIK: So, this is the update on the ASN requirement policy version from me and Tobias, Version 2.0 is on the mailing list and in discussion phase right now. There was going to be version 3, but we need more feedback from all of you to continue. So, to refresh what has been done so far; so me and Tobias were asked by the community at RIPE 89 in Prague to look into removing the multihomed requirement with 32‑bit ASN numbers. They are not a scarce resource anymore, so our policies maybe should reflect that, so some of the things that have been done in the past maybe are not needed anymore. On the other hand, currently, according to information from RIPE NCC, so this is what RIPE database believes, 50% of ASNs are not multihomed. So they don't follow the current policy.
There is some caveats to that. Some are just not visible, but let's say that's the number that the RIPE NCC is using.
So, with the new ‑‑ with this policy proposal,ing the multihomed requirement goes away, but with the multihomed requirement going away, I think we need to look into something else to hold, to block or to limit exponential increases in ASN requests for abusive or bad practices. So, the idea is to, for the new requirements on multihomed, you have to peer with a third party, and with the new routing policy, that includes the prefixes. So, in multiple locations you don't have to use the same ASN anymore.
So, the aim of the policy is also with the current state of the not enforced policy many network operators that are not part of this community, well the ones that know how things work just lie, and I don't think that's okay. And the others that don't, are blocked from asking from ASNs, because they read the policy and they see they can't comply or they see it as complex.
So, the feedback on Version 1.0 was that it's too long. That there are unclear requirements for the first ASN and the existing ASNs. And the unclear role and obligations of the RIPE NCC are Registration Services.
So this is the current policy. The one actively not the proposal. So the multihomed requirement. And this is the new one and it's a built long if I put it like this. So I'm going to divide it into three sections.
So, the first part applies to the first ASN. LIRs and end users may be issued the first ASN upon request without justification.
That just acknowledges we have enough 32‑bit ASNs, if you need it you can have it and there is no problem with that. Also we don't know yet how you are going to use it, so...
.
There is a thing here, it says to note its end users and LIRs. So if you are part of an organisation that has multiple LIRs, you can do this per LIR, and I'll come back to that later. And you can issue additional ASNs with different criteria.
So the new thing I think maybe the main rewording in Version 2, is the general requirements for ASNs, before it's at in Version 1.0 there was the first ASN without justification, the next one, the requirements, it's not exactly clear what happens to the first one. So now there are ‑‑ the idea is that the ASN requirements apply to all ASNs, so including the first one and the existing one, and the main thing, as I said before, is peering with a third party.
Now, there is one case here that we have noticed as some network operators ‑‑ so there is the meaning of third party, there have been many questions on what that means. Essentially, it means not you. And so you shouldn't only single home uplink to yourself. And in most cases, that's okay if you have a global transit network and you have a subsidiary in a certain country, there are two separate entities. So this is not yourself. We have noticed some problems, that's why before it says LIR or end user, in case there is an organisation that has a global transit network and a domestic network the same country under the same organisation and there is going to be an example later. We need some feedback on this. We're thinking currently to just split it based on LIR. So that kind of organisation I don't know how exactly organise right now, I think they mostly have two LIRs for the global and for the domestic use case.
And if you have under the current policy, if the ASN is not visible in the GRT, technically there is nothing that says that's under the policy, so right now it's just you have to provide documentation, and that's fine.
Or, when we come back to the information from RIPE that ASNs are not multihomed, you can just provide documentation. How that will be done depends on the Registration Services, it might be way simpler.
So the last section is what you need to do to request an additional ASN. So after the first one, you have to provide a unique routing policy which includes the announced prefixes, as I mentioned already before, and a reason why the existing ASNs cannot ‑‑ existing inactive ASNs cannot be used. The intention of this is that you already have ASNs that are not in use, or if they don't follow the policy, that you ask yourself: Hey, could we use one of those? And you might be asked that. It's not intended to specifically block, and depending on the decision of the ‑‑ at the discretion of the RIPE NCC, this can be waived. So for example, if you have a case of well, we just didn't get around to it, the project has been postponed, you write that. Another example is a bit later, if something is as a result of a merger, that can also be explained.
So, this is the whole policy again, just some parts that were not in that section. So, you should use an ASN in six months after it has been issued. The intention of this is a bit reversed, it means that for the six months you are off the hook for anything at least by ‑‑ that's the intention. It doesn't mean that after six months you have to return it, but if you, I don't know, you have an audit, three months later you say, well, six months haven't passed yet, I am off the hook.
And yeah, I think this was everything from this session, I'll even explain what is, what is the meaning of third party.
Now, edge cases:
So, I think that current, like for the typical network, this is a reasonable requirement peer with a third party, but we have some edge cases that we have ‑‑ that mostly uncovered, and talked about, and that raised during this RIPE meeting. So the first one is what was already mentioned, it's the ‑‑ actually this is two cases, but in case this is an example that I found of British Telecom, they have a global transit network and they have a domestic network. And as far as I know they are under the same organisation. So, in this case, I think the idea is that ‑‑ and this is absolutely okay, I showed this edge case, this technically falls out of the policy and this is something that we need feedback on and more examples to figure out what to do, but one of the solutions for this is, if it's a completely separate business unit, which I think in this case it is, it could be ‑‑ maybe it already is, a different LIR, and they are just the same organisation so two LIRs per organisation, this could be fine.
On the other hand, actually this is usually not as big of a problem because I did pick this kind of graph from BGP tools. This AS is actually present in IXPs in the UK, so it does peer, so it is under the policy. But there might be some cases of some ASes that are not. The second case is plus net. So, plus net has been acquired by British Telecom. It used to be an independent network, now actually if you look on the Hurricane Electric, as I just says, British Telecom, British Telecom and British Telecom. And this is a bit of a more out of the policy. As far as I know they want to merge these two networks but this is something that's not intended. This AS does peer with CDN, so it's also technically under the policy but may be a bit out. I think that in this case maybe a bit hand waving and say, it's been a merger, it's going to take time, eventually it's going to be there, maybe it's not that bad of an example.
Then we have edge cases of special projects like the free transit project by Openfactory. They use a special AS for that. Maybe it's nice ‑‑ so just so, you know, the free transit project gives free transit over usually a GRE tunnel to personal AS number. This is my own AS number, and maybe this is a marker, it's not that bad. But this could also be just put in the Openfactory ASN, but this is technically outside of the current proposal and we should figure something out.
Then you have the VeriSign case. So, for a long time nobody from VeriSign even talked to me, so I didn't ‑‑ and they are under ARIN. In VeriSign's case, they, for their A root DNS Anycast network they used an ASN number per location. And I thought it was an example ‑‑ this was an exception because I haven't seen it anywhere else. There is actually a best practice RFC on this, and this looks like this. So, every location of Anycast only uplinked to the VeriSign transit, to the VeriSign transit AS when then goes onward.
We also have other special projects that I think it also makes sense they are in a special ASN even if they are uplinking to the same one, that's a BGP block, so they want to move it to a different AS number. So ‑‑ what I noticed that most of these cases have in common, that that's, I would call it an atypical network, so those are not networks, so if I go back, I think ‑‑ so okay, this is an Internet measurement case, this is an Internet infrastructure case. Okay, this is different. And this is technically under the policy and just caused by legacy. So, maybe this cases they are measurement and atypical networks maybe they should have a specification, in the policy you can peer with yourself in case you are running a network for a measurement educational purposes or like a service that's not meant to connect customers. But this is where we have landed right now.
So, questions and feedback, please, please, please feedback so we can figure what to do. But, at least I think that the main part of the policy for typical networks is fine, and as I said, there is going to be a v3 where we cover the rest of the cases.
FRANZISKA LICHTBLAU: Thank you. Let's start in the room. Gert.
GERT D÷RING: Sort of like responsible for the previous AS number policy. When Sander and I were Chairs, we had a policy proposal to simplify what we have and that didn't fly. So, it's good that a new attempt has started.
I think that the way it is is fine. So, putting all the special cases in there is not making a good policy document. So, this is short and concise, and you can read it and say yes, this applies to me.
What I would not do is to then receipt the retroactively apply it to ASNs that have been given out before. So all the stuff you find in BGP out there today should not have to be reevaluated by the new policy, because technically, you cannot do that. They have been given the AS number by somebody under certain rules, and you don't change these rules later and say oh now you don't fulfil the rules anymore and take it back.
We had to do this once with the PI and the contracts, and that was not to everybody's liking but in general, basic contract law says you cannot do that unless the contract has a clause that says we can take it back at any time if we feel so, which it doesn't.
I'm neutral on the intent itself to make the AS numbers easier to get. I can see that there is demanded. I have some reservations on the number of AS numbers showing up in global BGP, because they are not free, even if it's the same number of prefixes having more AS numbers means other members used. So it's not global is ever free. But I will not say I don't support this, because I don't think there is much harm in it. What I would like to see, and this is a tricky bit, is to keep the reclaim mechanism by the cost, because if somebody goes for stockpiling by inventing very nice schemes about he and all his friends peering with each other and using up thousands of AS numbers, if they have to pay $50 per AS number every year, it will be annoying enough to not do that. If you need an AS number for your enterprise, 50 bucks is nothing, but if you make it completely free, we put the burden on the NCC to actually go and chase all these 10,000 numbers every year again and again. So if the policy loose, we need to have a financial mechanism, which is not for the Address Policy Working Group to decide, but we can at least issue a statement towards the Board and say this is important, this is good stewardship. Yeah, that's basically it.
URBAN SUHADOLNIK: Thank you so much. Maybe some things of this that ‑‑ thank you for all the feedback, all will be considered. The thing that I am worried about is that I think Ä50 per ASN for a business is nothing. I don't know how much licensing costs for switches is, they are probably more than Ä50 per year, for much of the hardware and software. So, I didn't mention this. I would worry if somebody would come up with like a product that would use public ASNs, I don't know for internal fabric. Or that becoming viable in, I don't know, in five years. So I am a bit like Ä50 is great for let's say me on a personal AS, for business is nothing. Mostly this for ‑‑ at least how it is written now and that can be changed, and that's what the feedback is for. Is like, we kind of need to decide do we leave everything that has been done until now, as you said, not retroactively looking at things, or the way it's written right now it could actually technically be blocked from new ASNs because we already have them, and I would like feedback from the community, should we do that or should we should we not?
GERT D÷RING: I think that is fine because if somebody comes and said I have a need and you say, look the database says you have 20 AS numbers, why not use one of those? They should have an answer to that. If they say they are all used internally, okay, a good answer. If they say oh yes, we had forgotten about them, even better.
Actually I forgot another comment. You say "And end users." There is devil in that fine print. What is an end user? What makes me different, me Gert Dˆring, personal from me Gert Dˆring small business. Under German jurisdiction, I am not the same as me as the company. So, am I two persons or three or four or whatever? So, identifying what is an end user and what is a different end user might actually be tricky. But it should not go into the policy. Because you cannot write up all the educators.
LEO VEGODA: We have something from online. I have a comment on Meetecho from Jordi Palet, the IPv6 company. "Maybe instead of third party views, third party/ISP or different business unit, when it's the same organisation. Some special cases documented in RFCs and experiments are also supported. I think that covers all possible cases."
URBAN SUHADOLNIK: Thank you Jordi for the feedback.
AUDIENCE SPEAKER: David. This is more of a comment, not necessarily a question or anything. I am personally in favour of lifting AS restrictions a little bit, because as you have said, the 32‑bit AS kind of removed all scarcity, but encouraging the creation of new LIRs for specific business purposes isn't something that is ‑‑ I am terribly in favour of, just because the creation of an LIR also comes with areas of privileges, such as voting rights in certain scenarios, and for my company specifically, we have got eight different LIRs right now for, due to historical reasons with mergers and everything. And right now, there is a goal of moving everything into one LIR, with the ability to keep our ASNs and still have our infrastructure work as it used to before without larger migrations, because renumbering is a very large undertaking in large organisations, so maybe suggest this is of course outside of the scope of this Working Group, but maybe this would encourage an exponential pricing modifiers and numbers, ASN numbers, to prevent orders. So, for example, the first ASN just costing Ä50 a year, the second 75, the third 150, because a large organisation isn't going to care about these numbers. But if you are going to hold them and have hundreds of ASNs this is going to really upset your balance sheet.
URBAN SUHADOLNIK: So thank you for the feedback. It's a very good point about the LIRs and maybe I should ask Athina later how that works, the specifics. The problem I have is that I don't know exactly how to define what is a distinct business unit, if it's a subsidiary of a company organised like that, it's a different legal entity, that's clear. If it's a different business unit, I don't know where to draw the line. So, the LIRs is as a result of that but thank you for pointing that out. Because I think we should think a bit more about that. Thank you.
MARCO SCHMIDT: Marco Schmidt: We had already some conversation in the hallway, and I mentioned already to you. I think it's good that the current version is not too specific trying to capture all the edge cases because obviously there will be another one, and the more specific is a policy is less flexibility it gives, and the sentence at the end right now is indeed good, because we know quite well what is a reasonable edge case and a third party. So if it stays like this, we can know best and we do indeed like what Gert says, we see somebody has already several ASNs, we ask, they give an answer and if it makes sense that's fine and that also takes away concerns about retro activeness and so on so I think, so I would recommend not solving edge cases in the policy.
LEO VEGODA: I have two comments from Meetecho: "How will RIPE NCC define and assess intermittent usage cases, for example, how temporary can the use be and what makes a benefit statement sufficient?"
URBAN SUHADOLNIK: Thank you. That's one of the cases that I did not go into that one.
So, there are cases where research institutions have a 16‑bit ASN used for measurements that sometimes pops up every so often when they need it or they run this. Of course, sometimes they just keep it for a longer time so they can do that. The other case is some events have their own AS numbers that happen every year, every two years, so on. The general idea is the ASNs should be in use, but it's meant as maybe more like not abandoned. If an AS is allocated for one purpose and it's used once per year only for this, I think that's okay, as I said before if they want to pay for the Ä50 peer, that's fine. And most of the time those ASNs are well either properly in use or out of the GRT where they don't cause memory problems and so on. That's what's meant by that.
MARCO SCHMIDT: We also talked about this when there is actually another policy out there for temporary assignments including AS numbers, so that was one concern that people might get confused what is an intermittent usage, what is good enough, what not. So, we might have to think about it an impact analysis. Also what I mentioned that the temporary assignment policy works, so somebody who needs every year for a yearly conference an AS number in an IPv4 range can get it. So ‑‑ but also for example, we would not be super strict if an ASN is requested and somebody says oh we have several conferences over the year, just ‑‑ yeah, we can get it but there is a bit of an overlap with another poll that maybe needs to be also discussed. That might be confusing.
URBAN SUHADOLNIK: So, I'd like to add what I would imagine what the intent with the benefit statement is we need to like, for example, with the 16‑bit ASN, we need to measure stuff with the 16‑bit ASN and that's why we have it reserved for our research and sometimes we do that research. I think that's good enough benefit statement for that.
LEO VEGODA: I have a comment on Meetecho from Jordi. "I partially disagree with Gert. I am not asking for re‑evaluating previous cases which in any case is fully supported because members are bound to policy changes by service agreement, otherwise we can never change policies. However, same or similar cases must be supported in the future. This is archived with the text I just wrote in my previous point."
SANDER STEFFANN: I am speaking as an old Address Policy person. So the previous time the ASN policy came up, one of the worries was that people might request a million ASNs because there was no rate limit. These days there is a fee attached to the ASNs, so ‑‑ well if somebody wants a million ASNs, please keep sponsoring the NCC. But what problem are you trying to solve with your assignment criteria? Because, why do we need complex assignment criteria at all appoint? What is the problem we're solving with it?
URBAN SUHADOLNIK: So, it's I believe that Ä50 is not something that would stop somebody that would want to stockpile ASNs.
SANDER STEFFANN: So?
URBAN SUHADOLNIK: It's a hard question. But the example that was given for IPv6, that there could be a shadow RIR, I don't think we'll have for ASNs though. But still I would avoid somebody deciding to use ‑‑ so, I think that ASNs should be used similar to now when they connect to the public Internet then they are outward facing, and an internal network should continue to use private ASNs and as I said before I think that Ä50 for ASN would not stop that in some cases.
FRANZISKA LICHTBLAU: From what I have been hearing also in the hallways, that is definitely the fundamental question we probably also should take to the list, then everyone can really participate and in order to facilitate people to engage in your discussion, let's just quickly recap what are your next steps because what we have heard here so far roughly is that the current version people seem to be interested in. But you listed more cases. Is your plan now to go and cover them in the new version or just...
URBAN SUHADOLNIK: Yeah. So the next steps is of course going through everything again. I would like to ask for as much feedback on the list as possible because this is not ‑‑ I'm doing this for the community, I'm not putting this on others. The next step is I think for edge cases is maybe one sentence cover all of them, those are special cases, and cover them by that and open the door for experimental usage, like that. I think that's mostly it. Some parts might be removed from this based on the feedback if it's, if it specifies too much.
FRANZISKA LICHTBLAU: This is for us to have a way forward to know what we expect.
GERT D÷RING: We might actually put a sentence in there that says AS numbers are given out freely without any criteria as long as there is a yearly fee attached by the general membership. If that fee goes away the number policy stops being effective and we stop handing out AS numbers. I am curious to see the impact analysis on that.
URBAN SUHADOLNIK: What if we write that this policy starts applying only if the fee doubles..
GERT D÷RING: As long as there is a fee. So in the end it doesn't matter if the fee is Ä10 or Ä50 or Ä100. It's inconvenient enough to have to pay something every year that you considered whether you really want it. Even if it's just Ä5 but you have to do it every year it's annoying and to teach your accounting department to pay these Ä5 every year will be a painful exercise. If you need the AS number, fine, if you don't need it you don't do that. And indeed as Sander said, we could do away with most of the criteria if we just say but it must have a reclaim fee. But that is ‑‑ we cannot decide this. But we could do, put it in the policy and say it's free as long as, and then put the burden on the AGM.
FRANZISKA LICHTBLAU: Do we have something online? Or what ‑‑ Leo what are you waving?
LEO VEGODA: We have a request for Tobias to speak in the queue.
FRANZISKA LICHTBLAU: Okay.
TOBIAS FIEBIG: . I am speaking for myself. To respond to the idea just concerning tying fees to the policy. I think what this would result can be probably summarised as too much text. And as such I would very much caution against that.
FRANZISKA LICHTBLAU: Thank you. Okay. With that, I think you will take this on the list further. Thank you so much.
(Applause)
And the next one is Clara, and she will present an updated version of 2024‑01 on IPv6 PI assignment.
CLARA WADE: Thank you. Hi everybody. The original author of this protocols proposal was Tobias Fiebig, he can't be here today, but he is online, as you just heard him. I mostly joined as a co‑author to edit the proposal based on some feedback that we got back from the discussion.
So, if you were present at RIPE 90, you might remember Tobias's slide with the spaghetti bowl to represent kind of where the discussion was headed after the initial version of the proposal. So, I tackled it and made three bigger changes.
So, the first one was following feedback from the community it seemed that defining end site or redefining it was going to be a bigger discussion. So, we decided to just spin that off into a separate proposal.
The second change was in section 7.1, we made some changes to language, so it was simpler and we also removed 7.1.3.
And the third one is really just aiming for a more conciseness and removing some redundant statements from there, trying to make it more readable.
So, going back to the first bigger change, PI and PA have a joint end site definition and the proposed section in 2.1 was making a case to differentiate them. Most of the counter arguments that we received in the mailing list to this proposal kind of seemed to be zeroing on that issue being bigger than what it was being proposed in the language there. So we, as I said, decided to separate that into another proposal that will be coming up. And aside from that we also simplified 2.6 to make some clarifications on what are the permitted and not permitted non‑PI assignment use cases.
The second change regarding 7.1, so there was broadly consensus on introducing PI assignments at the nibble boundary and having an aggregation principle for PI. Some concerns were expressed regarding right sizing PI assignments. For instance if someone actually needs a /46, but they are getting a 44, that's a lot of unused space. In reality, we need to remember that the scale of IPv6 is massive, and we're setting them up for the long term. I don't think I can even say that number, but eleven zeros right there.
Aside from that, if ‑‑ there is a section in 7.1 as well, that's 7.1.2, where we were discussing what happens if the extension to the next nibble boundary can't be granted because that space is unavailable. There was more prescriptive language originally that kind of stated the organisation or the operator would need to re‑number in order to get a bigger assignment. We ‑‑ well we still aspire to that obviously. We have made this more of a "May" rather than a "Should" in terms of them being rented that space. In a similar vein, 7.1.3 was also too prescriptive about how we're handling those that have existing PI assignments and policy really can't micromanage how the NCC implements in their end. So, we removed 7.1.3, because it was also reiterating a lot of concepts that were already addressed in 7.1.32.
And in general, we removed some redundant statements and we kind of combined all the purpose and considerations that were previously listed under each proposed new policy change into one essentially because the concepts and the rationale behind it are still the same. Please read the new version I posted on the mailing list. We are down to six pages. So hopefully it's easier to take a look at it because last time we heard from a lot of people that they just couldn't dedicate the time to read it. So, far we got one response in the mailing list, one‑off, but generally the feedback has been, you know, how would the requirement of it be in the same geographical insight be implemented? There is a suggestion perhaps the geolocation attribute. And another one that would be sent to the Database Working Group. But, if there are any comments or questions ‑‑ oh, and the new version will be posted after RIPE 91 for everyone to review, but it is available on the mailing list.
FRANZISKA LICHTBLAU: Thank you. Clara. Do we have immediate feedback in the room? Do we have anything online? No, okay. You are released. Thank you so much.
(Applause)
We'll continue on the list with this. If I'm not completely mistaken, that brings us to the Open Mic session. So we have a lot of time left for all the things you want to bring up, you want to talk about time slots, new proposals, ideas, things we should do different.
AUDIENCE SPEAKER: Hello, I have a let's say question to the community. We hit an issue with the policy. The current policy does not allow transfer of IXP blocks for the moment. So, my question is there are some cases and we hit one of those cases where we want to transfer basically to transfer one IX from an entity to another, it says as an IX but the one that is doing all the work is another entity, and this is not permitted. Well, there has to be some form of merger acquisition which may or may not be the case, we hit one of the cases when it is not the case, so my question is: Is it worse a policy that says that IXP blocks can be transferred by keeping the same conditions as the initial one? So it's still an IX, it stays an IX, but it can be transferred to some other entity without all the legalese that says this is a proper merger or a proper acquisition rather, because there is two entities keep existing as separate ones.
MARCO SCHMIDT: Maybe we can later meet at the service desk because there is a scenario that you describe actually we do allow, we have it occasionally that an IXP was one by one company, another takes over the peering LAN and so on, and there we are a bit more flexible what documents we accept and so on. So, I would like to look into the details. But the way how you describe it, it should be possible in the current scenario.
AUDIENCE SPEAKER: Because the answer ‑‑ the situation that I described to you is, the answer that I get in the transfer ticket. This is not possible and well I stopped going further, but I am wondering...
MARCO SCHMIDT: Let's maybe talk afterwards, because for this scenario we have a solution right now at this point. What you described.
GERT D÷RING: Commenting on that. So I haven't read up in the policy yet, but it might have been just an oversight, because at some point we tried to make a transfer policy that just applies to everything and have no special cases, special rules. Did we forget the IXP prefixes? Oh, so somebody could just do a policy proposal to bring them in line. It's great that the NCC actually makes things possible when needed, but having to have to go that extra round means the policy is not good because that's a real life scenario, it should be working.
MARCO SCHMIDT: No, actually the policy is clear on that. All resources are allowed to be transfers unless another policy forbids the transfer. And IXP is currently says they must be returned if no longer being used. That's why it's one of the few edge cases ‑‑
GERT D÷RING: Technically they are still used, just used by the same network, run by a different ‑‑ so maybe we can clarify this.
MARCO SCHMIDT: Okay.
GERT D÷RING: I actually have something else.
ANGELA DALL'ARA: To add something on this. There is even another inconsistency, if I can signal it, and somebody in the community wants to work on that, because we have this specification for IPv4 addresses for IXPs while IPv6 addresses can still be transferred, are not excluded from that, because in the IPv6 policy there is not a specific exclusion from transfers. And let's say that the exclusion comes from the fact that the return is mandated, if the holder is not applicable anymore. So, if somebody wants to work on that, I'd welcome any input. Thank you.
FRANZISKA LICHTBLAU: We are good on that topic. You found a very interesting problem. Thank you. We will try to figure it out. So I think you were first, and then Sander.
GERT D÷RING: You asked on whether the new meeting slots are to the liking of the group. And... no, for a very specific reason, and I bumped into this trying to talk to the Chairs before the lunch break, and all the Chairs had to run away to the Working Group Chair meeting. So, having a two slot Working Group on Thursday afternoon is inconvenient.
FRANZISKA LICHTBLAU: I saw that. And actually, I don't think there is really anything that bars us from being probably a little bit later for the lunch or something, what we can see to figure out. This time we had agenda constraints. Some people were actually happy about the break, but you are right, especially the Working Group Chairs, we can see what we can do about that, that was definitely ‑‑
GERT D÷RING: Usually after the first slot you go talk to the Working Group Chairs about things that have become relevant, than having a rush there is needless.
FRANZISKA LICHTBLAU: Feedback received.
SANDER STEFFANN: Again speaking as an old Address Policy person. One thing, it's more a generic comment, looking at several of the proposals that have come up in the last couple of years. There seems to be a tendency to want to specify everything and be extremely precise and put in all the requirements. Like, that's why I was like, why do we need these requirements? And I would encourage the Working Group to think about the balance between making the policy more complex or realise that there might be a 0.01% of people who might slip through the requirements at some point. But accepting that that last bit might be okay. So, think about the balance between trying to solve every little edge case or keep the policy simple and generic. And I feel that the balance currently is swinging towards the very complex policy text which makes it harder to maintain, harder to implement, so from personal experience as my years as Address Policy Chair I would urge the Working Group to consider swinging back to keeping it simple again. But that's just an old grumpy guy's opinion.
FRANZISKA LICHTBLAU: The Chairs, yes, we have realised that as well and many people commented on that. I had a couple of hallway conversations with people who were involved or adjacent to these proposals. And while you are making a very compelling simple case, they are apparently some underlying concerns that before we basically go to your statement, I think as a working group, we also should address, because there seems to be some not fully clear understanding what an interpretation of policy means, what the NCC's amount of interpretation room is, what our mechanisms, if something doesn't work out, so maybe we just need to have a broader discussion. But that is just my summary from what I gathered in the hallway, we are not entirely sure how to capture this discussion but it feels like we could have it.
SANDER STEFFANN: Perfect. Thank you.
AUDIENCE SPEAKER: I would just like to say the new format of having lunch between Address Policy is awesome. Thank you.
FRANZISKA LICHTBLAU: Excellent, maybe we can make even more drastic changes and switch the PC and the Working Group Chair lunch, I mean that would be ‑‑ we need to see what works out. I think Mirjam will already love the rescheduling again.
Okay.
LEO VEGODA: We also have Tobias in the queue. And let's see if I can click the right button. You should be able to speak now.
TOBIAS FIEBIG: Looking at the agenda, I am basically involved in two thirds of the policy proposals. I think that as another issue the Working Group has to think about, making policy in the Europe NCC service region is not going to the AP WG like two times a year when there is something in a meeting, but it actually also means like trying to work on this policy. This policy will not get simpler if nobody does the simplification things. I mean I'm not the most simple text writing person, but in the end, there is also a lot of spaghetti that has accumulated over time and the process of everyone having good ideas which should be accounted for and should be covered, actually contracted a lot to the spaghetti over time, especially for 2024‑01. So, if we want all these things and if we want to have a better policy for the service region, we need a couple more people to step up and do things.
FRANZISKA LICHTBLAU: I can only agree. Thank you.
Anything else? Because I don't really see the queue from here. Nothing online.
Okay. With that, I think we give you back a lot of time. I think we are going to do an early coffee. Again the usual reminders: You can still rate for the Programme Committee. Remember if you are registered to rate for the NRO NC, and with that you get much more coffee than you expected. Thank you.
(Applause)
.
(Coffee break)