Address Policy
Part 2
.
FRANZISKA LICHTBLAU: Okay. Everyone please find your seats and welcome, also from my fellow co‑chairs, for this second session of Address Policy today. We have three talks lined up. And we are going to start with Antonious from Cisco on a discussion on AS reallocation. Those of you who have been, if I recall correctly, at the Plenary on Monday, already saw a little bit of the discussion that he already started and he informed me he is actually having a small set of slides to pitch this idea and what he actually wants is to talk to the Working Group. So, get your thoughts, come to the microphone and give him the input he wants.
ANTONIOS CHARITON: Basically I am going to go through a handful of slides to have everyone on the same page here. Just in case you weren't in the Plenary which is fine of course, and also because I looked into the policy a little bit more so I have more references here that I didn't have time for to present.
Let's go through the problem.
First of all, for whatever reason, an AS is returned back to the RIPE NCC. Let's say the LIR has closed, it's not needed anymore and they return it voluntarily, it doesn't matter.
The database clean‑up takes place, so, records are removed, and BGP is monitored to ensure that this is no longer present in BGP feeds.
Then we wait for six months to ensure, you know, that it's not going to come up again, or something else.
And then the AS goes back into the pool to be handed out to new entities that request an AS in the future.
And the issue here is that there are ROAs around probably in the future there will be ASPAs that give it prejudices, like the previous user may have issued a ROA for some prefixes pointing to the SAS, they may have forgot to remove them and they say yes, this new AS this new owner has some additional ROAs for IPs that don't belong to them. The thing I found is that happens often, almost one in 5 ASes that were handing out today has this issue, it comes with preexisting ROAs, and this is a concern because these are legitimate addresses from the previous life. Like from a previous company that had this space. So the new owner can hijack IP space and it would appear as RPKI valid. So this reduces the protections that validating networks can offer against hijacks.
And also, if you generate your prefix list automatically, they are overly broad, a lot of networks generate them based on BGP Q4 for example, which unless you point it into a specific instance, it's going to include all of the ROAs for this AS automatically there.
Of course, we slowly accumulate garbage here, we will have more and more ASes that are, more and more ROAs that are of ‑‑ they shouldn't be there but they still exist into our systems, we still have to fetch them, validate them, and they just increase risk. So we just pay the price for higher risk.
So, the first question is like, let's never recycle AS. The first potential solution, here is the IANA a policy it says that they give AS blocks of 1024 to the RIRs, so we can receive them at 1,000 roughly at a time. There is, however, like some additional location like after your first one, basically, you have to provide feedback I guess like some kind of documentation that you used 80% of your allocation to qualify for another block.
So, we cannot probably go and request 20 blocks of 1,000 ASes, unless of course you know IANA changes their policy which I think is going to be a difficult and long process.
The other thing is that for larger blocks, basically what they say here is that you can qualify for what you need for the next twelve months. So you always need to have enough head room, and how we calculate the run rate of every RIR is based on the past six months.
So, we probably, if we wanted to, stop this issue, like trying to prevent new ASes from being assigned with pre‑existing ROAs, definitively we may have to expand this six month period, because stopping the recycling by just getting a large number of ASes doesn't seem like it's easy. And I was trying to think what a good period for that may be, and you can see that like this pattern of ASes being assigned signed and then having preexisting ROAs and then stopping that and then having pre‑existing ROAs again, it happens roughly every pro years and you can understand more about the methodology in the Plenary. So, I was thinking perhaps that since this repeats every two years, every two years is that period, we need to move to maybe three years, I don't know, what's the right time frame is, so keep that out of circulation for a longer period of time.
There were some suggestions about monitoring, like alerting people that you have ROAs in your RPKI dashboard that are pointing to unassigned ASes, maybe even when you log in you see an alert and unless, you know, you confirm or you know you delete your ROAs, it doesn't go away. This would be software that either the RIPE NCC could build or we could have community software that would help with that.
Then we have encouragement perhaps in the automated assisted registry check. We can have some specific place where you get to review your ROAs and make sure that they are still valid, your ASPAs too actually, and that you don't have any unassigned ASes. Perhaps we can make this explicit in these checks.
These are the slides I had. I am open now to discussion, unless you also have questions, like if I went through this too fast, if you want me to explain something, well too many questions already.
FRANZISKA LICHTBLAU: Thank you very much. Questions.
AUDIENCE SPEAKER: I am Leo Vegoda and I used to co‑chair this Working Group, and I have also worked for the RIPE NCC and for ICANN in the IANA function. You did a really great job on this presentation, and I fully support everything that you are saying here. I think you missed the relevant part of the policy which is in point 2, it says the number of free ASNs currently held, and so I think if an ASN is not free to be assigned because it is legitimately held in quarantine, then the RIPE NCC, or any RIR, would qualify for additional ASNs, and I am sure that if we make a clear request to the RIPE NCC today, they can adjust their processes and no policy change is required.
ANTONIOS CHARITON: Thank you for that. It's indeed a good solution, I just didn't want to be the one interpreting this particular section.
LEO VEGODA: I am just pointing out what it is.
FRANZISKA LICHTBLAU: We have Rudiger on the remote.
RUDIGER VOLK: I think I am being heard now. Thanks for taking note of my remarks in the Plenary about ROA monitoring. And I think yes, the observation that there are problems is important. But, yes, the basic first thing that really has to be done, in my opinion is to make sure that address owners have sufficient tools to be really helpful for them to maintain their ROA set. And that's something that quite obviously cannot just be ‑‑ well, okay, that's something that actually has global scope. The thing that is biting us here is that the AS numbers are used as identifiers where people have the assumption that they are pointing to very long list identities. Identities are things that are or stay the same. The and obviously reallocating identifiers is kind of a very basic and fundamental conflict with the identity assumption.
So, kind of one thing that will need to go into the monitoring is to actually figure out whether an AS number still is identifying the same identity. That's actually not a very simple problem.
Obviously, returning ASes to the free pool and moving AS numbers by new assignments to new meanings or to in this where the identities are changing. Kind of, the most simple thing to do, obviously, is to make sure that AS numbers that are still tainted by references in the operating system should not be reallocated and just stay in quarantine. Looking at the identity question, I think one thing that we have, will have to figure out and that is probably less a thing of Address Policy than of some other Working Group, that when ‑‑ well, okay, the tools that are offered to the address holders for managing their ROA sets probably, probably should not just say, please enter an AS number here, but also reflect back something that tells the user in a more human recognisable form about what identity we are pointing to. And that mapping actually also showing up in the monitoring and well, okay, used for the monitoring ‑‑
FRANZISKA LICHTBLAU: Give the speaker a chance to actually go back to you.
RUDIGER VOLK: I think I am at the end of what I had planned to say. Thanks.
ANTONIOS CHARITON: Okay. Well there are several points there and thank you for these.
So like first of all, on the technical side, what we can do to the RPKI dashboard, of course yes we can spend more time, more resources improving it, and there is certainly room for that. I just try to understand how important it is versus the other things the staff has to do. And I guess depending on the outcome of this we can decide this all together.
In terms of the identity and never recycling them, would I say that if it's up to me and recognise in the recycle them, 32 bits can go along way. Those are famous last words for other technologies but forecasts it seems safer. So maybe it would be fine, but it's interpretation, so I don't know if everyone will be happy. We can certainly try.
AUDIENCE SPEAKER: Tobias. You may know I really like to get ASNs and if we do not reassign them I can very much I think for each 48 in my two 29s at 132, one ASN, then I can use them back and I can reassigned and I can do it again, that doesn't cost me money if they are not assigned on the 1st January. It's amazing, it means I alone could go through the pool and finally get a 64 bit ASN. This doesn't make you friends with implementers, with operators, and most likely unable to leave the room!
So, I think that this would be a technical solution to the problem. It's people not cleaning up, and everyone who once has lifted a flat chair and looked at the dishes knows this issue and this issue has very limited solutions. One is everyone does the right thing and I learnt that if people would just, if that is the start of the answer, it's not really an answer. The other one is somebody sacrifices themselves and just does the dishes or runs after all these people and is like, you don't want it, you don't want it, clean up your ROAs. And the last option would be get somebody with experience in something similar, so my proposal would be that the RIPE NCC hire a dedicated position, or somebody who works as bartender and has a lot of experience in cleaning up ashtrays from really messy people and their sole role is hunting down the people who have their ROAs left over and that would probably hopefully solve it. The cynical option would also be selling those ASNs and advertising the networks they are allowed to announce. That would probably also work.
ANTONIOS CHARITON: True, like hacked accounts or something, right. If ‑‑ just one thing to say here, that perhaps, you know, recycling, it could be that you know the same person can get the ASes again so we can ensure that the identity is similar. But I understand that you know if we just keep giving them out, eventually we are going to run out of them and then we need one 28 bit ASes with multicast. Yes.
AUDIENCE SPEAKER: There is a comment from the Internet. He says: "I agree with extending the quarantine period as well as checking if anything points to its like Peering DB, ROA route object or any RIR and so on".
ANTONIOS CHARITON: Yeah, like other databases by the way have this problem too. Peering DB, as you mentioned and IXPs have this problem on their peering LAN, they get a new member, they try to register the IP address and they can't because it's just taken by someone else and they have to go hunt them. So, yeah.
JOB SNIJDERS: Job Snijders. In reaction to Rudiger, I agree with everything you say, but we have to have a rule in this Working Group that the comment cannot be longer than the original presentation.
Okay. To the topic.
Can you go to the slide where you, about two and three years, please.
ANTONIOS CHARITON: I put numbers here this time for you.
JOB SNIJDERS: So having recognised there is a potential correlation to a two year cyclic event consequence sequence, saying maybe it could be larger ‑‑ for the room, we currently have six months cool down. The conclusion is six months apparently is too short because the collision rate of almost 20% is too high. Then okay you recognise there is a two‑year period that seems to correlate, maybe three years is better, I would go a little bit further and just double the two‑year period and say, a four year cool down period and then reuse.
The advantage of this is that there is some reuse embedded in the system, because I do think we need to conserve the resources in the long run, like the multiple decades. But also four years is, you know, planets come and go in that lifetime, and there is enough ASN space in the global free pool to allow such a long cool down. Or actually I don't think it's long. Like four years flies by if you are having fun.
So, I would say cool down period of four years would be fitting for this problem space, and if not, then five years from now will have another analysis. Thank you for the presentation.
ANTONIOS CHARITON: Thank you.
PETER HESSLER: Peter Hessler: You brought this issue to the Database Working Group like a month or two ago, quite recently, and in the discussions that we had while there was not a call for consensus, there was clear support from the community that upon returning an ASN to RIPE to enter the free pool, that we also delete any associated ROAs, ASPA objects etc., basically all the associated things from the RPKI side of the database. So, I just wanted to point that out to the room that there is some support from the community that I would encourage you to explore that here and maybe add that to, as a policy. Then further to Rudiger's point of, when does an identifier cease identifying that one individual? If this Working Group is not interested in handling that aspect, I think database would be happy to be your backup for it.
ANTONIOS CHARITON: The technical thing there was messing with people's objects, like, you know, if it's a delegated CA in an RPKI you can't really start revoking certificates. If it's APNIC that issued the ROA or the ASPA, you can't really revoke it, so there are technical issues with RPKI that are more complex than, you know, just database.
But yes, some of them, most of them can be cleaned up, this is true. On the other hand, there may be, you know, someone doing research or automation you never know but unassigned ASes are probably fair game.
AUDIENCE SPEAKER: For the ones that are returned that's really obvious for us. For the other cases we can work out a complex policy if we need to.
ANTONIOS CHARITON: Yes, I am saying it will be complex.
MARCO SCHMIDT: Marco Schmidt. Thank you again for bringing this to everybody's attention, and first off I want to solve a mystery that you raised at the Plenary that it seems to be raised in the beginning of January, the you saw some correlation with IPv4 and then that was just a coincidence. I looked into the data and basically what happened from the beginning of 2025, we handed out only recycled AS numbers because we had finished up the latest block from, that we got from IANA, and we had so many returned AS numbers that why we would have qualified to request more, we decide okay let's do the good thing and let's do the recycling because we protect the environment. Having said that, now we actually quite much lower of those numbers and for this recent point we well request a new block from IANA very soon and then the request you will get a fresh numbers, whoever is requesting AS numbers then.
Regarding the period, that cool down period, it's good to point out that this is not defined by any RIPE policy and so on. How long we do the current thing, it's an operational decision by the RIPE NCC based on best common practice and based on experience, which also means now, after this was raised here we will take this certainly into account and there is some quite easy operational decision to extend that period to a significant longer period. So I am happy to announce that we will do that very shortly. So that should take care of that problem.
The third point I wanted to raise maybe at this point it's a smaller issue, but as you can create those ROAs without any verification from the ASN, can we actually a problem beyond getting recycled AS number because you might set up a ROA and you have a type there or something like this, or you do create a ROA which currently unassigned the AS number or it's assigned somewhere else. It's still probably worth to look into it if there are mechanisms to give a warning.
ANTONIOS CHARITON: Thank you firstly for the six month comment and going back into the data. The other thing about the ROAs there is some validation still, I think private ASes you can create ROAs for, if I remember correctly I am not sure about that, perhaps we can also extend the validation check. If there is no legitimate use, we can see that as well.
MARCO SCHMIDT: It would be for example that any AS that is not issued to any RIR cannot be ‑‑.
IVAN BEVERIDGE: Ivan Beveridge. Can I request or suggest that if you notify potentially impacted people with regards to say, you know, via gooey from logging in someone you consider almost e‑mailing some because obviously there are some that don't spend much time ‑‑
ANTONIOS CHARITON: Of course.
IVAN BEVERIDGE: And the other possible thought with regards to try to clean up, I guess there will be a number that you will see that are totally clean, don't have any references, yes potentially at the point that you receive, you know, a returned AS number, if you kind of scan and it's clean, it goes goes straight back into the reallocation.
ANTONIOS CHARITON: Yes, that's also going to help recycling a lot. Like four in five probably.
AUDIENCE SPEAKER: Tobias. Concerning the four years suggested by Job, I personal think that the four years will not lead to cleaner ASes being reassigned, They will just make it more of a surprise if it goes wrong. So, I remain with the point of we need to do something active and it could be, for example, when an ASN is returned automatically mailing the contacts of the networks of the existing ROAs.
ANTONIOS CHARITON: Yes, I think e‑mailing people is the easy and the first part we should do. The thing is that, you know, maybe you can e‑mail them after some time to make sure, you can e‑mail them immediately but it should be very easy.
GERT DÖRING: I am not going to make friends with the next comment. We might consider sending a message to the NCC Services Working Group about an assignment fee for AS numbers.
FRANZISKA LICHTBLAU: We don't have anything online any more so with that closing comment I thank you very much.
(Applause)
.
Next up is Tobias, we already heard him talking a bit but now he is coming up back to the stage to give us an update on his proposal 2024‑01 IPv6 PI assignments.
The policy is now at Version 2. The comment phase has ‑‑ the discussion phase has been ended and now the authors want to proceed.
TOBIAS FIEBIG: My favourite thing, 2024‑01, together with Clara Wade who happily joined I think two meetings, three meetings ago, years fly by. Anyway, so this was initially started in 2024. The plan was that we get larger PI assignments to end users. So we are not bound to a single 48 per end site and if you have multiple end sites multiple none the overlapping /48s we wanted to switch to a Nibble boundary assignments just to make sure we can test case it in a somewhat smaller‑ish class of assignments/allocations. We wanted to get rid of some corner cases and issues with the sub‑assignment rules, and we wanted to clarify the end site definition.
Version 1 did that. All of it. I think Gert commented on that document with a very elaborate which I cannot really recite anymore, bus it was too long.
There was a lot of agreement on the list on that Version 1, but some of that agreement was also accompanied which board's like: Well I haven't read it but...
Or, I think this is far too complex but...
It's basically the best we have.
So the high complexity of the proposal was noted a lot.
So, we want the gist but not the complexity.
So, that's when Clara joined the proposal, and she got a little chainsaw and went through my text. Actually it might have been a rather big chainsaw, but major complexity traps got cut. So the changes to the end site definition that is moved to future work. The nibble assignments so that you can not split a nibble assigned assignment later on to transfer out parts and the detailed handling of legacy. So, pre‑change assigned PI resources was also cut because that had a lot of interdependencies cross dependencies and a lot of text.
What was left in? The clarification of sub‑assignments, the clarification of the maximum assignment size and reasons for shorter than 48 assignments and the nibble unboundary assignments.
.
How does it look? In section 2.6, we have the clarification that it is not allowed to fully or partially sub‑assign assignments to another entity. Meaning that technically, if you receive an assignment which has a purpose of being used for your organisation, you could theoretically at least make more specific database objects as long as the org responsible for the object remains the same.
We have a lot of clarifications around what you can do with PI, because there were a lot of concerns of using PI for purposes it's not supposed to be used for. For example, running an ISP out of a 48 because a 48 only cost you €75 a year in contrast to being a member.
There is also a limitation to a /56 which you can give to other people. So for example if somebody puts a server in your rack or if somebody joins your wi‑fi network, and there is a clarification in there that static addresses or this will be reworded, and I'll come to that later, if ‑‑ like, if addresses are assigned statically and not dynamically that's also not a sub‑assignment.
.
Then there is a lot more text to clarify that you can actually have different sub‑networks of your assignment used for different parts of your infrastructure, also different end sites as long as it is within one organisation.
And that you are not allowed, to and it's a bit weird formulation, any other use of a prefix formula assignment up to prefixes of 128 to connect a receipt end site of another entity to the Internet constitutes a prohibited sub‑assignment. What that means you cannot use these to uplink the subscriber or any other transport technology.
Then we have a change for 5.4, that is it clarifies that 5.4 is about IPv6 allocations, not assignments. Before that was for all assignments. So also for PI assignments. And a bit of grammatical clarification on address usage or routing requirements, to make clear that if you need more addresses or you have those routing requirements or have the end sites, you need something bigger.
And then we have an awful lot of text in 7.1, which is the new IPv6 provider independent assignment sizes. But what this essentially says is one 48 per end site in the smallest covering block by nibble boundary.
That is the nibble boundary part. And a suggestion to the NCC, not a requirement, if they hand out a block to at least think about that leaving that space free. If they don't, they don't. It's not a requirement to them. Implementation left to the implementers.
And if you get something larger and you cannot be extended ideally if you have a 44 and need a 40, you would be extended to the 40 and would keep the 44 as a sub‑network of the 40 you were getting because it was something free. If that is not the case, you need to re‑number and return the resources to the NCC. Well that is basically like if you no longer need it, you need to return it. And it gives you a six months renumbering period.
There were some questions and challenges brought up. So the requirements for having like not end users on that prefix etc., etc., and those are really hard to check for the NCC. So, you cannot really glass ball what will it actually be used for. People can and sometimes even do, I am as surprised by you as that, but people do lie, and the NCC is kind of, you know, not in a good position to smell whether people are lying, unless they are not smart enough to actually provide documentation of them lying.
It's unclear what happens if somebody is later found to actually be something they are not supposed to be doing with PI, but that is also a thing right now to a degree.
I think the idea of unassigning things forcefully that are in active use is not popular among RIRs, yes, I think that's a good wording.
Another issue is that users may receive more IP than needed, so for example if somebody needs just 15 /48s but receives a 44, then they receive one /48 more than they actually need, which technically lies dormant f they need arises within the assignment size that is something that can happen without bothering RIRs, which is also nice. It doesn't allow more detailed documentation of sub‑assignments. That's also a policy/implementation choice.
There was also I think, I forgot that ‑‑ let me quickly check, before we get into the non‑sub‑assignments.
There is also the point of what we do if the renumbering period expires. And there, the most important point, at least from my perspective, is that if those resources are in this renumbering and return period, they are resources placed and have to be returned to the RIPE NCC, which, according to the transfer policy, makes them non‑transferrable anymore.
So that is the main mechanic I see in the required renumbering and return.
So, this would be an example of how a network 44 could be used by some entity that qualifies for it. So you see there is a 48, 4 network infrastructure. There is a couple of POPs. There is an office network which has several sub‑parts, like internal systems, infrastructure, office wi‑fi and a guest wi‑fi and unused networks, they're a philosophical question which would I also like to put to the Working Group is, is it really a sub‑assignment if the work does not change and we just have an Inet6num object which provides for detailed documentation, it increases registry accuracy allowing operators to for example understand what those parts of the PI assignment are you used for, loop back, transfer networks or an office access network? Open question for the mic line.
Next steps, so we had Version 2 that had a second discussion phase. Will as I read it, there was mostly agreement, there was bun editorial suggestion to move from static to persistent addresses as described in BCOP 690. Otherwise we believe the proposal to be in a good state. If the chairs also find consensus be to have been reached we would like to proceed to the impact analysis according to the PDP.
Thank you. I am happy to take any questions and would I like to hear your input on the sub‑assignments.
(Applause)
FRANZISKA LICHTBLAU: Let's start with a comment from the Internet.
AUDIENCE SPEAKER: Maximilian, former and hopefully future IPv6... " I consider having a bit of reserve with the nibble boundary feature not a bug after all. A great selling point of IPv6 is abundance and we aim to avoid RIPE NCC work load. It's not a lot of space compared to /29 or whatever the current PA limit is.
TOBIAS FIEBIG: Yes.
AUDIENCE SPEAKER: Alun, I am a RIPE 92 fellow. My question regarding the policy is regarding the, when requesting a larger or an extension. So, the current proposal requires returning previous assignments within a six month renumbering period. If a contiguous use extension is not possible, right? So for operators running BGP with downstream customers or interconnects already numbered on those prefixes six months might be a little bit tight. So is it possible maybe to propose a different different time maybe more than six months.
TOBIAS FIEBIG: I personally think that that would be technically feasible thing. I am not 100% sure how far that is reasonable, because most of these PI resources I would imagine are not necessarily in the backbone of a Tier 1 or Tier 2 providing transit. Those most likely have PA, where they wouldn't face this issue. So, I am personal torn, and open to the Working Group's opinion on that.
JORDI PALET: From Jordi Palet: As explained on the mailing list I am not going to repeat myself. While I support the intent of the proposal, I have major concerns to support it with the current text. The maintain point is that we can restrict or contra deducted by means of policies what is standardised in the IETF. If we don't agree on standards the place to disagree it the IETF not by artificially doing standards by means of policies. Otherwise what's next? We create BGP or RPKI changes by policies.
TOBIAS FIEBIG: Thank you for your comment. I would like to give my e‑mail response to the same comment as a protocol.
FRANZISKA LICHTBLAU: Noted.
GERT DÖRING: As you have specifically called out for me this is nice because it's short to the point and there is parts to it that I don't like that much, but this is not something I am going to fight against.
The untangling of the PA assignments and the PI assignments in the text is very useful, very good. The clarification of the sub‑assignment rules is good. There is one thing I think that is not working. Could you go back a few slides, I think slide 7 or so. It says "or using a 64 locker when setting up a point to point with other ISPs for the purpose of changing traffic and Internet routing information."
This is allowed. On the next slide you basically say that if you peer with something that is not an ISP, it's not allowed. So it says connecting to another entity on the Internet so these two feel a bit of ‑‑
TOBIAS FIEBIG: It's actually pretty simple. If you speak BGP it's okay.
GERT DÖRING: Then you should maybe just ‑‑ I think the wording is not clear enough here. So it wasn't ‑‑ I felt it's contradicting itself. So, clarification might be in order.
The intent of saying you use this to set up transit, set up peering is fine, and giving transit to third parties is bad, is fine. On the nibbles itself, I don't believe in nibble assignments. But I am not going to oppose this for the record. I just don't think it's useful. But go for it. I am fine with it.
TOBIAS FIEBIG: Thank you.
MARCO SCHMIDT: I just want to clarify something at the end you asked a question or you said if there will be now consensus, then moving on to the next phase. Strictly speaking, we are at the end of discussion phase, that's not the call for consensus, it's more you have got sufficient support to move on and then also the RIPE NCC will create an impact analysis and like what you said at the beginning, it's important that people read the policy proposal, I would want to urge everybody to read. Once we go to the impact analysis, because we discovered already a few details an so on that might make it difficult for us to really fully go through with it or that might be unwanted side effects like let's see if somebody doesn't manage to re‑number within six months, we say is that a policy thing or are we going to take it back? But we will make sure that it is very clear the impact analysis and then please everybody have a good read through the proposal, the impact analysis and see what you make out of it. Thanks.
TOBIAS FIEBIG: Thank you.
JAMES KENNEDY: James Kennedy: So, you just spoke about the returning, if there is no contiguous space available for PI holders. Maybe if we could have a look at slide 12. First of all, thank you Tobias and Clara for your work on this.
We see the last bit, yeah, the returning assignments within six months.
Personally I don't see if this is necessary at all in the sense that why, first of all, return the existing assignments, I assume for aggregation and for routing table impact purposes.
TOBIAS FIEBIG: Mostly, as I said, usage of the transfer policy to prevent transfer of these resources and prevent in that process stockpiling.
AUDIENCE SPEAKER: Okay. Stockpiling.
TOBIAS FIEBIG: If a resource must be returned to the RIPE NCC, it's exempt from transfers.
AUDIENCE SPEAKER: I think the next steps will be an impact assessment. Yeah, I think we should take into account the impact on these holders, you know, you said earlier probably is not configured to their core network, it's an assumption, perhaps it's true, perhaps it's not, but, you know, really take into account the impact on operations in these type of scenarios that might actually be more impacting.
TOBIAS FIEBIG: Thank you.
FRANZISKA LICHTBLAU: Okay. Nobody in the room, nobody online, so I think, thank you for presenting this. Then we will continue with the process and await the impact analysis from the NCC. Thanks again Marco for reminding us.
Our last presentation for this session is Clara and Peter who want to talk to the Working Group to get feedback for an upcoming policy proposal to the loss of legacy status up on transfer.
CLARA WADE: Thank you. So, Peter and I decided to bring this to the Working Group after we both were in the charging scheme task force and came across a couple of issues that we want to bring to your attention, they were deemed out of scope for the task force so we individually took it upon or selves to bring this to the Working Group, so we're not speaking on behalf of the task force or our employers either, but we're disclosing our affiliations for transparency.
PETER HESSLER: So, what is being proposed is to remove the option of retaining legacy status after a transfer. This address as number of issues. One is increasing overhead for RIPE NCC. Speculation around scarce resource hindering adoption of best practices like RPKI and accuracy of the registry.
What is not being proposed. We are not proposing elimination of legacy status all together. I personally feel there is value in legacy I personally feel that people who ‑‑ many the people who have legacy are using it correctly. And that it is the ‑‑ we ‑‑ it would only loose legacy status only after a transfer. We are also not proposing backfilling the database based on past transfers. What happened in the past is in the past and we're only look to go address the future.
We want to reduce the overhead for the NCC we don't want to increase it.
CLARA WADE: So, addressing the reasons why we brought this policy forward.
So, as part of the charging scheme task force, work we discovered that the NCC Registration Services team was spending a lot of time processing legacy updates because they are not conceived as transfers but updates involved a change in holdership in the last three years there's been about 300 a year and of these, 20 to 25% of the receiving parties choose not to enter into a contractual relationship with the NCC, whether that was directly as a member or via a sponsor.
So, on average, about half of the work of one head count is spent per year on activities that essentially the membership is subsidizing for non‑contract holders. So we think this is inherently an issue that's driving up operational load and cost for the membership as well.
The second reason is there's been some rising speculation around a scarce resource. In order to prevent this speculation, this community introduced a 24‑month transfer lock whenever there is a policy transfer taking place, however this does not apply to legacy resource certificate updates even if that holdership is changing. So certain entities are purposely targeting legacy resources to be their flip or lease them and this is driving up the prices artificially for any small LIRs that need to get resources to get started, which nowadays they need to go to the secondary market for.
Some also are quoting as a benefit that you can circumvent RIPE membership fees if you do not enter into a contractual relationship. And in some cases, they are even requiring that RIPE reinstates legacy status after an inter‑RIR transfer if that resource was originally issued before the RIR system was implemented.
Another reason is this is inherently hindering adoption of RPKI. When legacy ‑‑ when there is opinion of legacy recourse transfer doesn't opt into a contractual relationship well, the NCC they are also opting out of the ability to use RPKI as this is only provided for members or sponsored LIRs.
And even when they choose to become members or have a sponsoring LIR, there is a bit more friction to RPKI adoption because you need to add each CIDR to your contract with the NCC to enable it. And the last one that might be a bit obvious I think, is the accuracy of the registry. Legacy status was meant to indicate that the holder received that space directly from IANA before the RIR system started, and this is essentially true in all registries except for RIPE. And part of the issue as well is that retaining legacy status after a transfer is the default behaviour, so it takes intentional effort from the recipient of that transfer to convert status to either allocated parks or assigned PI.
PETER HESSLER: So, the question is: Is which policies do we need to change? The first one is we would need to modify the RIPE resource transfer policies to include legacy resources within the scope of the policy. This is an example of the text we would like to add. Of course, when we come up with the proper PDP, we will have the full text included. We also need to modify the RIPE NCC Services legacy Internet resource holders document. We have, in discussions, we have heard from the original authors of this who have offered to help with that and we would be delighted to have the discussion and discuss this in detail with them as we work forward on this proposal.
Obviously, during the impact analysis, there will need to be a legal review of this to make sure everything everything is appropriate. In addition to all the other impact analysis that will need to be done.
CLARA WADE: Okay so, to far we posted this in the mailing list and received some feedback. Initially we had raised this as a clarification, but it's certainly a modification of existing policy, and another callout had been that this could be used to bypass utilisation requirements in inter‑RIR transfers. However, it seems that actually there was a utilisation plan justification provided but there were repeated changes, a plan that ended up in resources being flipped or leased. In the ARIN 56 policy report it was brought up that a single facilitator transferred about 17 hundred /24s into RIPE for network operational needs. About today half of those resources are being leased, some of them have been transferred to another party.
So, in this situation, flipping could be prevented by the loss of legacy status resulting in that 24‑month transfer lock going into effect.
Another point that was brought up was what if a transfer fee was introduced to cover overheads for the NCC. It's a bit of a chicken and egg problem. On the one hand, the NCC needs a contractual relationship with a party in order to charge for services. And this also doesn't address the remaining reasons that we presented on
.
Another point that was brought up was a concern regarding certain parties starting to bypass the registry diligence process and just updating the database unilaterally or creating their own in order to retain that legacy status or to avoid paying higher fees in the event that, you know, option B passes.
Personally, I would say that if you are a service provider engaging in that behaviour you are doing that at your own risk and your customers, we're all I think striving to build reliable networks and following database accuracy principles and routing security best practices. And also the RIR fees seem very reasonable considering. For most organisations that does not pose a material cost.
The other item that was brought up was that other RIRs have attained similar outcomes by deeming transfers as a service that only those with a contractual relationship with the registry can get access to. But this doesn't still address the speculation issues or the accuracy of the registry.
And with that, we open it up to questions.
FRANZISKA LICHTBLAU: Thank you. Let's start.
NIALL O'REILLY: Niall O'Reilly, former employee of a legacy holder, currently with Tolerant Networks Limited, but that's not really relevant to this discussion. And also one the co‑authors of policy proposal 2012‑07. I'll try to keep the comment shorter than the presentation.
I am concerned about due process here on two levels. There is a whole stack of rabbit holes here. On the first level, adopting such a policy or asking the NCC to implement it is, as I see it, a third party interference in an agreement in which you are, in which, in respect of which you are a third party, and that's not appropriate.
The second issue of concern on a due process level is that as far as the legacy resource holders whom Kasim in the outreach that he described to us in his RIPE Labs article has not yet main contact, this is not an open forum for transparent consensus, it's a smoke‑filled room populated by a cabal of insiders and those are both things that we have to be very careful about. I understand the pragmatic requirement to do something here. I understand the good intentions behind the proposal. But, I think it's not that simple. I am happy to work with the proposers to map out the pitfalls and see what's the best way forward. I don't propose to expand on that right here right now. It's complicated. Let's not do something that will invite litigation that will cost the members more than what will be saved by doing what seems to be the right thing at the moment.
I think that's enough for me to say at the moment.
PETER HESSLER: I would just like to respond briefly to those comments. Thank you very much. You are absolutely correct, there are a lot of pitfalls in this area. We did consider that when we started, as we were thinking about this, that's why like I am encouraging Athina to look into the legal aspects but also specifically what ‑‑ we did not do a full analysis of the legacy holders, but we did a, check the temperature with several legacy holders like how would you feel if this proposal was to be brought, they felt, well we'll have to see the details. But also that is why we're bringing it to the community to have a discussion about this, and to work out a full PDP process. So we want to make sure this is, you know, as transparent as it can be, that this is, you know, brought to the community and there is proper consensus before any of this is implemented for sure.
NIALL O'REILLY: There is something I should have said at the beginning, and that is to thank you for taking this approach. The other thing I would suggest already now is that there may be ways of using the existing policy rather than introducing a new one which would be adequate to address the problem. I haven't thought that completely through yet, but we may not need a new policy.
PETER HESSLER: I look forward to exploring that with you.
BRIAN NISBET: Conceptually two big thumbs up to this whole idea. While legacy resources are absolutely a thing and they have all the rights and reasons to be a thing, the moment you transfer that, as far as I am concerned, you lose that special bit, you know, it's no longer coming out of a notebook to allocate that address at that point in time.
I think, obviously, and Niall mentioned this, you are not coming along saying this is the policy right now. This is the beginning of the full process with all of the impact analysis and everything else that will go on there, but I think anyone who sits there going, I should be able to buy this legacy resource and keep the things and do all the stuff that people are doing with it, that's ‑‑ yeah, that's not a rational thing to do in my mind and I think you are just trying to get around a whole bunch of policies that we have already put in place so thank you.
AUDIENCE SPEAKER: I am a RIPE NCC member so I know about the smoke‑filled room. I am not a big fan of the policy as currently crafted as I expressed on the list, but I do appreciate, Peter and Clara, your efforts in bringing the problems up and opening it for discussion. When it comes to RPKI adoption, legacy holders can do RPKI at RIPE. They have to sign a legacy services agreement and become a member or sponsored, and then they are paying dues so that problem goes away with the, I guess, 75% to 80% that do become members. That's a pretty good percentage. And I think the way to promote RPKI adaption is not at the registry level, but at the network operators level as we're doing now. When your upstream tells you, you can do either RPKI or stop broadcasting, you are going to do RPKI. And as we do more and more of this that 20% to 25% are going to come on board.
Now being able to retain legacy status after a transfer in RIPE is unique among the registries, and you have some problems, but it also attracts people to your registry. I think it's one of the two reasons why RIPE is the greatest Internet registry in the world, and I wouldn't want to eliminate that. More people come in, some abuse it, but over time as RPKI is adapted, they will be dues paying members, there will still be legacy, but they'll be able to do it.
I did want to point out an alternative. I know you didn't want to charge a transfer fee, but you could require that during a legacy transfer, the receiving member can keep it a legacy status but they have to become a member or be sponsored. You are getting the dues, you are getting the relationship, you are keeping the carrot for all the other addresses to come in, so thank you, and I like that.
PETER HESSLER: Thank you, that's an interesting avenue, and I think is definitely something that will be worth discussing on the list and seeing how the other members of the Working Group feel.
I do want to say just very quickly that while RPKI is important that was absolutely not a driving factor for this discussion. Our concern was more around the flipping and avoiding policy. That was our primary concern with this. And that the RPKI problem is just one of many issues that show up.
AUDIENCE SPEAKER: Right, I wanted to go on that. I will say this. I am an IP facilitator, used to be a dirty word associated with that, but I see a lot of transfers and I see the motivations for people making these transfers. And as I say, RIPE is very appealing to them. Speculators are not always evil, they don't always have a monocle and a top hat. We do have a market place easier and in most market places where there is a Stock Exchange or the IP market, speculators provide liquidity. Yes they may make money but when you need IP resources that are scarce and you need to purchase them, those are the people you can get them from because they are not using them. Yeah they are flipping and they are doing this and that, but they are providing the fluidity for the market place, I don't think we need to go this route, but thank you and I'd like to keep the discussion going.
PETER HESSLER: Thank you.
AUDIENCE SPEAKER: Sergey: Looking at what happened on the market with the IP, legacy IP resources I would rather, would say this is a mess, I would rather welcome the exception and approve the policy proposal amending the RIPE transfer policy. So I will support losing the legacy status after the transfer. I'll be happy to contribute if this will, if this consultation will end in a policy proposal. That's it.
AUDIENCE SPEAKER: I do have a couple of points ‑‑
TOBIAS FIEBIG: First, just speaking for myself, I personally believe that IP addresses are not property. We are a community. We want to work together as engineers to make a better Internet and we do not need to increase our customers base, may that be speculators, traders or whatever, and I think that should not be a consideration for how we craft policy, Policy should be crafted to make a better Internet. So, then multiple hats. The first hat I'm putting on is now the hat of AT.internet, as a freshly founded LIR for my research group, and as that representative I have to say, how dare you trying to spoil my perfectly crafted plan of gaining charging scheme model B.
PETER HESSLER: I do what I can.
TOBIAS FIEBIG: Different hat. Thank you for doing that. This is an amazing idea. I would personally also do this retroactively. I believe that it is not us fiddling in a relationship between two other parties. Legacy status is something given to an entity that has got something before the rules of regulations were in place and when they transfer it they want something from the NCC. They could just leave it as is. That is what legacy is about, leave it as it. But they don't want that. And that's where we come in and then we can say well like either you leave it as it is, which is legacy, or you follow our rules.
FRANZISKA LICHTBLAU: I don't think we have anyone online: Nobody at the microphones anymore. Then thank you.
CLARA WADE: Thank you and look out for the policy proposal in the mailing list.
FRANZISKA LICHTBLAU: And then read it.
Okay. We are well ahead of time, but as usual, we keep time for our Open Mic session, so if anyone who is in this room or online with us wants to address the Working Group with some question, comment, idea, now is your chance.
While you make up your mind I would actually like to bring something to your attention. I think it has been mentioned in the Opening Plenary and we also discussed this at the Working Group Chair lunch, but I think it could especially interest this community. We have this, some call it rule some call it convention about naming your name and affiliation when you speak at the microphone. Some people are questioning whether that should be stronger enforced or not enforced at all for various reasons, because some people, if we force them to name their affiliation, might not be able to ever go on a microphone because their companies won't allow them.
But on the other hand, we need it transparency on who talks to us, especially about policy and to contextualise what we have been hearing. And I would be very curious because this discussion is going on here and there, what the opinion of the Working Group is because that is also informative to us chairs, how we actually run the session:
GERT DÖRING: Member of the community: I saw this being enforced in the first Plenary on Tuesday. People coming to the microphone, stating their name, which is sometimes everything that is needed, and the moderating chairs insisting on an affiliation is needed.
When I come to the microphone, I could speak as SpaceNet, as a regional ISP in Munich, I could speak as a person being interested in things, I could speak for the OpenSource projects I take part in, I could speak as a former Address Policy Working Group Chair trying to give advice of the old people, or as just myself. So, I think sometimes the affiliation gives background that is useful, and this is when I mention it, and sometimes it's getting in the way. So, I would see it as an optional extra.
FRANZISKA LICHTBLAU: Okay. So we actually overlooked a couple of questions, so Tobias, while you are there, can Alex read out two questions?
TIANRUI HU: Meetecho wasn't very clear that there were two questions waiting. Was it, to which one? To Clara and Peter.
ALEX LE HEUX: Maximilian asked, did AWS and its subsidiaries cover all previous legacy to PA or PI? Can you tell us about the process, especially talking to your own lawyers. I have posted the proposal as transfers might happen totally off the books as a result. Just introduced a fee that reflects the actual workload.
CLARA WADE: Yes we did convert all previous resources to PA especially as we stand in support of option B, we want to make sure we are contributing our fair share.
ALEX LE HEUX: Second question from Jordi Palet: . "I think we should move away from legacy, so in support already an interesting step down in APNIC and recovery of unused space, LACNIC is working in a similar path even if there is not too much public disclosure. Of course legacy must be lost when transferred, as in the other RIRs".
PETER HESSLER: Thank you.
FRANZISKA LICHTBLAU: Now, we are out of questions?
ALEX LE HEUX: Now we are out of questions.
FRANZISKA LICHTBLAU: Good, back to the affiliation discussion.
TOBIAS FIEBIG: I personally do believe that name and affiliation is a very important thing because it also forces thereafter the explicit, what are you speaking for at the moment? Because A) transparency and B) making explicit that you are not speaking in a specific role, for example, role as a current Chair of another Working Group, as like lead C level person in a major international company, but just as yourself and like might even have thereby the opportunity to say like this is me, and that's my employer. Those two things might not be aligned. It's very important.
FRANZISKA LICHTBLAU: One clarification question from my side to this. I think one of the questions is: Are we requiring somebody who has an affiliation to state them. For example in my case I am not paid by my company to do any of this but I have it for transparency reasons but I can never speak for them. So, are you ‑‑ to understand your comment, are you okay with the speaking for myself and not naming the company?
TOBIAS FIEBIG: I would personally say your company should be named because then you do influence a discourse of the community, you might also end up getting into a leadership role, become a Chair of a working group, an then it's just important information. Of course it is on your badge and on the registration page for the very same reason, technically you could also register without putting that in. And then it would start to get difficult. I mean, imagine Tina would here be as Tina Morris unaffiliated, joyride to Edinburgh, I like it here.
FRANZISKA LICHTBLAU: I really wanted to contextualise. I tend to agree, but... Tina.
AUDIENCE SPEAKER: Tina: Thank you for giving the example. Tina Morris. AWS, people know where I work, it's better to say it for me. I am allowed to come to the mic and I have been through all the speaking trainings and all that. I think the affiliation is super important for context and world view and even that we all serve and we really do come to the mic as individuals and serve on committees and boards as individuals. We're always influenced by our entire resume up to that point. That's where your world perspective comes from. It's really helpful. However, I get that some people can't go to the mic and can't say their name. Maybe there is ‑‑ I haven't fully thought this without but maybe there is a way could you say I work in a big Cloud provider, can't really say with but my opinion is X, Y, Z, so you can give the context of the role that you have without naming that name that will get you quoted somewhere inappropriately. Because I think the context does matter. Your perspective matters. How you see the network in the world, are you coming from a small university, or a global organisation, you are going to have a very different perspective. They are all valid, I want to hear them all. But I do kind of need to understand where you are coming from.
FRANZISKA LICHTBLAU: That's a pretty good way in between and that also informs us as session chairs how we could potentially do something with that.
NIALL O'REILLY: Largely what Tina said. I am just a random err who walked in from the street but I am not from Glasgow, I am Niall O'Reilly, there are a 174 people here on site who haven't been to a RIPE meeting before, So Mirjam told us on Monday. The rest of the people in the room have met me before and some of them know what I share a birth year with Rudiger, and when they hear me mentioning my name, just as for Rudiger, they know what biases and baggage I am carrying, but that's something that ought to be disclosed to the new people. I think ‑‑ you asked specifically whether this should be optional? I think it should be a very strong all capitals SHOULD.
AUDIENCE SPEAKER: Yang, Internet citizen. I tend to agree very much with Gert, and a bit less with Tobias. Basically, I think that it is important to state your affiliation if you feel that you are speaking on their behalf. So, if you are wearing your hat, then you probably should state your affiliation. At the same time, if you do not want to state your affiliation, I think we cannot enforce it. So, I already had such a discussion that the NCC cannot check whether at registration you say who you really are, especially as far as the affiliation is. And I think we shouldn't require them to do so. So it's up to everybody to state how they feel and of course after a while, everybody will know you if you continue to come to the RIPE meetings, even the new people will find out who you are and they will take into account your comment as they feel it is appropriate. That's my opinion.
AUDIENCE SPEAKER: Will from AS 2613. In my case I did raise that point because I had trouble with the ‑‑ I was not really easy with the situation on Tuesday, and so my thinking is, if we state an affiliation and we say the relevant affiliations for the comment, it would be probably really helpful and I guess I have many hats of administration, I am Chair of connect, co‑chair of connect, I am part sitting in IXP and so on, I said I was the one that was the most relevant with what my own affiliation association, and so I hope that we can find a good balance there an, yeah, that's all I have to say. Thank you.
TOBIAS FIEBIG: Speaking for myself and not my affiliation. So, the blue sheets in the IETF were there to document who was in the room when the decision was made and those also have an affiliation column for the very obvious reason that it is not about people being mistaken to speak for their affiliation but it's about people speak for their affiliation without carrying their affiliation, which can be somewhat annoying in consensus‑driven organisations when there is a bus from hypothetically speaking bridge style network vendor, for example, who does this changes over the years, it's always like the same procedure, different company. Stopping in front of the meeting and loading a couple of people ready to vote. You can do this but at least it should be visible to the community.
FRANZISKA LICHTBLAU: Thank you.
JEN LINKOVA: I was someone who worked for an ISP to content provider, system integrator and a routing and switch vendor and who also has run an enterprise network, I am confused are we in the Community Plenary now. I am not sure is this discussion going to be specific to this group or are we going to leave each Working Group decide and Plenary decide, or are we talking about generic policy we are going to apply.
FRANZISKA LICHTBLAU: Comment received, for me it was something discussed between Working Group Chairs and to me, it was, or to us it seemed useful to raise the question to the Working Group but I hear you, yes.
JEN LINKOVA: I'll tell you, I actually came here to say something different.
I think affiliation again might be useful and I think nobody trying to hide is when it ads context, but sometimes it's also might be misleading because again people which wear mainly hats should be free to choose whatever they think is relevant for discussion, and if nothing it relevant for discussion, nothing should be disclosed, because I suspect that when I say Google, people might be, might misunderstood and think about Google as the, as a content provider or Cloud provider, which has absolutely nothing to do with what I am doing there, right. I am also afraid that I am not the only one who works not very well under pressure, so when you start forcing something, people might be reluctant to go to the mic, and is it actually a direction we want us to go?
AUDIENCE SPEAKER: Just as someone ‑‑ Rory Bush, Netcraft, as someone who is at their first RIPE meetings I think the affiliations are useful, It gives a lot of context of who is speak and what biases they might have. And so yes, I would be in support of keeping it up.
AUDIENCE SPEAKER: Stefan, with my own hat. I have to think about the name which company I am working right now. It's open 7. I remember. I think what I Niall said is totally right, It should, and a strong should, and I remember times when Gert was on the microphone years ago and he said, I have now my hat on because this is this topic, and now I have my hat on because it's a different topic. This is the best thing we can do. There was a lot of people here and discussed during the work chair dinner, there is a lot of people doing consulting stuff for a lot of different companies, and sometimes it is good to mention the name, and sometimes it s only good to say, I am a consultant.
FRANZISKA LICHTBLAU: Peter.
PETER HESSLER: I am co‑chair of the Database Working Group. This issue does affect all the Working Groups, so, I believe Franziska's intention was not to come to a decision or policy in this room, it was to raise a question and that I do agree with the previous comment of we need a single guideline for all the Working Groups and the Plenary and for the entire event essentially.
FRANZISKA LICHTBLAU: Fully agreed.
IVAN BEVERIDGE: Ivan Beveridge, ex Fintech employee.
So, I can appreciate as well the comments that have been made that potentially it might be difficult to come up to the mic and name your employer when the employer maybe doesn't want to be associated but perhaps there maybe a middle ground whereby you end up saying for, like for example, Ivan Beveridge, company speaking on behalf of myself or something like that, because I think the majority of people when they come up to the mic, you tend to get some abstract comment speaking on behalf of myself anyway, but just a thought anyway. Thank you.
NIALL O'REILLY: Old timer at RIPE. I have held a number of leadership roles here, and I think it's important that Franziska has raised this question in the Working Group that she is leading, because it's relevant to her leadership role and yes, we need to do it wider than that, but the implementation of whatever policy we have, or however we want to do this has to be implemented by the Working Group Chairs, and it's relevant to Franzika doing her job. So that's just to follow‑up on Peter's comment.
FRANZISKA LICHTBLAU: Thank you, you said it better than I did. Okay. Unless we have more comments for the Open Mic session, I think we can ‑‑ well nothing from the Internet. You checked. Okay. Then I think we can close this session. I still remind you that you can rate all the talks at the RIPE meeting, we look at these reviews, we give feedback to speakers and until five o'clock you can still vote for the PC, two seats are open and your vote is very appreciated. Thank you very much.
(Applause)
.
Coffee break.
.
RIPE Community Plenary is the next session at 4 p.m.