Address Policy, part 2.
Main hall,
RIPE 88
22 May 2024
11 a.m.
ERIK BAIS: Good morning, welcome back, this is going to start the section session for Address Policy, and we have Remco up next.
Remco is going to explain the agenda item on there about PI simplification, but it's not, right.
REMCO VAN MOOK: So, this is, this is the title is, as Leo so aptly put, a little bit of click bait.
Thank you all for joining, why PI?
This is essentially a repeat from a presentation I did at one of the easily forgotten virtual RIPE meetings, RIPE 82, so three years ago where I went through the them, and had a look at the statuses of the resources in there: The last time I said well this is not a policy proposal yet. I'm going to be doing a policy proposal this time. It might not be Address Policy, but here we are again: Starting off with a quote. "We need to hit the two main criteria of science: We need to graph something and we need to cite something. And like a true academic the main reference source I will be citing is myself from a few years ago."
.
So inetnum statuses, my favourite topics and yours. What's your flavour? There was someone else presenting earlier this week about this. Legacy, allocated PA, assigned PA, assigned PI, assigned Anycast. But you think that's all? I don't know. So, back in 2022, I presented this slide and there are four typos in it. The good news is in the last three years, someone very, very quietly did a clean‑up. So kudos for whoever that was. But the database is now clean and there are no more errors in status. So applause for whoever did that. So we have on the inetnum side of things and IPv4 side of things, we have a few more assigned PAs, about 6,000 more, we have 16,000 less legacy, we have around 6,000 more allocated PAs as well, weird how that attribution. Assigned PI is gone down. LIR partition, PA, those are actually gone up quite dramatically. We have allocated unspecified, which is always a nice status. And we have assigned Anycast, which has not moved at all.
So let's focus on the assigned bits of this. We have just under 4 million assigned PA. 126,000 legacy, about 20,000 assigned PI and 50 assigned Anycast. Here is the helpful pie‑chart to show you what that roughly looks like. So you can sort of see what the majority here is. And let's have a look at IPv6.
So, back in 2022, on the IPv6 side of things we had two typos that were more common than assigned Anycast. And also on the IPv6 side, someone has cleaned up the typos. So, that was good. You see the similar kind of move. Assigned has actually gone up quite a lot. And, you know, focusing on the assigned bit, there is 750,000 assigned, 60,000 AGGREGATED‑BY‑LIR, which really is assigned. We have assigned PI and we have assigned Anycast.
So here is a helpful graph of what that looks like. Roughly 99% of the stuff that we have in INET6 num is assigned PA space.
How much of that is actually still relevant? Certainly for v4, but maybe also for v6. So, the first lot of Curtis, I saw him in the room earlier, the first law of Kurtis is: If you think you're special, you are probably wrong.
And so which ones of these statuses are still relevant? Allocated? I mean, has this been out to someone based on a contract with the RIPE NCC? Sure, absolutely. Assigned: Is this in use? Is there someone responsible for this? Well, absolutely, that is definitely relevant.
Legacy, is legacy actually a relevant status? It's assigned space, right, and does it really matter if something was assigned by Jon Postel by the RIPE NCC or some LIR? Probably not. The real difference is the contractual chain that sits behind it, not the address space itself.
And Anycast. I'm going to say a hard no. Kind of the part of Anycast is that doesn't stand out, so, there you go.
So, if we were to start looking at simplifying this, what would we gain? So, assuming a world where we took the inetnum part of our database and we simplified the statuses to allocated or assigned, it gives you a lot of clarity, consistency, less room for loopholes because Lord knows that this room and the people outside are very creative in finding loopholes in policy and it allows us to much simpler ‑‑ make much simpler policy and procedures on address space. Because if you do it this way, and you look at inet‑nums as sort of a tree, then allocated can have leaf notes and assign it as a stub, it makes it a very straightforward thing to understand.
Why do we want to do this now?
.
So, remnants of Address Policy, and certainly the reflection of that in the database, defines a pretty rigid mould for the RIPE NCC to follow for structure of membership, especially based around rules for v4 distribution, and if we want to give the membership of RIPE NCC room to evolve its membership structure, we need a bit of a break with policy in a database that no longer the database no longer should describe how the membership, what the membership should look like. But we should rather have the database accurately follow what reality looks like.
Exact policy proposal text to be determined, I think I'm going to leave most of the writing of that to Angela who is sort of aware that this is coming her way. But since this is such, so tightly woven into he every single corner of our policy handbook, I'd rather leave that to the expert. So Angela, already thank you for your hard work, we'll be putting into this shortly. But to give you a bit of a flavour on this.
So, we have types of address space. This is part of the IPv4 registration and creative interpretation. So we have allocated, this address space has been allocated to an LIR, and no assignments or subsequent allocations made from it are portable. More specific objects "May" exist in the RIPE database. Assigned: This address space has been assigned to an end user. More specific objects do not exist in the RIPE database.
And apparently, 13 years ago some genius came up with the idea to do aggregated assignments in the database. And I found this while I was writing this presentation, I don't know who the relevant was it. It turns out it was me.
So, investigated, which is basically a group of assigned. This address space has been assigned to an end user by an LIR. Each end user has been assigned to block size of the assignment size in the object. More specific objects do not exist in the RIPE database.
So, that's all I have here. Can we restart this maybe? Get the final slide open.
It's here.
So what do they think? Is it time to clean up?
AUDIENCE SPEAKER: Can I speak now? So my take on this is that I think some of this makes sense, I think for v4 there is may too mean different statuses, and simplifying that would make a lot of sense.
I think keeping legacy kind of makes sense, or at least some way to publicly check what's legacy and what's not. Because that helps when trying to figure out okay, like, I think it helps with trying to gather data on how much space is. There are other ways of publishing this information, but if I don't want this information to stop be published.
REMCO VAN MOOK: Fair point. At the same time, the cool thing about legacy is we're not making any more of it. So, in that sense, information about legacy is out there, and whatever is out there, is going to be accurate until a new object is in the RIPE Database essentially. So, in that sense, I absolutely understand what with you are trying to say, but at the same time I don't see the need for this to be, to continue keeping track of this as a special item. Like I said, assigned is assigned and I don't really care who did it.
AUDIENCE SPEAKER: But, I might be mistaken, but from what I understand, how policy is enforced varies for legacy. You can't really enforce policy. To my knowledge for legacy.
REMCO VAN MOOK: That's ‑‑ and this is where I think it's actually interesting to make the cut between the contractual relationship that exists openfully for every piece of address space, I'm keeping my fingers crossed here, and what we actually have in terms of who is responsible for what is in the database. Because, there is a bunch of stuff ‑‑ I mean originally, of the entirety of the contractual relationship between RIR and address space holders was in the database as published. That hasn't been the case for, I'd say at least 13 years, probably longer, probably closer to 20 years, so we're carrying this whole stack of pretty much redundant information behind us. So, in that sense, I absolutely take your comment that we need to be able to continue to be able to identify legacy. At the same time, having a table based on today's data of what's legacy should do for the foreseeable future.
AUDIENCE SPEAKER: Peter Hessler, active with the Database Working Group but not speaking on behalf of the Working Group.
So, as I understand it, one of the critical parts of your proposal is that you would move the contractual requirements of the address space from this public field to a more private field. But don't feel that there is some very strong interest in the ‑‑ in the public knowing some of the basics of the contractual requirements. Like, for example, assigned Anycast means that you have to use it for an Anycast purpose. What end ‑‑ we're not issuing any more of that, fair enough. But those address blocks are special in this way. Some are for legacy, some are for ‑‑ some of these more subtle ones, and this is perfect for both v4 and v6 going forward. So, are you suggesting that we hide this away from the public? Are you suggesting we make this a different field within the database?
REMCO VAN MOOK: I mean, going back to my ‑‑
.
This is the distribution of v6 inetnums. There is, I think, for IPv6 there is a sum total of 67 of these assignments on a pool of a million. I think that keeping these special super special corner cases and carrying them around with us forever because it was once special, I don't think that's ‑‑ that is beneficial to us in any way, and if that means that we remove some of the requirements on the space that was once handed out in this way, you know, what, I don't think we're going to lose much over that.
PETER HESSLER: Just as a comment for the proposal that I do recommend consulting the Database Working Group and especially the database team from the RIPE NCC. There may be technical issues in implementing this, which we have recently learned with the approval of end of view IPv4.
AUDIENCE SPEAKER: Tobias. I do see two major issues with this. If you do not have the contractual relationship/status document in the RIPE Database that introduces a margin of error while handling things while requesting things while making requests. And just to the point from the transfer policy, allocated resources may only be transferred to another RIPE NCC member provided independent resources may be transferred too. So of course you preserve this contractual state of the resource somewhere else and in the database. So, like in a shadow database, but it will introduce noise in making requests to the registration desk, requesting transfers that cannot be transferred, and you will have to aaudit all policies on whether the just presentation change might ultimately have unexpected policy implications in a policy that was written under different expectations on how the database looks.
The second thing is legacy. Legacy does not really have to remain static. I think we all hope and dream that people voluntarily transferred to PA. Putting it just on the jurisdiction of the RIPE NCC. But it also raises a question if you, for example, create an inetnum object within legacy space, what is it then? Is it an assignment? Is it an allocation? What does it mean if there is an allocation within the legacy block? Those are all very tiny intricacies, and it can also I think raise the impression with legacy holders that you are coming for them.
Okay.
AUDIENCE SPEAKER: Hello, Nick Hilliard: I am a bit concerned about what you are proposing here because I don't really understand what it means, and there is a bunch of slides I think of which this particular one is probably the most misleading in the sense that it's pitching itself as helpful. It's not really, because these terms mean very specific things, and have a connotations associated with them. For example, assigned PI address block is something that had some quite substantial level of due diligence performed on it by the RIPE NCC ultimately. Assigned PA could be any old junk, you know. So I mean like to compare those in the same pie‑chart is not useful. But to echo what Tobias said over there, it's not clear whether this is just some sort of technical change to make the database structure a slightly bit easier or whether you are talking about a policy change to sort of coalesce all of these type of things into one.
REMCO VAN MOOK: Just to be very clear on that. The only thing I'm proposing to change, which is why the title was a little bit unfortunate on the agenda, is I'm not proposing to actually change any of the current policies, whether it's about PI or whatever. That is not on the cards right now. We might want to change that because we're looking at potentially changing contractual relationships etc., etc. I think the whole e‑evidence thing that's coming up is actually going to put the whole contractual obligation thing under a magnifying glass in the near future.
Having this out of the way before we actually have to dive into the contractual stuff that's sort of sitting next to this, I think would be helpful.
NICK HILLIARD: I still don't understand the consequences of what this proposal actually means.
REMCO VAN MOOK: So, what I'm trying to do here is make sure that what, what is reflected in the database, what is reflected ‑‑ what has potential operational consequences, we do now and then we can look at the contractual part of this in another form in another place in another time without actually having to worry about anything we're doing there having operational implications here.
NICK HILLIARD: I still don't see ‑‑ maybe I am being stupid, but I still don't exactly see what you are planning to achieve.
REMCO VAN MOOK: Okay.
ERIK BAIS: I am going to read out a question from Alon Maximilian, "I agree with the lack of need of any separate Anycast in the database. We need to be careful not to trigger any unintended lingering policies. Cleaning up legacy to allocate it in a signed would make sense especially considering legacy more specific than 24s, but could be a lot of work."
.
And a question from Elvis: "So all PI holders must become LIRs?" You already answered that question.
REMCO VAN MOOK: That's not what I'm saying here at all.
ERIK BAIS: We're talking about status in the database, not contracts.
REMCO VAN MOOK: I'm not talking about contracts. I think this is also not the place or the forum to talk about contract. So...
ERIK BAIS: All right. Then Sander.
SANDER STEFFANN: Speaking for myself. So, I agree with Nick here. I am not sure where this is going, because some of the things you are splitting off and separating actually do have operational impact, maybe not on routing, but on transfers, on other things. So, just grouping it like all assigned or allocated. I think at that point, we're making operationally important data less publicly visible because it's not just the contractual relationship that you are taking out of it. You are also taking some context out of it, and I don't think that's a good idea. I see why you are doing it, but I don't have the feeling this is the right solution.
REMCO VAN MOOK: Okay. I think most of the context is going to be apparent from the structure in which it is in the database. But sure...
PETER HESSLER: I want to continue my thoughts from earlier. I forgot one important part. I am not opposed to your problem statement. I think this is a good problem to solve and ensure that any policies that we create are minimally impactful to any future charging schemes, and I don't want to discuss that here, but I think we need to make sure that we allow for reasonable freedom for the RIPE NCC, with its members, happen.
REMCO VAN MOOK: Okay. Thank you.
AUDIENCE SPEAKER: Mike Burns, IP trading. We use that legacy field quite a lot in transfers, and I'd just like to share the situation at ARIN, the legacy status does not exist in the ARIN Whois, and for us as brokers, it's one of the first things we want to determine because there are different rules for legacy transfers. So in ARIN, they have created what was suggested a separate database that we can access to determine whether blocks are legacy. If you don't have that, brokers are going to be calling it and asking if that legacy field disappears, what the status is, because many times the clients don't know.
REMCO VAN MOOK: I mean, that's ‑‑ I think that's actually a rather elegant work around from the ARIN side. So ‑‑
AUDIENCE SPEAKER: Maybe it can be done here.
REMCO VAN MOOK: Thank you:
AUDIENCE SPEAKER: Hi. I would like to comment on the Anycast category. I'm not against removing this, but I would like to drop the remark that identifying Anycast and measurements is incredibly difficult and any information actually helps. So, please don't remove it in a way that makes it less publicly visible.
REMCO VAN MOOK: I am going to counter that by arguing that out of the the what was it, like, 4 million assigned PI inetnums that we have, and 50 assigned Anycast, I would argue that out of those 4 million assigned PA blocks, or assigned PI, there is actually thousands of them Anycast. And actually, calling anything ‑‑ having a small section assigned that defined as Anycast it actually misleading, because it sort of implies that the rest isn't.
AUDIENCE SPEAKER: I mean even a sample of where it can be relatively sure that it is Anycast is useful because then you can at least look at the sample and can study that where you can be pretty sure where it's incomplete of course, obviously, right. But still it's a valuable information.
REMCO VAN MOOK: Okay.
AUDIENCE SPEAKER: We don't need it as a category but it can be somewhere else but it should be publicly visible. And by the way, there is also a draft at the IETF for designating prefixes. So, there is obviously interest in the operator community to see this.
AUDIENCE SPEAKER: Alex Le Heux, speaking as a network operator who runs several Anycast clouds. None of the space is marked assay signed Anycast in any database. And to confirm that.
REMCO VAN MOOK: That's as much as I suspected. Tobias?
AUDIENCE SPEAKER: Tobias: This time around speaking as a researcher. The point about what Matthias just made is about having roundtrips. If you are doing measurements and you have a small set of networks where you can be reasonably sure that they are Anycast, you can use them as round grips to identify as Anycast networks that are not marked at as much. That's the value Matthias was referring to for having that.
REMCO VAN MOOK: Okay.
AUDIENCE SPEAKER: Stefan vial from out 128: We have some issues explaining all these different things you have listed in the beginning, even without all the errors inside of it, small, big letters, double S, single S and all these things. I think so it's the simplification gives us more freedom and also in a lot of other things, and the suggestion that ifs there is some need for legacy why not have a special database for it or for the Anycast stuff, why not have a second database where we can look this up, maybe a global one which would make sense in a way. So simplification I think gives a lot of freedom to talk about the future of RIPE.
REMCO VAN MOOK: Thank you.
ERIK BAIS: I have one additional remark from Elvis.
"I don't understand then what will the holders of assigned PI hold if this proposal gets approved assigned by RIPE NCC?"
REMCO VAN MOOK: No, the status is assigned, full stop. There is no ‑‑ so, the distinction in the status field is either allocated or assigned or the aggregated thing which is the annoying thing that someone added, I think Angela is waving her hand. You are about to write this thing Angela, so please come and comment.
MATT LARSON: Let's see where it goes. So if I understand correctly, because I got some questions, you want to have two Greece, one the allocated category and the other is the assigned category. And what is assigned set assay signed as, is at the last stage of an assignment. So what is registered in the database assay signed, the holder should be the one using the ‑‑
REMCO VAN MOOK: Assigned is a stub, and allocated is how it can have leaves.
MATT LARSON: And for this Remco, I have to make a little correction, because for the AGGREGATED‑BY‑LIR, there is the possibility actually to have a child assigned PA in the status like, for example, if you have the same assignment size in IPv6 and you want to group something in one assignment bigger, there is the possibility to do it. But it's a ‑‑ I mean, the syntax and the allocate can be arranged. So, just this, and I hope I interpreted correctly what was your ‑‑
REMCO VAN MOOK: I think you did. And I mean the reason I'm looking at you to write this because the devil is in the details and there is a lot of devils and a lot of details in this one, so yes.
MATT LARSON: Okay.
ERIK BAIS: Last question.
AUDIENCE SPEAKER: Hi. So, my problem is that if you want to just put allocated and assigned, you should keep in mind that there should be some way of identifying who assigned it. Was it the RIPE NCC, which is known to do due diligence, or is an LIR and LIRs are heavily random, more like towards them not necessarily updating regularly and stuff like this? So, one thing that ‑‑ for the moment the status says who did it. If it's assigned PA, it's clearly that it's not an LIR, it's the NCC. If it's assigned PA, we should probably also ‑‑ we still have payer and payee find some other of spelling is loud because in English it's just bad. So assigned payee is known to be a kind of accurate. Assigned pay eye, it's random towards bad. And if you remove the second part, you just leave allocated, which is always, let's say, good and assigned. There should be some other way to mark who did it.
ERIK BAIS: I want to make a comment on that. First of all. Same as with legacy. You will always have a parent block. You can also ‑‑ if an LIR assigns a PI, assigns IP space to an end customer, which can not have any stubs, but you can always see if there is an allocation above it, or if it's a prefix, the block itself ‑‑
AUDIENCE SPEAKER: In which case you have also to deal with the stuff where you have blocks that cover, do global cover up like the stuff where you have IP space from other RIRs which is marked as some statuses, allocated shoe else. So, this complicates stuff a little bit but it may be one of the ways to do it. It just the more complicated way of doing it. So, say let's keep a way of specifying who did the assignment if we just stick to assigned and allocated.
REMCO VAN MOOK: All of that complexity you are describing is actually in the database right now, and we're not making it any easier for people to figure out what's what. There was another relevant point I was going to make but it's Wednesday, so I'm starting to lose my mind.
Thank you. I think we're done for time as well.
ERIK BAIS: Thank you.
(Applause)
If you have any more questions or comments, please refer to the mailing list.
RADU ANGHEL: Hi, I am Radu Anghel, this is a slightly updated version from yesterday's slides. I have incorporated some feedback I received. I will try to be shorter.
So, we have a lot of ASNs right now because they are 32 built, we have 4 billion of them. Very few of them are assigned to RIRs. Some of them are missing from the routing table, so we don't exactly now what happens to them. Basically, they are not a scarce resource.
Some of them are not routed from the ones assigned in the RIPE region. There is this nice document, very old document, that describes the three main criteria used foray signing AS numbers. This is referenced by all RIRs, but APNIC actually mentions it as the main criteria, so they can reject the request if it doesn't comply with those things.
In the RIPE region, the policy is not very clear. So maybe this should be updated, maybe not, I don't know.
In general, the three main criteria for assigning ASNs are: If you need to exchange the routing information, you need that if you speak BGP to other networks. So automatically you kind of fulfil this requirement. Having multiple prefixes is not that important. Having a unique routing policy is important.
What is a unique routing policy? Multi‑homing is one very important unique routing policy. It is required by the RIPE NCC, but it is not the main requirement in that RFC.
Now, do you think having a VM with GRE or WireGuard tunnels to different BGP speaking networks represents a unique routing policy? That's a question. I don't know the answer to.
Also, another thing was suggested to me that ASNs are used predominantly for Anycast. How many ASNs could be used for Anycast? So with Anycast you can do an UDP, TCP is a bit harder, but Anycast is also a unique routing requirement, but how many of them can can be Anycasted?
.
This is ‑‑ so we have established that you need an ASN. Where do you get it from? You get it from a regional Internet registry, usually the one in your region, or currently you can do some shopping and you can go for easier to deal with or cheaper RIR. This made the out of region assignments in the RIPE database.
So, as previously discussed in this Working Group, there are an increasing number of requests that come from natural persons. I thought registrations services are not happy but they generally are happy. Also, this is a comparison between the five RIRs, the RIPE region wins with the most ASNs announcing just one prefix for some reason. But this is not a contest. If it would be, RIPE would win.
What are the ASNs? They are numbers. Just numbers. They represent networks, they don't represent persons. The network can be operated by a person, can be operated by a company. That's not important. It's just a network.
People currently use these terms such as "Personal ASN" "Research networks" and they justify this to register a lot of AS numbers.
Last year it was mentioned that the RIPE NCC received requests from a one year old and an 8 year old person. The one year old didn't get the ASN. The 80 year old, I'm not sure. But that means it's a very inclusive environment, so everybody can request an ASN. That brings us to the world population. We have 8 billion people, but only 4 billion ASNs.
Now, we might have a scarcity problem with the 32‑bit ASNs. It's not a problem with the routing tables. People have big routing tables, people don't care about that, but think about the people. We can't have all of them with ASNs.
In general, there is this question: Do you need an ASN? The generic answer is no, you most likely don't need one unless you need it with some unique routing policy.
If you want to learn BGP, you don't need an ASN. You can read books, it's a better investment for the price of registering an ASN, you can buy a book about BGP and you can learn something before actually playing or not global routing table.
It has been brought to my attention that not only dissatisfaction do research, that's true, but people doing research usually don't complain that they can't get ASNs, or they don't have resources to do that research.
There is also the question: What is research? How do you define research? I wouldn't define research as having BGP at home. So, once you register an ASN, you suddenly get access to a lot of databases, where you can put a lot of information. This information is not really checked, it's user generated content. RIPE is not the Internet please. Nobody want to become the Internet please, so we have spiderman philosophy.
There is a lot of Internet of Whois graffiti, that's how I call it. People add very interesting things to Whois. It's funny the first time, so if you see one access attempt, it's funny. But if you see ten, it's suddenly no longer funny. So how many people can do this?
EICAR is also an interesting thing. I had it yesterday. That's not an A cart signature, so that could be considered art.
Apparently, it's also a discussion about these natural persons requesting AS numbers because they are private persons, they kind of don't want their information being in a public database. But in order to operate a network, you kind of need to have some contact information, so I think that by signing up for this, you kind of agree to have your information public. And complaining that RIPE shouldn't ask for this information is pretty weird.
I have had yesterday an example that you can now do software defined radio mobile networks. So I suggested people would try to obtain actual phone numbers from the national authorities by sending them a censored passport or something and telling them they're a natural person, they want this for research for their roam mobile network, and I wonder how the national authority would reply to a censored ID.
So, there is this list maintained manually. Because it's maintained manually, it's probably not complete, so I think there are many more such ASes, but most of the ASes from that list are in the RIPE region. So this makes it a RIPE problem, or feature, it depends. Some natural persons even have more than one AS number assigned. I'm curious what justification was used for the unique routing requirement. If I have one network for my PlayStation, one network for my TV, I have to have them in different AS numbers? I don't know.
This currently represents around 2% of the global routing table. This is not much, but it's AS numbers. What is too much? Is it 10%? Is it 50%? I don't know. This is also a business model. These things are usually sold to people that want to become network engineers or think they will become network engineers because they have an AS number, but you can't do anything with just an AS number. So, you need IPs, you can't get IPv4 because there is no more IPv4. So what do you do? You get the sponsoring LIR to deaggregate some of the PA and you start announcing. This is not an issue because we have space in our routers, but this is IPv4 again, where LIRs deaggregate PA and kind of share it with share customers that use it as PI by bypassing RIPE.
Besides the BGP VMs, there is also this interest service for a very, very low price will export your route to RIS.
I'm not sure why this is a must have service for networks, but it seems to be important. I think it just pollutes the route collectors with wrong AS paths. This affects the LIRs directly because a lot of time being wasted on these assignments translating membership fees. It also breaks database accuracy. It could create operational issues, a lot of Internet news that the small network did something that didn't go outside the route collectors because it didn't go through but it was recorded in the route collectors because they directly submit information there. This also affects the data quality for research because researchers consider route collector information to be mostly correct. How can we fix this? We can enforce the existing policies, for example, the unique routing requirements. Maybe they can be checked a bit more. ASN contacts could clean up some of the graffiti. And if we want more network engineers, we could find alternative ways to get them interested. And a hard option would be to vote for introducing maintenance fees on ASNs. That would be an option later today.
Thank you.
(Applause)
ERIK BAIS: Thank you for the redo of the presentation. We, as Chairs, thought it was interesting and we were requested by James, James Kennedy, to do this in an additional slot in Address Policy prior to the GM. So, any charging discussions, and stuff like that, you can take to the GM, at least prior to voting, at least you have some background on this. I am going to start on the left.
AUDIENCE SPEAKER: Peter Hessler. I am a member of the OpenBSD project. I am one of those natural persons with two ASNs. Each ASN also has an associated IPv6 PI allocation. And for assignment I always forget which one is which. I can explain a little bit of why I have those two. And it is legitimately for separate routing policies. One of them is used primarily for a server and for some hosting information and to provide address space for that. The other one is for one the projects I am involved with within the OpenBSD project, which is an OpenSource BGP routing daemon, and so I requested that and I have a hosting at an Internet Exchange, so I can get real updates, real routes from the real full Internet to my system.
So, an obvious question is: Why doesn't the OpenBSD handle that for me and they themselves register and get address space and ASNs? OpenBSD is unique in all the OpenSource communities where the foundation has no assets. We have no intellectual property. There is no assignment. And so it's not appropriate for our non‑profit to handle this. So I have it directly assigned to me personally.
AUDIENCE SPEAKER: Speaker: So, there is a lot of things I could comment on. I'll try to keep it short. First of all, I feel like I need to address the callout here for you. Because I think as the first person to have like an access thing in my, in Whois, from what I know at least ‑‑ and I will say, this did display something in multiple places including one RIPE NCC page, and I think that's quite useful that I was able to do that, and then report it to those it was an issue so they could fix it.
Second, I have to comment on the thing you mentioned about reading a book being a better way of learning about BGP. You may think that. I can say I would ‑‑ if I had not got a personal ASN six years ago almost now, I would not be here today. That is how I learned. That's how I got into these community. Reading a book would not have done that. I learned so much better by doing things than just reading a book. And I can assure you mean others feel the same. And so, yes, there may be other ways of getting more young people into the industry, but then I would say, okay, what are those ways? Like, come up with those ways before trying to limit this way, because otherwise we're not going to get new networkers.
RADU ANGHEL: But I suggested courses on BGP. I suggested joining networks with private ASNs that could send the global routing table to you so you can learn and with actual routes. There are a lot of options where you don't directly interact with the Internet. So you are basically creating a parallel Internet over tunnels. I don't think that's useful, that's not unique routing if your base provider fails, the tunnels fail and...
AUDIENCE SPEAKER: Hello. Savvas, from LAN castor university. From my point of view this is not a problem. This is a business opportunity. So, what stops me from acquiring all the remaining ASNs? And then starting an ASN intensive market like the same thing that happened with IPv4. Caning caning hopefully RIPE would stop you.
AUDIENCE SPEAKER: Let's assume that I acquired them today after this presentation. Caning caning I think you would need a lot of IDs or a lot of unique routing policies. I'm not sure.
ERIK BAIS: So there are some limitations in acquiring an ASN. Obviously processes of taking times will be stacked against you especially if you want to do 4 billion. But, you know, there are some limits in here. Also, unique routing requirements, and the NCC will ask you about, you know, where are you going to use this? Do you have co‑lo requirements? Contracts? Upstream providers? They ask you the with the actual request for multiple upstreams, contact details of those, things like that. So the NCC has tomorrow options to dampen the amount of requests you can put in. But, yeah, valid point.
AUDIENCE SPEAKER: But I am a single person. If I was a big company, let's say, I could do that, right. There is still the chance I can do it, I can adjust the space.
ERIK BAIS: I see somebody stepping up behind you.
AUDIENCE SPEAKER: You would also have to wait for IANA.
MARCO SCHMIDT: Please don't request many AS numbers, our team is very busy. But indeed, also for big companies, they all have to go through the same requirements. They have to show new routing policy multihomed and so on.
And just maybe want to use the opportunity also to address Cynthia's concerns. I think we are all in favour to promote a network engineers and so on to get into the business and working. The challenge that of course we have is workload wise, we see currently there are legit cases but people just request and they are being abandoned, and it costs a lot of work and getting this balance right, I think it's good to have those numbers out there and to think about it in this community. So, how we can serve this both ways.
ERIK BAIS: Yeah, so assigning the AS numbers, due to the contractual relationship that the NCC has with the end user or the resource holder, there are things that need to be checked, including if people are on the sanction list and stuff like that. And those are the things that you cannot automate. And it needs a whole process. So this is not something you can just automate and assign. Otherwise the NCC would have done that already 20 years ago.
AUDIENCE SPEAKER: Tobias: So, Tobias, Max Planck Institute, speaking for myself. Reiterating an earlier point. I think the main issue here is indeed the business opportunity, and business opportunity being perceived and somewhat irresponsible LIRs promoting the cheap though away vanity use of resources, and we should not sacrifice people actually learning and becoming members of the community in a bid to actually fight those. What we should consider though is ‑‑ well, it's called a sponsoring LIR, it comes with responsibility, and maybe the RIPE NCC should become well equipped with levers to put, A) responsibility, B) effort and C) costs on LIRs that are not living up to their responsibility when it comes to sponsoring end users.
AUDIENCE SPEAKER: I would not be here, I would not be the same network engineer without an AS number, and like I don't use it right now but I have the ability of having it, like I feel I can do more. I'm thinking of further projects, experiments and to learn more. And I don't think that the €50 fee that I paid to change the barrier that we have right now, I paid €50 to Glouka, I don't think that we are getting what we want if I pay €1,000,700 to the RIPE NCC to be a member to get the same thing. I don't think that's the intention you want to do here.
Also, you said that every second person would not be able to learn like this in the world with the current population. Well, the reality is not like that. Not everybody in the business asks for a personal ASN. I work in a company with 750 people, and I think I'm the only one with an ASN. So I think that the number already goes lower.
Also, is it really easy, at the university as a student, or a network engineer, at the company, to get them to provide this resource? If you go to the networking department at your university and ask for ASN, they will throw you out. If you ask for peering, they throw you out. If you do the same at the typical network company, they are going to throw you out. Well, I mean from the department where you ask them and close the door. But maybe in the end of the day, it's not how the RIR system, which is bottom up ‑‑ We don't have NIRs, we have LIRs, we provide people or people or companies things directly, and it works on a bottom‑up wards principle.
I do hear your concern that there is a lot of requests that is putting a big burden on the RIPE NCC or maybe a lot of throw away resources, something already Tobias said, but maybe some ‑‑ not ‑‑ I don't think we are solving this problem by making the walls higher to get in an ASN but maybe give a requirement to use it in two years or something like that, and I think with that we can conserve ‑‑ well preserve the ASNs to be better and just not have them thrown away. I not a lot of them are just never used.
RADU ANGHEL: Can I answer with another question: So for example in your organisation with 700 employees, would you think they would be more motivated if all 700 got AS numbers? Would you peer with all 700 of them?
ERIK BAIS: There are route servers for that.
AUDIENCE SPEAKER: No, but there are people here that I would like to peer through, even if through tunnels. And my company, well ‑‑ I am here by myself because I want to be part of this community. Like the companies are not that supportive, most of them.
RADU ANGHEL: But I think your company would be better if more engineers had ASNs.
PETER HESSLER: So we are a LIR, we are a member of the RIPE NCC, and we have two ASNs. One of them is visible in the global routing table, the other one is not. Under the RIPE policies, it is completely legitimate for us to have an ASN that's not visible in the global routing table as long as we use it for unique routing policy. Our publicly visible one is our standard IP transit network, and it does standard IP network things and everyone is happy. The other one we use for MPLS VPN,s with some of our customers who often have their own ASNs and we use this as a separation from our primary IP transit network. And so, with some of these questions, we need to make sure that we don't ‑‑ and then also for example, IXPs are probably the most publicly visible non‑publicly visible ASNs that we have in the community and we need to make sure if we aren't going to make any changes that we carefully consider the valid non‑visible ASN usage.
RADU ANGHEL: They were on my second slide. The non‑visible ones.
PETER HESSLER: My understanding of that it that it was a problem. And that may not have been your distinction. But that was my intention. I wanted to suggest that that was not a problem.
AUDIENCE SPEAKER: Kind of continuing what Peter said. So, what I think we have to do is reformulate at policy level what does it really mean unique routing policy? Because again, IX route servers privately but with a need of globally unique identifier, there are a number of cases where a non‑visible on the Internet but globally unique AS number is required, and it does not necessarily involve two upstreams. You may have no upstream or the concept of upstream may not apply, so the whole stuff of globally unique policy, I think it needs to be a little bit revised. This is about the non‑public visible ASes.
As for personal AS numbers, you don't learn to drive a car and you don't learn how to build a car by just building something and just putting a licence plate and going on the public streets. It's not how it works, and it shouldn't be how it works with learning BGP either. You can do it in a privately isolated environment, you can have some interaction with the public world, but in a, let's say, a signalled way probably. But not just everybody goes and does their stuff in the public.
AUDIENCE SPEAKER: Can I ‑‑
ALEX LE HEUX: The Internet does not exist. There is your Internet and there is my Internet and I may be peering with an Internet Exchange, so I will see that AS and you will not. So the important part here is you are globally unique.
AUDIENCE SPEAKER: Exactly. This is ‑‑ I don't think it's very clear for everybody.
TOBIAS FIEBIG: I was formally employed at TUDelft until end of March 2022 I think. I actually did ask the IT team for an ASN. Long story short: After departing TUDelft I decided to become an LIR and I have been insanely productive ever since.
The other point about learning to drive. I recall learning to drive a car on a road with a person next to me actually qualified to be an instructor but with an actual car on an an actual road, bringing me back to the point of responsibility of sponsoring LIRs, and that having to be enforced.
ERIK BAIS: So, I have a question online from Carlos." Thank you for the presentation. This issue is an issue that almost nobody is aware of. One day somebody wakes up and decides I'm going to be an Internet operator from now on, and what enables this? How cheap is it to get some address space and an AS or multiple AS numbers? This is a small issue but needs to be addressed as it has cost for actual real operators."
AUDIENCE SPEAKER: Antonio Prado, yet another BGP guy here.
So, maybe there is someone in this room who resource six bone, it was a test bed global environment to play, can we say, play with the IPv6. It was inside three FE space. There, everybody could make transit tunnels and whatever the dirtiest things on earth, just to make experiment, whatever.
So, maybe it could be an idea to have a test bed like that.
RADU ANGHEL: I want to say something about that. They actually asked for a contact details. So in order to join that, you kind of needed a RIPE NIC handle. I meant six bone.
AUDIENCE SPEAKER: So, I just wanted to make a quick comment first on why, for example, would not have worked for me, or any other isolated environment.
One the main reasons why I started to do this was I wanted to get IPv6 at home. That needed to be on the real life Internet.
Second, so, beyond workload for the Registration Services, which is real, it's a thing you have to deal with, other than that, I have not seen any real arguments against this other than oh, it makes a dataset slightly less clear, or ‑‑ I have not seen any good arguments against personal ASNs beyond the workload. Is there any other argument against it?
RADU ANGHEL: Have you considered Hurricane Electric tunnels instead of getting an ASN at home?
AUDIENCE SPEAKER: I did. That did not work because the deallocation on those IP addresses made everything break.
RADU ANGHEL: And being in Antarctica helps new what way?
AUDIENCE SPEAKER: My v6 addresses are not registered for Antarctica. That is just a single address for testing. Thank you.
AUDIENCE SPEAKER: Urbans, speaking for myself: I would like to just respond to those that say you shouldn't learn well like driving a car by driving by yourself and then learning. And ‑‑ sorry, it doesn't matter, just like in general. We have those things in other fields. I have this listens here, I am a hand radio operator and I am allowed to build radios. I can do frequencies. And I can make things break. With the equipment I have at home and the equipment that I am allowed to build, with the equipment that I am building everyday or every week. And I think that this concept, I can even get IPv4, I can still get it, I can get it from the 44 block for my experiments, and if we have a great example in the hand radio community, that this can be done, and there is mostly no damage. I think we can do the same in BGP. And that's what I wanted to say. We have examples from elsewhere where this works, and it also works in the Internet right now. Thank you.
RADU ANGHEL: So, are you suggesting having a BGP driver listens also the 44/something that Amazon got half of is not supposed to be globally routable; it's supposed to be only for use with hand radio operators? So...
ERIK BAIS: Let's not go into that one. Peter.
PETER HESSLER: I want to mention that even though it sounds like we have a lot of these assets available, we have 4 billion ASNs, we have effectively Internet IPv6, I want us to keep in mind to not replay the same problems we had with IPv4, where because we have huge amounts and like, it's not reasonable to run out of this, that we just give it away willy‑nilly. We need to have a reasonable barrier to not excessively assign too much and run out because of short sided wastefulness. We also don't need to make the barriers too high to prevent learning, development, actual real solutions.
RADU ANGHEL: Exactly. So don't use PA as PI.
AUDIENCE SPEAKER: Sander Spos speaking for myself here. I want to comment on a previous audience speaker. I don't know if you know ADSB, so you can just send out a lot of information to airplanes even without an official radio licence. But I think it's all about the ethics in the end. And that's the most important part. Thanks.
SANDER STEFFANN: I don't think there is a real operational problem that you are solving here. So I'm not yet seeing a case of moving this forward.
ERIK BAIS: Thank you. I'm going to close the line. And thank you for your contribution. If there are any further comments, we can take this offline on the mailing list. Thanks.
(Applause)
LEO VEGODA: Hello, me again. We're doing the ‑‑ getting useful information from government adjacent organisations. So when I put these slides together with the agenda, I used the term "government adjacent organisations," and after a discussion yesterday, I want to clarify, we're talking really about law enforcement organisations. This community is a multistakeholder community, and the quality of the policies that are developed in the Address Policy Working Group depends on participation from all the different stakeholders.
In the discussion we had about 2023‑4, we had some input from law enforcement, and that is great. But we also recognise that the way the world is turning, the responsibilities on this community as network operators and the RIPE NCC as the RIR, those responsibilities are deepening. So we, as the Working Group Chairs, have sat down with the RIPE Chair team and we will be doing our best to deepen the engagement with law enforcement so that we can have high‑quality discussion in the future. And where they need to interact, we can have good quality discussion.
And that is all I wanted to say on that. Just to let you know that that's something that's happening in the background, so that, you know, we're not hiding anything from you.
(Applause)
AUDIENCE SPEAKER: Brian Nisbet, with my Anti‑Abuse Working Group Chair hat on. I think I wanted to say publicly here what we discussed I think on Monday, that this is something that the community needs to reinvigorate. I am a huge fan of this and we are aware of it in anti‑abuse as well, that we had I think a much better relationship, a much more active relationship with law enforcement. It's kind of gone away, and that is I think we're seeing some problems from that. So, yay, and we want to do more in Anti‑Abuse as well and work across the community on this. So thank you.
ERIK BAIS: Yeah. It's also for moving forward also in the other discussions that we have seen and moving forward into the whole e‑evidence discussions, what's coming out of the EU, what's coming out of new acts, the DSA, NS plus, NS2, we really need to keep up in what their requirements are and how do we get them to contribute on the policy discussions that we have? And we're really seeking out how can we get them to comment in our time limits that we have in PDP on one side, and then being able to speak up publicly and get that information? So it's a struggle how to do this transparent within the community and how we do this. On the other hand, we may also want to engage with the NCC and see if there are other ways on moving this forward. Peter.
PETER HESSLER: While I do enjoy having all stakeholders involved in the process and having everyone participate, one of my big concerns is a takeover by a law enforcement of our policies. And so while this does sound very good, it is something that ‑‑ it feels a little concerting, so I recommend caution, and keeping as little private as you possibly can when you are working with law enforcement.
MIRJAM KUHNE: RIPE Chair. I am asked to say something here. I'm not sure what you expect from me. I think this is a good discussion to have, and a good way of finding a communication channel and dialogue. I don't know if you want to say non‑traditional stakeholders, not part of our community and our community processes, so on the one hand to explain our processes more, make them feel more comfortable. On the other hand, also recognising constraints they might have, and so we are working together. It's a still work in progress on how we can further, what Leo called, deepening our responsibilities in that area. So I'm really pleased to see that happening. Thanks.
AUDIENCE SPEAKER: Andrea speaking for myself. What I understood from Mirjam, we're talking about informal information exchange, not modifications of the PDP? Are we talking about the PDP? Because I understand the challenge. I think getting input from different stakeholder groups is very important, in this particular case law enforcement, but there are more stakeholder groups. So are we thinking about sort of defining rules of the game how stakeholders can be involved? Because traditional PDP process is based on personal participation not on stakeholder group participation. How that plays out.
ERIK BAIS: So, at this moment we're not suggesting that we need to make changes to the PDP. However, some people might actually have constraints speaking up in public, and it's not only from government groups but we have seen this also in large organisations within our community without naming any networks here, that have strict policies about speaking up in public, even though everybody knows that you work for company X.
So, we're not trying to, you know, force this into the PDP in a separate section, but we are reaching out and trying to engage, and this is also part of the outreach that the NCC is doing, and trying to help them towards the meetings and also read up on the mailing list and participate there.
BRIAN NISBET: I want to say, this is not new. I mean ‑‑ and I think some people in the room will remember, other people won't. We had good engagement in the past, and I said this, and we didn't change the PDP, we didn't do ‑‑ because we shouldn't, and, you know, absolutely. Unfortunately, I think some of the people we were engaging well with, they moved on to other roles, there wasn't handover. This happens with these things. But I think we were doing this without compromising our vital community values in the past, and I think we have kind of lost that, I feel very strongly that we can get back there again and get that input, which is very useful and get it in the right way. So I think if anyone is kind of going, you know, what is this going to involve? It's going to involve talking to people, and, you know, and as Mirjam said, having to explain things again that we thought we had explained, I think we just need to engage again and we can do everything within the structures we have. So ‑‑
LEO VEGODA: I think it's inevitable in any relationship with organisations, that the people change, and so you always have to reexplain. It's inevitable. To some extent, we have relied in the past on personal relationships rather than institutional relationships. We are not proposing anything huge and ground shaking. What we are proposing is that we talk to some people and we solve some meet problems, the best that we can, and then once we have made one small step, we can see if there is another step. We're not proposing changes to the PDP, we're not proposing abandoning transparency or anything like that. We are just saying we recognise we need to do a better job than we have done in the last while and we wanted to make sure that we, as the co‑chairs of this Working Group, and the RIPE Chair team, acknowledge that in public to the Working Group so that we're not leaving you in the dark.
BRIAN NISBET: I think this is not unique to RIPE. If you deal ‑‑ anyone that deals with law enforcement, this happens, no matter ‑‑ you know, changes of people having to explain things, having to bring people in, it's the same. This is not unique to this community. So thank you again.
LEO VEGODA: Okay. So now that we have done agenda item I. We have agenda item J: Open microphone.
ERIK BAIS: So this is the section between you asking questions and us getting lunch.
SANDER STEFFANN: I am very aware of that. When the transfer log was mentioned, it became quite obvious that there are only two LIRs currently using it, or testing it. I actually was a bit mean in that transfer log, the resource that was supposed to be returned to the NCC just to see what they would do. It's better for me to try it out than somebody who is actually having bed intentions. I was thinking about the transfer log, and I feel that there is a much wider potential use for it. I was talking to a friend from a bank. You know, a bank is not going to transfer away their ASNs or IP addresses or anything. So, maybe it's for them a good extra safety measure to put a transfer log on the resources because they know they are not going to transfer it, why run the risk that an administrative error somebody having bad intentions, whatever, suddenly affects your operations. So, I'm actually looking at making people more aware of the possibilities of the transfer log, especially enterprises. So if anybody wants to join me and raise awareness a bit, please contact me on the list or privately.
ERIK BAIS: I want to comment on that because I was the other one that actually did the transfer log testing.
It is not very obvious how to do it. You actually need to open just an open ticket in the LIR portal, and the resources that are under lock, transfer lock, are not visible in the RIPE Database that they are locked. So, you can only see it on the actual transfer lock statistics page.
However, for the huge amount of transfer logs that we have currently in place, there is no intent currently to change that, because if nobody is using it, why automate is or make it more, you know, integrated within the portal or in the database even? And currently, we're looking at, you know, a solution and we're currently looking at problems that might solve it, at least that's how I feel about it. It is there, and I think we should reevaluate this system in maybe a year or two, but currently, you know, it is there. You can use it but it's a bit ‑‑ you need to see how it works, and if you haven't legitimate use for it or an idea about it, just open a ticket and tell the NCC well this is what I want to do, and then they'll go through the whole authentication process with you, because not everybody could just say, I want to lock this and leave the company and then you might have other issues. So there are some processes in place, and, you know, from somebody that actually did it, I got a warning, you know, this is a fairly lengthy process, I'm used to doing quite a lot of transfers, I thought the process itself was fairly light. But this was my experience.
PETER HESSLER: I actually wanted to ask that question to Marco. If you can describe how much load and effort that the RIPE NCC needs to put in for when somebody requests being added to the transfer lock, and whether or not you feel that with your current workload, a rush of people who are encouraged to do so, how would that would affect you and your team?
MARCO SCHMIDT: I can actually can confirm what Erik said that we do some checks that if you we get such a request, is it the right person that does it, but it's manageable, it's not too much. So also from the workload, and we also, I want to second what Sander said. We think there might be good use cases for organisations and members out there that want to protect their resources, we would welcome their requests.
ERIK BAIS: So, basically you are saying you are always looking for more work, right?
MARCO SCHMIDT: Don't put words in my mouth, but that actually good work that is good for the Internet and members of course we are always happy to do.
ERIK BAIS: The option is there and if you have a legitimate use for it ‑‑ if you have a legitimate user concern about it open a ticket in the LIR portal and they'll help you through it.
SANDER STEFFANN: A sort of comment on what you said about reevaluating it. I think most people for whom this would be useful are not even aware of it because they are not part of this Working Group, they don't attend these meetings. So, I totally agree we need to reevaluate at some point. But we also should give it enough time for the knowledge to get through the operators.
ERIK BAIS: Do we have questions online? No questions. Going once, twice.
All right, so, if you have any additional questions, remarks, from any of the content presented here or on policy or you have policy ideas, speak to the RIPE Address Policy Working Group Chairs or post on the mailing list. And I would like to thank everybody, and we'll see you for the next session, if the scribe is working for the technology this time.
Thank you.
And see you in Prague.
(Lunch)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
