FRANZISKA LICHTBLAU: Please everyone we are reconvening for the second session, please find your seats, have all the lovely conversations you want to have during the lunch break. Welcome back to the second session of the today of address space. Our first speaker today is going to be Tobias, and you will talk about about TIS IPv6 PI proposal. Tobias.
TOBIAS FIEBIG: Good morning. Well, I can't believe that it's been getting close to half a decade now that we are talking about the IPv6 PI policy. Well at least over two years a bit, closer to five, which is half a decade.
We had a plan, the plan was pretty simple: Make addressing simple so we need nibble boundaries. There are some limitations in what we can do with PI in terms of assigning it to things, especially around things. We want to have more than a single 48, which is kind of included in the nibble boundary thing, within one assignment. And we do not want to introduce new bugs.
This is roughly how it's going. So, the policy is amazing because it's like this little wheel of tiny teeny threats intertwined into each other and as soon as you stop pulling in one, you get a whole bunch of spaghetti on your fork. Important: Do not try to solve policy or spaghetti with spoons. Use forks.
This is another illustration come from academia which you will straits a problem with the process around 2024‑1. So at the top you have the initial idea, and at the bottom you have the result after feedback. I think we all recognise a pattern.
So, why did we end up there? So if we want to introduce a nibble boundary, we all of a sudden have legacy. We have to wonder about maximum size because I heard ARIN has recently been assigning a /16. Do we AT&T to assign a /16 PI? Probably not.
There is funny use cases like Anycast. There is a lot of corner cases which you can come at. There is well there is limitation to 48 in terms of size, but have you heard of 64 PI assignments? Do they exist for IXP lines, you cannot routed them on the Internet but that's kind of a feature, isn't it?
There are things we kind of want to prevent, like using PI for ISP use, there is sufficient we have to account for. There is the intermixing of end site and PA and PI which are somewhat different. If we start touching one of these things, all of the other stuff comes running along.
And in addition, you might have guessed it, so this is a picture from a bike shed in the Netherlands and the Dutch are generally known to be the best bike shed creators in the world, one of the largest ones. It might be second only to the policy process in RIPE.
Coming into the nasty details.
So, nibble boundary. I think we all remember Gert phrasing his very extensive criticism of this proposal on the microphone with the words "Too much text." Which he later clarified as it actually being too much text. And a good thing you could do is you could split things out. You could split out the assignment rules and the nibble boundary thing. Well it actually makes a cleaner proposal to split the two. But, if we would first focus on getting more than a 48 assigned, we would inadvertently, if we would later want to go to nibble boundary, in the meantime create new legacy space, things their not assigned on nibble boundary we we later have to deal with.
We also, I said legacy, and keep in mind if I say legacy, I'm not talking about like IPv4 legacy, I am talking about things that are assigned in a way that might not be compatible with a new version of the policy.
It is like non‑nibble boundary prefixes and if we would want to have this aggregation idea which was also in the draft, how do we deal with prefixes people already have if they then would get like a nibble boundary assignment which covers all their needs, what do we do with the prefixes they already have?
.
We want to prevent hoarding, which I think is not that big of a problem in PI. But we also have to think about transfers. If we say like hey, we are assignments at nibble boundaries, we do not invalidate the transfer policy and the transfer policy means that somebody could be hey, I have this nibble boundary re assignment of a 44, I now want to transfer the 7th/48 to somebody else, what do we do with that?
.
It's a mess.
There is a thing about the maximum size. Currently it's relatively easy. So, we only have a somewhat definition of smallest and, an /64 for IXs so a corner case, how do we define a restriction. What is a reasonable maximum size for IP prefix? Whatever we add in there it ads complexity. There is special use cases. You might want to have a prefix which is non‑overlapping with other prefixes you are using, and you might have a valid operational reason for that. And this boils down to, if you look long enough you find enough valid use cases for this.
Then we have the routing reasons. So, what the proposal in the current form did it said well if you have an end site you get a/48 counter, and if you have like 15, you can get a /44, if you have 17, you get a/40 and so on.
By the way, I forgot to ask this in the beginning: Could I please see a show of hands who has read this proposal? Who has read it?
I am positively surprised.
So, if we say like each end site can get a 48, what about an entity that has like a lot of routers everywhere and wants to do SRv6, it says every cabinet we have on every street corner is an end sites. They have a lot of end sites and run into getting a /16. If we then do restrictions there, it might prevent other use cases which we do not want to prevent which we would prevent in the pursuit of preventing SIP use cases. Think about it SIP use cases is basically having a CPE, a device using belonging to the SIP these days at a location. So it's kind of end site. So, we do someting that prevents that. All of a sudden no longer possible is a use case is where you have like thermostat company like energy operator that is using BPNs so control the metres that put in a metre users location. A smart metre is a Linux device which does device... that is no longer policy compliant.
So, while we are at it we could, this also ads complexity.
We have PI and we have PA, and they are both sharing an end site definition. And a whole idea around what is assigned, what is not assigned as what is sub‑signed is kind of interwoven with the idea of end sites. Which is joint for PI and pay and it turns out they are very much different so I hardly see any SIP that the happily letting its end users even getting a/48 route that on their own. Nevertheless, the same definition of end site applies.
Whatever we do there, it will be a mess. My idea for the current version of the proposal was splitting the two. So having a definition of end site for PA and having a definition for end site PI. But generalising things means making things the same that necessarily are not. We are currently at the one extreme which makes both I think so this the same. Even if we split this further up, we run into all these use case issues I discussed before.
So, that very briefly gets me towards the end of this conversation, well of this engines were. What I would like to do with you now, I would gather ‑‑ I would like to gather some perspectives on these issues, what you think should be done, should not be done. I initially wanted to ask for a co‑author but I actually found somebody, and Clara was willing to get into this fun endeavour of not too much complexity, and do you see anything that should be skipped, changed, adjusted to make those things a little bit more compliant with what we want? And make those red lines a little bit more swirly and a little bit more blue?
.
Thoughts?
.
FRANZISKA LICHTBLAU: Thank you Tobias. So let's jump to questions. Would I remind you that this is a hybrid session so you can participate via Meetecho and/or here on site. I would also remind you that the Code of Conduct applies in this session, please keep that in mind when going to the microphones.
AUDIENCE SPEAKER: Thank you Tobias for the proposal. We are doing a lot of consulting in the area of IPv6 with this also government and business. We always say go with the nibble boundary, and I think we should go with your proposal and do it also on a bigger scale, and I think it will do, for us, explaining how to build address plans much easier if it's top‑down nibble.
TOBIAS FIEBIG: One question, did you read the full proposal?
AUDIENCE SPEAKER: Yes.
TOBIAS FIEBIG: Don't you think it's too complex?
AUDIENCE SPEAKER: No, it's okay. So, thank you.
AUDIENCE SPEAKER: Blake Willis, I totally agree that bike shedding is a thing, we need to be careful about that. I personally really like the idea of nibble boundary and also the fact that if you ‑‑ I use 12 bit boundaries a lot, and 28 is that, when you count down from 64, so, that's really helpful.
The one other thing I would say is that in general, when I design IPv6 address plans, the idea is really to try to throw out IPv4 thinking and go for all right I want to be one and done with this. The idea is to touch this stuff as little as possible once you provision it. And I think if that's maybe a general guideline to keep in mind when trying to avoid bike shedding, it's like how can we avoid having to tweak this later, how can we avoid an LIR having to tweak this later, right? Thanks.
TOBIAS FIEBIG: I mean that's also a part of the idea behind this, like nibble boundary extension if you get like a 44 for example, the 40 should be reserved so if you grow, get like the rest of the 40, and then you just extend your addressing plan instead of having to fully re‑number.
AUDIENCE SPEAKER: The one other thing I would add is that the, a really important goal for me is not necessarily avoiding the allegation of large blocks to say it's avoiding leaking those blocks out to the Internet but you have to little control over that one so you have assigned the addresses, what are you are going to do, right? Thanks.
FRANZISKA LICHTBLAU: Anyone else? I don't think we have somebody online. Do we have something in the chat?
TOBIAS FIEBIG: So we have the same engagement on the mailing list. Thanks to the two speakers and please read it and give feedback.
(Applause)
FRANZISKA LICHTBLAU: Thank you. Now, we continue with Jordi who will talk to us about IPv6 initial allocations.
JORDI PALET: Okay, we worked on this about three weeks ago but because the process in the PDP, it was only uploaded or published yesterday unfortunately.
Anyway, thank you very much to Angela because she did an incredible effort to have this in time and all the team.
So, this is version 3 of this proposal. We have tried, together with our colleague, Rinse, tried to capture the discussion in the previous version in the list and also in the previous RIPE NCC meeting.
A summary of the proposal, you know we have been discussing about the changes in the IPv6 allocation policy for a couple of years, at least probably already more than that there were some meetings where we discussed different aspects of the. Basically the idea was to make IPv6 easy to get, encourage roll out. We also discussed that aggregation is important, and conservation is still relevant of course.
So there are a couple of links here if you want to see those discussions, and the summaries that the Chairs do it on those discussions.
From the NCC team, we also got some stats which were part of the basis for drafting our proposal as well. Basically, the idea is that there are many allocations that are smaller than a /29 and in summary approximately about 91% of them could be extended to /28. The main discussion is why do we need a /28. Probably there are many many ISPs which a /32 they have enough, but there are some medium sized ISPs which don't have enough, which is /32, or /29, and they have a strong difficulties to justify the need for a bigger allocation, okay? So that's the basic problem here.
So some of them were how by passing the problem by creating different LIRs, okay, so that's part of the problem.
So, what we are trying to do is again simplifying the allocation for the majority of the ISPs, typically I just said, medium sized ISPs.
Now, in the slides, you have used two colours, the black text is no changes, the blue is what we proposed in Version 1 and 2, and the green is the small difference between Version 2 and version 3. So basically, in the previous version, we were saying that you can get either a /32 or a /28, AUP part of the discussion was why not something in the middle? So we changed that. So the idea is you can get anything between a /32 and a /28, okay. So this is very, very simple change.
Now what happens with existing address space holders? In the previous discussion, there was also the problem of if we allow every LIR to extend all the locations they have, okay, so if you have an organisation or a member that has five LIRs, they could extend five, the five of them, okay? And there is some of these members which have multiple LIRs, they did that because they had this problem, they have difficulty to justify a bigger location, but we know there are others that they do this because they are stockpiling and probably then doing transfers. So, part of the previous discussion was: Do we want to facilitate the people that is just getting addresses for doing business and getting money and then doing transfers to get more and more and more space? So, we thought that the community didn't like that idea and one the proposal solutions was let's allow a single upgrade to a /28 per organisation or per member in our feeling I think we initially were talking about the organisation but it was said: Well we don't have the organisation in our text, so we need to use member, okay? So that's the reason we used member. I want to state this because this part of the discussion probably later.
So, this is what we are proposing if you have multiple LIRs, you will be able only to extend one of those allocations that you originally got as a single allocation from the NCC. That's the text.
Arguments supporting the proposal: Well it's a relevant update of the policy. Policies are not something that we never change. We want to adapt them to the reality. That's clear.
We are trying somehow to reviews we had for the justification. This is good for both the NCC and the members.
We provide some additional flexibility to get more space without the need for that justification that for many is not easy because the policy don't simplify the life to those that need for addresses. Extensions only for the originally issued allocations, so if you got a /29.and you split that in multiple transfers, we want to avoid that each of those could be extended as well.
I said that already, only one extension per member. To avoid the potential bad effects in the case of stockpilers.
And we mentioned already that basically about the 91% of the members ‑‑ sorry, of the allocations, could be extended not including stockpilers, okay.
Arguments opposing the proposal. Well, somebody mentioned in the list that it's perceived as counterproductive for the conservation efforts. Actually, for each new /29 allocation by the NCC, they already reserve a /26. So this is not changing the overall space which is being reserved or blocked by the NCC. So this is somehow not really such a big problem.
LIRs still cannot, if they don't need a /28, to choose a /32, 30, 31, 29, whatever, okay, so it's not mandatory that you really ask for a /28, if you don't need that.
Then by extending the initial allocation, LIRs gain the ability to split and transfer and our counter argument is precisely that we are only allowing one. Okay, so we are trying to fight that in that direction, which ‑‑ that restriction.
And finally, we have the ‑‑ make very, very quick summary of the impact analysis.
Impact of policy on registration on addressing system, well more addresses in routing table. Change of routing table grow. But also there are options for aggregation and instead of announcing 2, shareholder 29s you can perfectly announce one /28, if you get that. So that has the negative and positive sides as well.
Impact of policy on RIPE NCC operations and services. We may expect a peak, a short‑term peak in requests from a ‑‑ extending from a /29 to a /28. I think the impact analysis management is something like 15,000 tickets. I don't really think everybody will extend that. And the demonstration that have is that many of the existing allocations of a /32 have not been upgraded to something else. So, it should be the same here, right, we cannot expect everyone asking for the upgrade to /28.
It's true that there may be some confusion because members could expect that all their LIRs could be extended. So there could be some rejection of tickets because only one per member.
But in the end, there will be less growth for both NCC and also the multiplex, so it's an advantage that they can get, most of them they can let the allocation they need instead of fighting with the documentation for asking for more. So I think it's a balance. Yes, there may be some extra tickets at the beginning or a split across multiple years. But I don't really expect that to be a real problem, and it's really compensated, it's there for evaluation of a bigger allocation request.
And finally, RIPE NCC executive Board input, there is this discussion with using the term "Member" instead of "LIR." And if we recall correctly, in the previous version of this policy, we were not using "LIR," it was only possible to get allocation per organisation which, in this sense, it's the same as per member, right?
.
So, I understand the concerns from the executive Board, but we are going back to what we had before somehow. We are still allowing each LIR of a single member to get allocations but at the same time, we are saying we want to put some restrictions on that.
Okay, just it was not my last slide, it's this one actually. Just to mention that this policy proposal comes from a broader idea to take on the considerations I mentioned at the beginning we have been discussing is several years, this is the first step to what we are trying to do, but it was recommended by the Chairs that we split the proposal into smaller parts to facilitate the discussion. So that's the global idea. The main point is probably going to a scheme where we allocate basically in the nibble boundaries and we replace the HD ratio by a table corresponding with different sizes of ISPs with different nibbles for the allocation.
And with that, I think I am done.
FRANZISKA LICHTBLAU: Do we have anything in the chat? We do, so let's start with that for a change.
SPEAKER: Andrei from the RIPE NCC is asking: What is your opinion on charging members for more than a /28 than for longer prefixes? I know that this is the RIPE NCC matter but I wonder what you, as an author of this proposal think?
JORDI PALET: Can he repeat the question?
FRANZISKA LICHTBLAU: "What is your opinion on charging members for more /28 than ‑‑ more for a /28 than for longer prefixes? I know this is the unlike GM matter bur I wonder you as the author of the proposal think?"
SPEAKER: I think there are to promote IPv6 deployment, we don't want that people with larger than 28 get charged more so that's I think the essence of this proposal too.
JORDI PALET: And I should add the discussion on charging is irrelevant to this Working Group somehow right? It's ‑‑ in different registries they do the charging in different ways. RIPE is unique on that, that is not related, the charging scheme is not related to the size of the allocation, so it's a different discussion.
AUDIENCE SPEAKER: Dmitry. Speaking for for myself. I am glad we are going to simplify the DNS delegations to, you know, that 29 was a bit painful. We are sorry to holder, I understand all of the motivation. I am all for it. Because you say organisations I guess you should say members, just a nitpick. I guess what I want to say when you say first, because we are going back to member versus LIR count, maybe we should explicitly explain what happens when a member has multiaccounts, but then choose some of them were transferred and these accounts even though transferred later may have the RIR allocations, this is nitpicking, because they have multiple accounts and only one of them would be eligible as I understand the language of the proposal, maybe that should be this phrase they ‑‑ just say the single one, one of it D it doesn't matter which one they upgrade I don't think so. If they have multiple accounts they can upgrade first, second, whatever.
JORDI PALET: If I understood you correctly, that's what we are proposing. We are proposing that only one of the accounts can be extended.
AUDIENCE SPEAKER: Like our list I think, I think that is not necessary, or, or list allocation, I think that is not necessarily a qualifier, just a single one. Okay that's a little thing. Okay, bye.
FRANZISKA LICHTBLAU: Other microphone.
AUDIENCE SPEAKER: Erik. Most of IXPs are using /32, so, having more than /29 I think is not just for stockpilers, but also for LIRs who have a lot of ISP clients.
RINSE: What's your question actually?
AUDIENCE SPEAKER: Just a comment. So /29 is just not for stockpilers. It could be also for people that need more than a /29, really need.
JORDI PALET: Yeah. What we are saying is actually that there are ISPs that need more than a /29. So that's the reason to do the policy. What we want to avoid is stockpilers to take advantage of that and have much more than they should get.
AUDIENCE SPEAKER: Okay. Thank you very much.
AUDIENCE SPEAKER: Tobias. I do think we have the same problem, because technically your proposal is a one character change, like making an 8 from a 9, and now we have all those lingo about members, LIRs, and it's getting more and more and more text. And I think somewhat like same as mine, this proposal has already, has less text running in the wrong direction there, and we should think about how we can make that more simple. So one thought that came to my mind was like an LIR may hold up to a /28 without further justification, that would be an approach that would actually harm me because you have a 29 and 32, meaning that I could not extend that 29 to a 28 without returning the 32. But it would most likely simplify this whole discussion about stockpiling etc. Then of course we have the nibble boundaries etc., etc., which is also an interdependence of the proposal, but the current pathway with trying to explicitly account for like what are the nasty people are doing might be just a rabbit hole too deep.
RINSE: I think exactly the discussion about the word "LIR member is important. Like this with LIR, changing LIR to member we stride to fix the whole stockpiling thing and I doubt it's a big issue because Marco presented about it and it's pretty small group, but it's up to you, do you want to fix at that issue, then we switch to member, about you if we switch to "Member" the NCC states you open up pandora's box that the member is more a legal entity and LIR is more the operational so I think this is the most essential question we have. Thank you for the comment, Tobias.
AUDIENCE SPEAKER: Hello. Piotr. I would like ‑‑ not this one, from a couple of meetings back, I would like to quote you, your words, and it was "we are still allowing each LIR of a single member to get allocation but at the same time we are saying that we want to put some restrictions on that."
So, I think that you are mixing LIR and member first of all. This policy is about the member, so it's, in my opinion, completely not sure we are still allowing each LIR or single member now. Basically we want to ‑‑ that's my understanding. You want to restrict that to a member, not to LIR. This is a different story. So, either please clarify please or ‑‑ maybe I am wrong.
JORDI PALET: As I mentioned before, in the previous version of the policy, we were using "Organisation" which will match which member in the sense of the documents of RIPE, okay. So, we are not doing something so strange. We are just going to, going back to ‑‑ for a restriction using the terminology that we were using before. Now, if the community believes that we should forget about the stockpiling problem because it's being sorted out in a different way, we are happy to change again the wording and use "LIR" and problem solved. So that's... I don't feel this is a strong problem to keep going on if we need to just remove "Member" and keep "LIR" right?
AUDIENCE SPEAKER: I think that there is a misunderstanding. We can discuss that later. I am first of all personally very against stockpiling, that is a personal thing. But yeah, do you recall when the word "Organisation" was used? Like how many years ago?
JORDI PALET: Oh... 2008. And it was probably my fault moving to LIR because I am the proposer of that change.
FRANZISKA LICHTBLAU: 2018, Angela just said.
AUDIENCE SPEAKER: Then since 2015 this was this problem of multiple LIRs because of run‑out of IPv4, so probably the word "Organisation" was used just by is make and we shouldn't repeat mistakes from the past. So, taking this as an argument, I wouldn't follow that path. Okay, thank you very much.
AUDIENCE SPEAKER: Mike Booth. I just want to draw that there is a case where a member can have multiple LIRs, these can be different companies, different ISPs if it's an MSP maintaining them and they never know when one company or LIR account is going to be sold off. That's why they want to keep them separate and operate them independently so they want to have the opportunity to grow multiple LIR allocations at the same time. Also, at a recent Cisco live event there was a lot of pressure for smaller enterprises to go directly to RIPE and get a /29, when I think it would be better that they encourage, these smaller companies are encouraged to go and get sponsored resources and I think we should educate people on that a bit more.
AUDIENCE SPEAKER: Blake Willis again. First one, I think in terms of stockpiler prevention, the things that I am worried about are not necessarily everybody being able to get a 28. It's certain other RIRs allocating like a /16 to a financial entity and there are more than 65,000 entities in the world that are larger than that entity and maybe that's a better policy, that sort of thing. Really the big blocks. And second thing was, are it feels like maybe one the reasons, you know, whenever I create an LIR for a client, I pretty much automatically hit the please make this a /29 button. I feel if there is a bit more friction in there that says okay you want a 28, just tell us why, you know, the policy is the unlike will still evaluate it but ‑‑ because I have asked for a 29 to become a 28 before, they said your reason is not good enough. The point has created a bit of friction there and not have the automatic plays thick in a 28 and suddenly all the 29s will turn into 28s. If there is a bit of friction there, that will drag out that process.
I feel like in the IPv4 fair run‑out with the /24 per LIR that we had a decade ago, the idea that once you ask for your last /24, you couldn't transfer it for two years, I feel that was a really good way people preventing LIRs and immediately selling the 24 and I think that's a really good policy to apply here, especially for anything bigger than a 28. I think it's really important to draw a distinction between I need a 28 because it's a night nibble boundary and its 12 bit boundary I use and hey can I have a /26 today? There is a really big difference between that. So thanks.
AUDIENCE SPEAKER: Tobias. I would caution against any form of friction because it we just install a little bit of friction for example such a text field, it means the RA actually has to read, understand and follow‑up if there are inconsistencies in that text field and that will quickly quickly quickly end up (A) costing more money as members, and (B) if you are in a company, that you have a valid reason for a 28, and the RA does not fully understand what you are saying, like people communicating, it happens all the time, it might delay the process and this delayed process might also cause these new members real money. So, I would be a bit cautionary there.
FRANZISKA LICHTBLAU: Do we have anything online? Nothing on the chat? Nothing here. Then, thank you.
(Applause)
.
Next up is Urban, discussing his proposal to removing the multihoming requirements from the ASN requirements.
SUHADOLNIK: Hello everyone. I'll present the new ASN criteria policy proposal. We have been asked by the community in Prague to look into removing the multihomed requirement for new AS numbers, and we prepared it in the in cooperation with co‑chairs.
So, in this proposal, the main point the removing the multihomed requirement but we also acknowledge two things, that's like we have 32‑bit ASNs, ASNs are no longer a scarce resource, and our policies should reflect that. And also, that the current, the current requirements in the policy are not actually enforceable in the practice.
So if we are looking to the, look into this, that was actually, it's by right, the RIPE policy on ASNs, basically half of the allocated ASNs are only multihomed were close by, and the other happen is either not visible or single‑homed. There have been some point in the past that this information might not necessarily be true, that the actual state is a little bit better, but this is at least according to the NCC. So, the NCC believes it's like this, and there is no acting on it.
So, the other motivation was also that if we write the policy, at least for me, it was important, a policy that will not be just a piece of paper, and with the current unenforceable policy we have a situation where there is a lot of lying in the applications. This has been confirmed by multiple people to get single‑homed ASNs.
So, the current policy, there are basically, if I can shorten it to three bullet points, is that ASNs have to follow RFC1930, that means they have to be multihomed to qualify Tor an AS number, and they have to document their routing ‑‑ a unique routing policy in the RIPE database, and some boilerplate on the low part. So, just ‑‑ just before remove on, this part stays the same in the new policy text.
So, the new policy text is a little bit longer. So, the first part is, the policy is "LIRs and end users may be issued the first autonomous system number upon request without justification."
The idea is if you request, if you need and you are prepared to pay for the fee, that you probably need an ASN. With the current state of the allocated 32‑bit ASNs, there is no fear if everybody has one or even 10 AS numbers. And for additional ASNs, you need to peer with a third party, but also ‑‑ but the same as before, write the ‑‑ write your routing policy in the RIPE Database and the documentation provided to RIPE. So essentially you can, for ‑‑ you can request for every single‑homed site you can request an additional ASN but you have to peer with a third party. So you cannot peer with yourself. You have to have an upstream. That is to prevent chaining of ASNs in a needless way. So there are also like the stick, how to prevent abuse. Yes, you can request, you are six months to do so, and enforcement by the NCC, at least for what I talk, they don't want to take down existing networks. It's also very hard to go after people. So basically, when you request the next ASN, the idea is that the Registration Services would check if your existing ASNs follow the criterion up to date the documentation that you have provided to the NCC.
The second thing is it says you have six months to do so, if you are rolling out multiple sites, you need multiple ASNs for six months you are off the hook. And after six months you have a problem but there is still this part that RIPE doesn't want to take down your network, so you have something for that.
And also in the past in the current policy uses where the AS is not visible in the GRT are not supported, and there is quite a few cases when you have that. So that's also in the ‑‑ that's also in the new policy, as long as you provide the document, how is it used.
So, we have also considered some edge cases. So, what happens if ‑‑ so the first one ‑‑ so what if you have a legal entity, or an entity in general, with very diverse branches that might want to peer with themselves? So usually you would say well just ‑‑ usually that would be separate legal entity but there are some cases when they are not. So, we thought about the case of let's say you have SpaceX which is not an ISP and you have Starlink which is obviously an ISP. I think, I personally think it's completely reasonable for SpaceX to be like a customer of Starlink or even be completely separate n this case you basically, if I go back to the policy, that's why it says "LIRs and end users" so basically if an organisation has multiple LIRs, they can request the first ASNs independently of them. So that's basically some sort of a loophole for needs like that. I think there could also be other divisions in certain big organisations where they would want to run those networks separately.
So arguments supporting the proposal. As I said before with the successful migration to the 32‑bit ASNs, they are not a scarce resource any more. We should use them in a way that helps us. Our policy should reflect that.
And currently, so we have 4 billion 32‑bit ASNs. IANA has allocated 4 hundred and 2000‑ish for the RIRs, which is 0.01%. While the RIRs have only allocated 88,000 ASNs, which is 0.002 percent. So this pie chart is actually not that useful.
So we do have enough of this. And maybe if I go back a little bit. If we have cases where in the past where multiple sites were run under the same ASN number, if we just give every of those sites their own AS number and actually have it clear where it's coming from, then it's not interconnected, that might be helpful, and we have enough numbers to do so.
So, arguments against the proposal:
Would this increase the complexity in the GRT? I think we have cases in I think it's RFC 2270, it's the single homed customers of the ISPs, it needs to be run under one shared common AS, that is requested by the ISP. That's bad because we have different organisations under the same number that have nothing in common. But in those cases we could request an ASN for each of them, but in the GRT, the prefixes that are going the GRT are still like the same size. So it might not the same effect as expected.
.
The second a bit more real problem that maybe new technologies could be built on easy availability of AS numbers which would increase the rate of U ASNs. We do have fees now which could mitigate this to some extent but really if somebody would want to do it, the fees are not that high and maybe we don't want to have them much higher has been that.
So, again you are entitled to the first ASN, the poll proposes. No questions asked. Multihomed requirement is gone. But you need to peer with a third party. You have to follow the documentation and the purpose that you have provided to the RIPE NCC or updated it. And you have six months to do so.
That's it.
So, open questions that remain: What to do after six months? Should there be a higher responsibility for LIRs that are sponsoring a lot of ASNs? And any other feedback that you have. Thank you.
(Applause)
LEO VEGODA: Thank you very much. Thank you for taking this on. We really appreciate the fact that you have stepped up and put in the work. We'd like to invite people to ask questions or make comments, both at the microphones in the room and on Meetecho. Jordi, I see you there.
JORDI PALET: I support the proposal. I think the text could be much, much simpler. In fact, in October, exactly 28th October 2020, after Marco's presentation about ASNs in the region, I submitted officially a policy proposal doing exactly the same and I am still waiting for any confirmation from the Chairs. Interesting.
LEO VEGODA: Any other... we do have a speaker. Go ahead.
AUDIENCE SPEAKER: Will. I also support the proposal, and yeah, just had to raise, just wanted to come and say it's a good thing and it would be useful for us and I will use it soon. That's nice.
AUDIENCE SPEAKER: A quick comment. I don't know, are we creating a quick adapt, like in six months, then what? Are we going to create a work item for every request? I do support the proposal in principle but I find the requirements strange.
URBAN SUHADOLNIK: Is for six months.
AUDIENCE SPEAKER: Yeah, I think, okay, let's assume that normal, quote unquote, people can still though these two upstreams and nobody is really going an checking the contracts. It really need one and I do believe there can be a reason for that. They may say this initially and I just don't see why they are waiting. If it was impossible before waited for so many years for that, now this passes can be all getting ready and get this thing in in order once a proposal is reviewed and implemented. They would have more time than that, and then going forward, everybody would be aware of new policy and would come with a preparation. I don't think that a waiting period is necessary. Like I said, it creates a quick adapt, it's like a semi‑legal. In my opinion it's okay to have an I think is he will user LIR.
You are paying for that too, €75. Right? It's going to feel like if you start participating for the things you should be allowed to get one if you want to. I don't know, maybe should have a limit of how many of these. That's another thing. Like I had said, I don't think that waiting is necessary. I think it just makes people like conditionally approved. But otherwise I support, maybe yes the wording could be shortened. I can read the text with my eyesight, but usually shorter text is better, but thanks for the work. Add and I wonder what is the other proposal to slit maybe should bring you back. It feels really bad. Right? I mean the one that was...... comment to the comment.
URBAN SUHADOLNIK: Thank you. Sorry, I wasn't able to understand everything from here. But I got the gist of it and I will also watch the recording if I come back to you directly.
Thank you for your feedback.
AUDIENCE SPEAKER: Tobias. Also. What I would like to emphasise in my personal opinion more responsibility for LIRs especially for end users assigned ASNs is something that we should very strictly consider, especially also, and I know that's part of this Working Group actions in the context of this charges because I realise technically as an LIR you can outsource KYC free to the NCC because as soon as you ask for numbers for an end users they will do KYC. If that fails it failed, if it doesn't fail someone at KYC for that end user and you know that is you do the request request that end user's data that data is probably kind of correct.
So I do think that all these things which are currently more in like ticket and check after six months, especially for end user ASNs we might be able to put that more on the LIR, and have it more in a framework of if during an ARC it turns out that they were doing their job, gets expensive for the LIR, just as a thing to float in here for the LIRs that have a lot of end users.
AUDIENCE SPEAKER: Thank you Tobias, this is a part of a conversation we're having this one in public. We could consider to put also put together together to an LIR and put in a separate discussion and maybe combine it with this policy. I know some edge cases LIRs that I think are doing a good thing, but the ASNs that they are sponsoring are not following the policy.
I wanted to respond, so, for, also to demeeto, I collected my thoughts, there is also I think it's ‑‑ so after six months is either doing an audit is when you would get checked what's happening, as I said, at the next request, and I would just would not like to have, I would not like to have organisations sitting on a bunch of unused ASNs, even if they are participating for them. But I think after six months, if you provide a justification or where they got the feedback from the NCC that they would probably extend it. So, yeah...
Anyone else? Any feedback? Is there anything online?
LEO VEGODA: No.
URBAN SUHADOLNIK: Okay.
LEO VEGODA: In a moment we will start the Open Mic, but before that we have an announcement from the RIPE NCC.
The NomCom will hold office hours during the second half of all lunch breaks from 1:15 until 2 p.m. Come by to the room to speak in person to the committee or arrange for separate meetings with committee members. Also, you can share feedback on ICP‑2 from 1:30 until 2 o'clock at the meet‑and‑greet desk.
So, thank you very much. We are now opening the microphones for the Open Mic. I know we cut off the microphones just before the coffee break and there were people in the queue. This is an opportunity to return to the queue and that topic. It's also an opportunity to go and say: Hey, I have a problem, and find out if this is something that can be solved with a review of an implementation or maybe it needs to be a new policy proposal.
JORDI PALET: I have a problem. I understand this is a difficult discussion but it happened to me several times, and I think the community knows that I have been contributing to policy since 2001 actually, not just in this region but in many others, and if you follow the PDP, there is a clear description of how you submit a policy proposal. And yes previous discussion in the list is encouraging but it's not formally regarded . And I feel a strange situation like I mentioned a few minutes ago that there is a discussion in the meeting about the problem with ASNs, somebody says: Hey, I have an idea, let's make a formal policy because we discussed it already in the room. And you never get an answer. Okay.
If you have formally submitted a policy proposal, you should expect its published. That's it. Nothing else.
Now, second problem, and you know that we discussed this in Rome, is if a group of authors get together, prepare an IPv6 original policy change, and this is not something personal against anyone, okay, just to make it clear, if a group of authors meet together, draft a policy the Chairs said split it in two or three policy proposals. We did that. Then one the authors decide to step out but the other two authors already submit the three policy proposals and then for some reason the Chair said, no, we don't accept it or they just don't say anything and they accept the policy proposal that has been submitted by one of the authors that stepped out from the group. It's strange. I mean, it doesn't make sense. It doesn't make sense to me that if I submitted a policy proposal, and again this is not against me, it's against if anyone submitted a policy proposal in 2020 and he didn't get a response. And then somebody else sends a new policy proposal about the same topic five years afterwards, there is no discussion on that. Why we decide, why the Chairs have the power to decide who is able to send one or other policy proposal and why. If there are different authors working together, the Chairs have the power to decide no, I choose this one instead of the other one? It's the community. It's not the Chairs.
LEO VEGODA: Jordi, it is the possibility of the Chairs to manage the Working Group's work, and I think if you want to have a separate discussion with us as a group of co‑chairs, we will happily sit down with you. I don't think we should go into what has happened over five years right now, especially as there are other people in the queue. But we're happy to sit down and have chat with you, but it is the responsibility of the co‑chairs to manage the work of the Working Group.
JORDI PALET: What you told me in Rome, it's not five years ago, is: Oh sorry, we missed that e‑mail from the ASN, we will revisit it and I still don't get an answer.
AUDIENCE SPEAKER: I am not going to discuss any policy proposal just an explanation to what you said. Yes, you can see the NomCom if you want to find NomCom in Rome you mention you go to the lunch, you change your mind do an exactly the opposite. You kind of see the door. And then through the door, which is unmarked you go to the corridor, you see the kids room with the balloons, unfortunately unless you should not go there. Next door after that is a NomCom, I do believe the other room, no, no, I think ‑‑ the other room after that should be I think staff room. Anyway, well maybe we should have this ‑‑ but it's a second half of lunch everyday, including today's lunch and tomorrow's lunch and the Friday's lunch for those who here. I am of NomCom number and they have a NomCom written on the badges. Just a clarification, because it's very unclear where the actual NomCom. I was able to find it on my......
AUDIENCE SPEAKER: Clara Wade. I think there is another aspect of RIPE policy that is being exploited right now, and it's the lack of utilisation requirements or a needs based policy when we did away with this in 2013, I think, its goal was mostly to reduce bureaucracy and there was a lot of trust put into the community to act in good faith. Unfortunately we're not in 2013 anymore, and there are some organisations who don't even run a real network who are getting space transferred and encrypting it or monetising it, and these are not small allocations either, if you look at transfer logs you can see /16s, 15s, 14s, I can see Marco nodding here, and sometimes these are also legacy IPs where there is no contractual relationship, and they are not engaging in best practices like enabling RPKI and keeping that legacy status even after an inter‑RIR transfer: So I think we had a similar conversation with the IPv6 issue recently where there are also instances where there are entities that are enabling other entities who would not be able to meet RIPE's basic compliance requirements, perhaps it's time we had the discussion of having a needs based policy again.
LEO VEGODA: Thank you very much. Go ahead.
AUDIENCE SPEAKER: Piotr. I have been digging in the past, getting back to the Italian meeting, RIPE 54, it was an interesting meeting, Hans stepped down from being address space Chair, and Sander asked to stand as a co‑chair next to Gert.
But then once again, Talin, a long time ago, I proposed something to ‑‑ I stepped up with the proposal to extend one back then /32 allocation to the possibility to have two. And according to the minutes and my memory actually, Leo Vegoda from ICANN was quarrelling with me, or we had a conversation about that, and you wondered why two different businesses used one LIR. That was interesting fun, but, you know, we ended up years later with someone else proposing to extend these /32 to 29 and we have that right now and we are discussing 28. This is just a comment, maybe, most likely to Jordi, that maybe somewhere in the past there was no time for asserting proposal, and instead of like thinking about that, it's better to move forward and just cooperate with the, in the new reality. So, it happens to me, it happened to others that the proposal was not accepted, and then a couple of years later someone else would basically got the same idea and it was, it gathered and it was accepted. Just move forward, and accept the reality. That's it.
JORDI PALET: Then we should change the PDP to say that. Otherwise we are not following the PDP. Very simple.
LEO VEGODA: Do we have any comments or questions online? We don't. We don't have anyone at microphones. So I think that means that everyone is exceptionally hungry.
I have got to press the green button. We meet here in person and online twice a year, but we're always online on our mailing list. If this is your first time in the Address Policy Working Group, I encourage you to sign up to the mailing list and follow discussions and participate in discussions. We will hopefully see you all in Bucharest in the autumn. We just have the Open Mic, and that means thank you all very much for participating. Thank you very much for taking our words and turning them into text, Mary. And enjoy your lunch.
(Applause)
.
(Lunch break)
