Address Policy Working Group
18 May 2022
9:00 a.m.
LEO VEGODA: Hello everybody, good morning and welcome to the Address Policy Working Group. And this is obviously a hybrid session. We have people joining us in the room and we also have people who are joining us online, and the session is being streamed and is being recorded and published at a later date, the Chairs for our session today are here, and we'll be taking you through our session, we have two sessions, and but before we get into that, I am just going to remind you we have a code of contact. The idea of the code of conduct is make everyone feel welcome and it can be summarised as please be respectful to everybody else. If you treat everyone else with respect, then the session will go smoothly and everyone will have a good time.
So, I am going to run through the agenda and this is an opportunity for people to note whether we need to change anything, whether there is something that is missing, but before I do that I'm going to point out that we do have minutes from RIPE 83. They were posted on the 6th January. We haven't received any comments on the mailing list. I'd like to ask people in the room whether they noticed any issues that need to be corrected or if we can accept those minutes. I see some thumbs up and some nods. That looks good. So, let's move ahead.
.
So, we have got two sessions today. We have got these four items, then we have got a coffee break and then we have got another four items. This introduction, which includes the appointment of a co‑chair, NRO NC update, a policy update from the RIPE NCC, and then we have got not a policy proposal, but a review of the IPv6 policy and the goals coming from Gert. Then there is a hot drink of your choice. Then we resume, we have a Registry Services update to be followed by a concept policy proposal that arose from the Database Task Force.
So, a volunteer has come forward to turn a recommendation from that task force into a concept for discussion, and may be the Working Group will decide this should become a formal policy proposal, maybe not.
Then there will be a discussion on the IPv4 waiting list. This has got quite a lot of list discussion. And then the AOB and an open mic session.
Now, throughout this, when we have questions, people who are here in the room can go to the microphones to speak. It would be very helpful to us because we have a hybrid session and we will have people who will be participating online and contributing online, if you could go to the Meetecho side room thing that came in your e‑mail this morning. Click on that and there is an icon with a hand, and when you want to speak, if you click that hand, that helps us manage the queue because we'll have a single integrated queue and we can go and call the next person to speak.
So, this is the plan for today. Does anyone have any suggestions for changes to this or are we good to go? We are good to go. Excellent.
So the first item of business is selecting a co‑chair. We had one volunteer, Erik. Erik is stepping down and nominating himself for reselection. Now, there is a process which is documented on the website and it says that if someone wants to volunteer, they need to send a message to the mailing list before the RIPE meeting has started. We only have one person. So, that is Erik, Erik, do you want to say anything?
ERIK BAIS: Good morning everybody. Yeah, so it's been, I think it's my third term now, so for me it's not the first time. I am definitely looking forward to doing this again. If there are no formal objections, then anybody else, I'll do another term.
(Applause)
LEO VEGODA: That sounds like a warm consensus to me. In that case I think ‑‑ yeah, so that's going to be the last slide of the day. So in that case, we have completed the introduction and the appointment of a co‑chair. I am going to hand the microphone to Sander who is going to give us an update on the NRO NC. Thank you.
SANDER STEFFANN: Good morning. Some of the ASO AC/NRO NC.
Here we go! So, what is it? The NRO Number Council. It's a voluntary body, it has 15 members. We have three members from each region, two members of the region are elected and one is appointed by the Board of the RIR. We're observers in the RIRs and ICANN. And to make it more interesting, every RIR has a different term for who they delegate to the, to this group.
So, we do advise ICANN Board on number things. We do the global policy development process review, and we actually appoint some ICANN Board members. IRR, and select representatives to ICANN bodies. So we have a monthly call, we try to do face‑to‑face. Obviously that has been a bit difficult, but I really hope we can manage to do that this year. And, so I think for this group, the global policy development is the most important. So there are a couple of things. So one thing is I had some people ask me, okay, I have this policy that I want to implement in all RIRs, is this a global policy? Usually not. The global policies are the one where all the RIRs, together, all the regions, for example instruct ICANN. So, the policies from ‑‑ how ICANN gives AS numbers to the RIRs, that's a global policy. And that's what we do when we review the process.
So, who are the members? Well we're one person short at the moment. One person from AFRINIC should be appointed by the AFRINIC Board. They seem to be having some issues at the moment, so that is still ongoing. And as you can see, the names on the slide, the person ‑‑ the people with the star after their name, those are the people that have been appointed by the Board of the RIR. The other two people are the ones selected by this community.
Now, like I said, a global policy development. We rarely have them. Like I said, they are only for cases where we need to tell IANA to do things.differently but we do have a facilitate air team. So from every RIR, one person of the NRO NC is appointed to help people understand what global policies are, how to submit them and that kind of thing.
Now, we do have monthly meetings. These are open to observers. And everything has been done online. The next ICANN meeting in June will actually be a face‑to‑face one again. So, that one will be in The Hague.
We have obviously open records on the mailing list. The conference we do is at midday UTC on the first Wednesday of the month. And I see I forgot to place 2021 by a 2022, but that URL also works for the 2022 meeting calendar.
We have some appointments. I'm not sure if ‑‑ Herve, please correct me if these are still correct, because these were done before I joined so I might have made a mistake here.
So these are the current ones. Their term ended and there has been a new selection process. This has been completed and in all the RIRs it now has been announced that seat 10 for the next term will be taken by Christian Kaufman. There have been some mentions, because Christian is also the Chair of the RIPE NCC Board, but he has notified us that at the end of this, of his term, he will not run again for the NCC Board to minimise any overlap and conflict of interest.
And that was it. Any questions?
SPEAKER: One part and so remember the AC AC as James and Sander as well, so thank you as a presentation, so it was a complete etc. Thank you very much, just when going to the microphone, I noted that I had completely forgotten to go to Meetecho. So sorry for that. And just one additional remark, so there will be some work about the day to day of the operational features of the AOAC so the last election, so Christian Kaufman win. So we thought there was a problem regarding the definition of the way we have to vote etc., etc., so we decided to have a bigger date of the persons considers, there was a possibility to be online etc. Because of the coronavirus, and there is the question of the missing place for AFRINIC because it was impossible for IANA to belong to the AOAC any more. So there will be this work this year and probably next year. Thanks.
ERIK BAIS: Thanks for the additional info.
SANDER STEFFANN: I didn't realise this, but but the way the ASO AC works, does have ICANN influences on it so we do have a quite strict procedures, quite strict ways of doing it. Like, for example, when we coninclude the meeting, somebody actually tables a motion to end the meeting and then somebody seconds that and then we close the meeting. This is for this crowd it's a little bit different style of working, so ‑‑ but we do try to keep all these procedures very correct and very strict.
ERIK BAIS: We have a question from Flavio. Is it online? Okay, he is gone. And then there is no other questions. Thank you Sander.
(Applause)
ANGELA DALL'ARA: Good morning everybody, nice to see you, and greetings to who is online. Everybody knows me and they know that I am the quality officer in the RIPE NCC and I am here to give you an update about the latest topics that were discussed on the mailing list lately.
Also, in other regional registries. First, it's good to remind that all the policies in our region are discussed and accepted the following policy development process. If you are not familiar with the process, you can find the document on our website, and it's also good to be aware that this process is at the moment under review. Because a couple of years ago we had our first appeal and RIPE Chair team saw the opportunity to review the process, and the version 3 of the proposed draft is also available, and you can provide your feedback before the 27th May, and say what you think about it.
It was probably interesting to know how the participation in the last couple of years with the pandemic went. If you can see that we had a high participation until 2019, and also many policy proposals, especially in the ‑‑ and now we are probably sometime for being always behind a computer, we're in the situation and so on and I am very pleased to say that we can see an increase in participation again in the first months of this year. And also, the opportunity to be here at the meeting for sure is going to increase the amount of comments and exchange of ideas about what has to be discussed.
So, what happens since RIPE 83, especially on the Address Policy mailing list? You can see it ‑‑ most of that, you can see it in this session. So, the Registration Services report highlighted an issue with ‑‑ a possible issue with stockpiling of IPv6 allocations, and from this subject many different discussions started and some of them are still under discussion now, you will have many points in the agenda today. After this there will be the IPv6 policy goals review made by a team that worked out some considerations on validity and the need of reviewing the policies. Then we had a discussion on temporary assignments and you will hear more from Marco later about this. And as Leo said before, we had the RIPE Database Requirements Task Force report with some recommendations, two of them are resulting already in one policy proposal that is already submitted in the Database Working Group. If you are not subscribed to the Database Working Group mailing list, please do, because a policy that is actually affecting everybody that uses the RIPE database and is registering objects there. So, it is possible to comment and to exchange opinions and the discussion phase is going until the 8th June 2022. You can also follow the stages on this link for to follow how the policy proposal is proceeding through the PDP.
Later, you will see also there is a concept policy proposal here in the Address Policy Working Group that is regarding the registration of IPv4 assignments that at the moment is mandatory for all assignments and, let's say, the latest policy for assigning IPv4 allocations is allowing us to distribute only a /24 to each member that didn't receive IPv4 before, so, because of the need of registering assignments is now necessary to register to smaller assignment, a /25, that of course are not always corresponding to reality in assignments that operators do in their networks.
You saw Sander talking about global policies and it is good to remember that every RIR has his own policy development process and has different policies. There is a document on the NRO website that is comparing the main points of the policies, and it is updated every three months. So let's say, it is a good researches for the main topics, but I would suggest you to look into the policy of each RIRs when you want to know the details.
It's interesting also to know that the RIPE NCC has different policies while other RIRs have consolidated manual for all the policies so they are grouped in a single document.
So let's see what happened in other RIRs. We didn't have any policy implemented since RIPE 83 because nothing happened at that level in RIPE. But, in ARIN and in LACNIC, we had two new implementations.
In ARIN, how can I say, they took away, let's say, the especially of special space of IXPs or micro allocations from the calculation of the existing space of each member. So when you apply for the waiting list for IPv4, that space is not calculated any morass held in the account of allocations already held by the member.
In LACNIC, now, the staff is allowed, and has been mandated, to check periodically on the usage of the IP addresses and eventually try to ‑‑ they can try to correct the situation if the address space is not used following the requirements of the consolidated manual.
And also, whenever is available, the origin AS is mentioned in the response of WHOIS queries in the database. These are the only three policies implemented.
And I grouped now the policies under topics, let's say, because also in a sort of chronological order because these are the order of the discussions that we have seen in AFRINIC and LACNIC, they are about a review of the PDP. In LACNIC there are six policies that are modifying different parts they are all, let's say, waiting for a new version.
Curious to know, in LACNIC every version of the policy has to go through the whole process and then can restart the process for the PDP can restart with a new version, so we are in a stage waiting to see if the proposal is preparing a new version or not.
Hot topic always are transfers. We have a policy that reached consensus in AFRINIC, but is under appeal, and it is a policy that also includes inter‑RIR transfers, and actually, it's allowing only legacy space and space received from transfers to be transferred out of AFRINIC. So it is not, let's say, with RIPE is compatible but not reciprocal, and there is also another proposal under discussion that is, instead, opening up the transfer out of region, out of AFRINIC for all resources. Let's see what is going to happen in the discussion.
In ARIN, they just made a clarification about special cases for transfers, and how can I say, the second one is really clarification of the text and the first one is allowing to receive a small allocation in ‑‑ when they wanted to transfer, let's say, larger, how can I say, a larger block. So, let's assume that a member has a large block and he needs only a small part of his allocation, there will be the option to divide the allocation into parts, one is kept and one is transferred, and instead, they can ask a smaller allocation and transfer the whole block so that they prevent a bit of deaggregation. And in LACNIC, they wanted to specify in the manual that when, when a transfer fails, the resources can be kept by the the member, because, let's say, assuming that when you want to transfer the space, you don't need the space any more. You don't need addresses any more. The policy would ask for the return, but instead already, it is implemented that you can keep the space but they want to specify it in the policy.
Then we have another subject is RPKI. AFRINIC are the identified and is awaiting to implement the creation of ROAs for unallocated and unassigned space. This is very similar to a proposal that didn't have success in our region, and is actually allowing the creation by AFRINIC of a TAL that be be optionally downloaded creating ROAs for this space with AS zero as origin. Ours was a SLURM in that region is TAL.
In LACNIC instead, they are looking into giving the possibility for the holders of suballocation and assignments to create their own ROAs, and this is something that we received some questions about also in our regions. So, of course, the discussion is ongoing and we will see what is going to be the decision about it.
And then in, recently, very recently, in ARIN and LACNIC, we see that the issue of leasing issue, or at least the behaviour of leasing resources being under close attention. In ARIN we are two policies: One is ‑‑ they have two opposite directions. One would like to permit the leased space to be included in the needs of the member when they ask for resources. The other one is not ‑‑ wanting not to allow leasing at all. With leasing, the general concept is to see leasing when address space is assigned without providing connectivity. So, there are some discussions especially in LACNIC where there is a similar proposal. When, let's say that the not providing connectivity is one of the factors that can define leasing, but also they are discussing about defining leasing only when there is a commercial agreement or a financial agreement, or if, instead the leasing is also without any commercial or financial agreement behind it.
So it's going to be interesting to see how things are going to look.
And as I said, it is always good to have a look to the websites of the RIRs specifically because the comparative document is not exhaustive, so, these are the proposals and then you can see the stages and see how things are going.
So this is what I have for you today, and if you have questions, I am happy to answer.
ERIK BAIS: Thank you Angela.
(Applause)
ERIK BAIS: It's been a while since we had policies here in the RIPE region, it's always interesting to see the updates from the other regions and what the discussions are there. And it's good to see that they are, you know, improving on their policies as well and have different approaches on what we do here in the RIPE region.
Do we have any questions?
JORDI PALET: The last point that Angela just presented. I am one of the authors of the no leasing proposals. This proposal is being prepared also for APNIC and AFRINIC. The point here is to stress that we are not changing the actual situation. So, both in LACNIC, AFRINIC and APNIC, there is a special text either in the policy or in the RSA that states that leasing is not a loan. So what we are doing is not changing the actual situation but just stressing, or clarifying that because some people, it seems, they forget about that. Just want to make that point. I know your response Angela, I will do as soon as possible.
ANGELA DALL'ARA: Thank you Jordi. Thank you.
ERIK BAIS: Any other questions? Thank you. I believe we have a familiar face back on stage. How does it feel?
Angela DALL'ARA: I am just a random person.
GERT DOERING: Good morning dear Working Group to keep to our established standards.
So I'm not your Working Group Chair any more. I found other people to do the work and that is totally cool. But they, of course, found ways to keep me busy, so, we have the discussion about the IPv6 policy as it is, as it was, why it is the way, which started last meeting.
The new incoming Working Group Chair said we should overhaul all the existing texts because they are old and people have used bad language and all that, and we have to keep ourselves busy.
So, basically the idea was born to look at the existing policy text and look into the 20 year history that went into that. And see why these are in the policy the way they are. And if the reasoning is still valid, so maybe we introduce something because we had a need 15 years ago, and it turns out that since 10 years, nobody has ever need that had so maybe we can take out stuff again.
I did this together with Kurt Kayser and Sander Steffann, they are both here and will come up to the stage later for the discussion. I wrote a three page document and sent that to the list last weekend, like about two months later than I planned to do, but it's all there. And the main points I will try to sort of summarise here.
This presentation is a bit shorter than the document because, well time is short, but I think I covered the most important points.
Let's see!
.
The headline should say the easy bits. And then it says the complicated stuff and the nasty bits. Anyway, that's the easy bits. The underlying idea of the IPv6 policy has always been encourage IPv6 adoption, so make it easy to get IPv6 addresses. Have the policy in a way that it doesn't get in the way of doing IPv6.
Keep aggregation in mind for the routing, which also means be liberal about address block size, so if you do internal aggregation in your network, you cannot be as efficient as if you do really packed address assignment, and the blocks we assign are so big that you can do that.
Conservation is of course still a thing. But it's not like we're going to run out of IPv6 any time soon. So, conservation was never the primary focus of the IPv6 policies. And one of the important bits that we always wanted to achieve is there should not be an incentive for ISPs to force their customers to use that. But not if they want but like IPv4 where the customer has one address and if they want to connect the network they have to use that.
I think these points are all still valid, and we did a good job on that. So we have a fairly liberal allocation policy. ISPs can give their customers whole networks, 56s and 48s, so nobody is forced to use NAT. The policy is liberal enough that people can do proper aggregation and then it works, and still make good use of it. So that was the bit that went well I think.
Same liberal about allocation sizes has of course been more complicated bits that you can't see in the header of the page so. We said address space should be easy to get. Do not be more conservative but at some point, there has to be a boundary because otherwise everybody will go for a /10 and then we will run out of v6 space very soon. But there are, of course, very large networks that have, well large needs.
What we did over time was we started with an allocation size of 35 which was ‑‑ well the early days, 1999, still very conservative. Then it was extended to a 32, some years later extended to a /29, the 29 is sort of a, if you want a 32, you can have a 32 but if you want a 29 you can have a 29, so you just ask for it and you get it, no documentation needed.
And I think this worked out nicely for, say, 99% of all requests, and this is good. It saves time, saves effort, makes people happy, makes the NCC people happy. But then, there is larger allocations and we say there must be documentation. So, even for just one bit more, 29 to 28, you, all of a sudden, have to bring a stack of paperwork and document why your network is so huge that a 29 is not big enough. Which can be a costly thing, so people have been tempted to just open four LIR accounts to get a 27 instead because that's cheaper than getting that sort of documentation. Some people actually went for the documentation to justify a 24, but it has been a lengthy and costly process. So, this is something where the policy is creating a bit of friction. I am convinced that we cannot just open it up because if we say you can have whatever you want, people will get whatever they want and the NCC will run out of v6 space, and that's not good, but maybe we can sort of like make the step a bit ‑‑ the step in requirements a bit less steep. So not from zero to full but like a bit more documentation and the bigger the block gets the more thorough it needs to be.
Just as something that came up looking into this.
HD ratio. This is a thing that you all love. It's ‑‑ you are all engineers and this is mathematics and it is a very nice formula to model the way aggregation works in multiple levels of aggregation and you have loss on every level of aggregation and then you have a mathematical formula that perfectly models this by a scale and nobody understands that. So even the first version of the policy had a table in the packet loss that said, so for usual allocation sizes, this is the person that you actually need to fill because nobody understood HD ratio, but still it was there very prominently in the policy itself while the table is just in the packet loss, and, well, it has been brought up and I agree that this is why MAT mathematically correct, not a way to write an easy to understand policy. So maybe it could be rewritten to put the number, like, 5% for a 29 into the policy text itself, and put the HD ratio and the rationale and all that into an packet loss, or just get rid of it.
Since we basically have one size fits all allocations for most people anyway, this is a bit moot.
Also, there is interesting text in there relating to the measurement unit, the 56s, which is also very scientifically correct but totally not understandable. The document has the quote from there.
So, another area that at least warranted some document work I think is the special policy for pegs networks. When we started with this journey, we had no provider independent space. So, you either are an ISP or a RIPE member, then you get your 29 or 32, or you are not, then you get no space. But it was recognised that a root DNS service operator would need address space tied to the root name service, so not for their network otherwise but really to the root name service. Same for Anycast DNS operators, servicing TLDs or ENUM, whatever that was.
Also, Internet Exchange points of course need address space for their fabric, so not for the web server but for the actual fabric. These are special because they cannot be tied to any of the member space. And if you want to re‑number a root name server, it's a real big thing.
So it made sense to have special policies for them. What did not make so much sense is the information is spread over three different documents. The Anycast DNS stuff is in the main policy. The root name server, they have two different policy documents, one for IPv4, one for IPv6 ‑‑ oh, no, they don't have special v4, they only have special v6 I think. And IXP has two documents for v4 and v6 actually.
So we could either say this goes, because they can use v6 PI today, or we could just combine this into the main IPv6 policy it may be ticking out ENUM in the process because that is really a historic thing as there is no ENUM TLD operators any more, as far as I understand.
One of the big things is basically renumbering IPv6 networks and multihoming which causes effects in all directions. Basically, the question is: If I move my network to a new ISP, what do I do? And if you are basically a small mostly unmanaged network, it mostly works. You just plug your box not other DNS cable and your network gets renumbered and you don't know. Because, these addresses never show up in DNS, they are never manually put anywhere so it doesn't really matter if the addresses change. So that works. If you are an enterprise and your v6 networks show up in VPN conflicts in firewall conflicts in manually configured machines everywhere, renumbering that network is hard. It's possible but the bigger the enterprise gets, the more costly is that.
If you are an ISP, worse of all a data centre ISP running servers for like 5,000 different companies and they all have their IPv6 addresses in DNS zone hosted elsewhere, renumbering this network is just plain impossible. So, we have categories of networks that really, really, can't be renumbered. And, as well, if you want resilience to multiple ISPs, basically the only technology that is available for larger networks today is BGP multihoming and you need your own address block for that with asterisk and lots of discussion attached and so on, but this is the well understood solution today.
So, either you become a local registry and get your 29 from the RIPE NCC, which makes sense for a shop hosting like multiple data centres, but for a small garage ISP, they might not have the money yet. So, you could do IPv6 PI and get your own smaller but independent network.
Of course that's not without consequences and this is actually a bigger discussion, and I'm not bringing answers I am just bringing questions. The question why do we have two different colours of IPv6 addresses? Like we paint one blue and call them provider aggregatable and we paint the other one green and say it's PI space. But it's just numbers. So is that something we want? Is that something we think is good or not? It reflects on why do we have two different classes of NCC customers, so we have LIRs that are direct members, have voting rights, have a contract with the NCC, and we have PI holders which have an indirect contract, paying much less money per year for their PI space, have no voting rights. Is this good? Is this bad?
.
At some point I have heard rumours that the NCC Board doesn't like the construction with the PI space as the indirect contracts because it creates quite a bit of work for them. What I hear from my customers is that they actually like this approach because they like dealing with a German company with just German bank transfers and all that, and leaving all the international dealings with the RIPE NCC to us and we are happy to do that for a small fee of course. So, this is also a bit of tension.
Of course, everybody wants their own space, and they want to keep it forever. Nobody wants to re‑number. Nobody wants to do any work. But on the other hand, everybody who has their own space in the global routing system is eating memory in my routers, so why should I care? Their convenience, my cost, so again, it's a field of tension.
The current model that we have I think was, when we invented it, a good compromise. It said there is a cost to PI so it's not like it's totally free. If you really want it, €50 a year is not much money, but if it's just for vanity reasons, maybe it's too much money, so it's a bit of discouragement and there is a yearly fee and this is hassles attached to it, which I think does the job. But, this is certainly something we should revisit every now and then.
So, this says aggregation on the top. And this is actually also a complicated topic. The existing policy text recommends that when announcing your blocks to the Internet you should aggregate wherever possible, because it's good for the common everything and you really, really should do so. The policy we have enables address holders to do so because the address block is to big that usually you never need a second block. So everything you have can be in one block. That block can be nicely aggregated, externally and internally, so if you want you can. But there is no big stick. Like if somebody says, yeah, it's just a recommendation, but I have plans and for my plans I really need to traffic engineer by announcing every single 48 out of my address space, that's like many thousand routes extra in the global table, and nothing in the text says this is forbidden. And nothing anywhere says the routing police will come and cut your cables if you do that because there is no routing police.
So even if you have a company that has some people in the company that really understand the global routing needs aggregation, and you have ten others that say yeah, but it would be much more convenient to do a serious number of deaggregated routes it's hard for the people to actually point to a document that says but yeah, there is consensus that we really shouldn't do this. Because there is no, like, clear guidance document. We have nothing that says up to ten prefixes is fine, more than 20 is considered routing violation. I think having some guidance here would be good. Of course, it's not Address Policy. It's routing policy. I tried to bring this to the Routing Working Group some two years ago. They said yeah, but your policy says you should aggregate, so we have nothing to do, it's all in the policy already. And they were not interested. So, I found a new group to do the work, and that's BCOP. There is the Working Group Chair of BCOP and he has been told that something is coming. The task force Working Group Chair, whatever. So, I think actually having a BCOP document that says if you want to do this, do this. If you do that, it has consequences for everybody else, so, really don't do this would be a good way out of this. And...
SPEAKER: Good morning, John Zorz, 6connect and the BCOP task force co‑chair. Gert, congratulations you just won the speaking slot at the next BCOP meeting.
GERT DOERING: Should I pretend to be surprised?
ERIK BAIS: You should have known better Gert.
GERT DOERING: So that's basically it. The document has a bit more text like talking about transfers, which I forgot actually, but I don't have more time anyway. We have some five or six minutes before coffee break to give a quick round of feedback, and then of course, we discuss this on the list.
ERIK BAIS: Before ‑‑
GERT DOERING: Sander you need to come here because you are actually standing here and answering the questions.
ERIK BAIS: Before we go to the mic, on the documentation, thank you for presenting this here today, there is tension between availability or be available to get v6 and aggregation and conservatives. There has been some discussions already about the, being able to obtain PI space, about not being to to, you know, use it for third parties. We have been doing that some tweaks and changes in the last couple of years, a couple of years ago, to be able to get more clarity in the policy. We definitely need to have a good conversation what is going to be the most pressing issue on v6, is it going to be able to be easy to get? Aggregation, you are not allowed to do that. So ‑‑ and I would like to see if we can get that in the policy reflected as well where the most pressing things are on top and then gradually go back from there. Thanks for this already.
KURT KAYSER: I wanted also to suggest that we should prioritise this list because this is quite a lot of topics and we discussed a lot of other things too like ASN policy which is also quite open. We have nothing defined who limits the requests numbers on ASNs which are directly related also to block sizes and table effects. So these things could be alone discussed with these topics we had which we had alone round it the other topics backup that's the most condensed versions we have now for the Working Group.
ERIK BAIS: This can ‑‑ you can offer it here pretty quickly as soon as you start talking on the topics especially if you have a couple of people in the room that actually know about it. So, I agree, you know, we need to have some understanding what's going to be the index basically for the policy, because once that's clear, then it's full speed ahead and then it's the words that actually need to come on those topics.
GERT DOERING: So yes, definitely the next step needs to be agreement on a specific problem statement before going into policy texting.
ERIK BAIS: Yeah.
KURT KAYSER: One more comment to the routing deaggregation. The key word which comes to mind is call a deaggregation factor. I am following this number quite along the last years because RIRs are publishing some of these numbers with Geoff's and Phil Smith routing excerpt every week, and the numbers are typically for an average between 2.4 and 4.6 for AFRINIC, which are quite low numbers still, but if we see that there are more deaggregated blocks appearing, I think this issue really becomes more pressing that we should do something in the policy to do something about it or give clear guidance what is possible and whatnot with more specifics. I mean some do it for security incidents or reasons which might help or not. Others are doing it for multihoming and there are lots of reasons to do T but does it really help and, as you said, rerouting entries is costs for everyone.
GERT DOERING: We have a long microphone queue so no more about aggregation.
SPEAKER: Good morning everyone. Raymond Jetten, speaking as a working group Chair for the IPv6 Working Group Chair.
First of all, thanks to you for making this work and in the v6 group we don't have time for dealing with this so I'll put it on the list and make sure we can try to get some feedback on this. Then as a Board member, you mentioned that the RIPE Board does not like PI space. Just to make sure that everyone understands, the Board doesn't have an opinion about this in general, it's more like we have to make sure that we don't overload the RIPE NCC staff, and that is the reason we probably don't like it. So thank you for all this work and I hope we can have a long and a lot of discussions on this. Thanks.
SPEAKER: Just in regards to the queue, so after Rob, we have two put up their hand and then the remaining two after Rob. We have got ‑‑
ERIK BAIS: We have two questions online. Can we take first question online?
SPEAKER: In regards to sequence, the first two guys up after Rob, we have ‑‑
ERIK BAIS: Sander first, Rob first and two online.
SANDER STEFFANN: Speaking as a community member, I think this routing BCOP thing is long overdue, so it's really good to work on that. And since you have just been volunteered, I would like to remind you that you could delegate this to other members of the task force.
ERIK BAIS: So Sander is helping out on that I see. Excellent. Rob.
SPEAKER: Rob Evans. Just a couple of quick points. I will make them quick. First of all, RIPE 399 does exist which is the RIPE Working Group recommendations on use allocation so really it's time to update that but there is a document recommending route aggregation.
GERT DOERING: Thanks for reminding me. I forget about that one. It's old. It needs looking at.
SPEAKER: Secondly, you have talked quite a bit about the bits to the left of 32 and to the right of 48. I have got a bit of a problem with the bits in the middle, because I am like a lot of ISPs that have a lot of small customers, we tend to have fewer large customers. We have large universal campus, and we have a steady stream of requests coming from our customers for more than a /48. It's often easier to just become an LIR but they actually prefer to go through us and we have to justification for more than a 48 more than a bit onerous in the past t would be useful for us if we could find and easier way to justify more than a 48 where there is just due to say a hierarchy within a multi‑campus university.
SANDER STEFFANN: So, in that case, because the policy says a /48 per site, would a more liberal interpretation of site be any help?
ROB EVANS: It ‑‑
GERT DOERING: I don't think that would actually make sense.
SANDER STEFFANN: If it's a multi‑campus ‑‑
GERT DOERING: I fully understand what this ‑‑ yeah, usually it's easier fits like all of your business and you can just do business units with like 40s, but if it's not a BIS unit but actually a separate entity, I think the policy says go and ask the NCC hostmasters, which is ‑‑
ROB EVANS: That's where there's been a bit of a ‑‑
GERT DOERING: That actually is something ‑‑ thank you. I had totally did not have that on the radar but this is something that we look into.
SPEAKER: Maximilian ‑‑ speaking as a former IPv6 holder. I heard quite frequently that some people complain that they got, that it's much easier to get multiple /8 PIs more than one allocations that may be aggregated in the future if an end user decides to get transport between sites, so handing out multiple /48s and it's for multiple State instead of handing out for example a /47 or /46 might prevent future aggregation, is there any ‑‑ do you have any comments on this?
KURT KAYSER: It's an idea we connote that there is demand for it, yeah.
GERT DOERING: I have heard that brought up before. I have never actually picked up the idea and went to work on this, because in the cases that were brought to me, I always thought you could just use provider aggregatable space. I don't care about your vanity space. In these specific cases, so I was not maybe the most enthusiastic person about this. But, yeah, it's actually good to bring this up. We might look into it.
KURT KAYSER: Is it just we compare numbers. What would be the affect if we could just see what demand is out there like the HD ratio we talked with Angela about the last ten years about how many HD ratio requests were filed in the RIPE. Then it came up why we keep it complicated. The same thing about numbers, then we could discuss it.
GERT DOERING: I think we have so much space we could actually easily afford going to ‑‑
KURT KAYSER: Just note it, put it on the list.
ERIK BAIS: So I have a question on that. Requesting the space to set up a 48 to a 47 or a 46, but if it's multiple sites, is it also going to be deaggregated and routed separately? That would actually defeat the purpose.
SPEAKER: It might be routed separately in the beginning when there isn't that much infrastructure, but might be aggregated later and after all, it's the same amount of space you are handing out, so, handing it out in one plot could open the door to aggregate it later with the same /48 per site requirement it might make sense to just hand it out as one block to allow organisations to aggregate it later once they have the infrastructure to actually do it. And as we discussed earlier, renumbering is hard, so handing out 47 instead of two /48 might not bring an immediate effect bus it's beneficial in the long run.
GERT DOERING: What I have heard is like you have five sites and you can easily get five 48s, but to have an aggregatable block would be eight 48s then and you cannot justify these three because you have no sites and you have no policy that says you can just round it up. In the large number ‑‑ in the amount of v6 space we have going for a 45 would not make an dent anywhere. But it's not allowed by policy.
KURT KAYSER: This is what we suggest that we put in the obligation to keep it aggregated together with the request. I mean if they plan later to have their networks connected and everything, if we hand out a big block it should stay in the table just as a single entry, because then it's part of the policy.
ERIK BAIS: It's definitely interesting to look into this.
KURT KAYSER: It's like address demand and the other is like routing obligation.
SPEAKER: Thank you.
ERIK BAIS: Do we still have someone online?
SPEAKER: Jan Zorz, 6connect. A change of topic, not aggregation. Because I see you are going through a lot of all other stuff that you want to change.
GERT DOERING: Where do you want to go?
KURT KAYSER: We want to change with the topics these are topics you should discuss.
JAN ZORZ: What I get more and more is people apply for IPv6 IP space because they have one or two racks rented in one data centre somewhere and they are multihomed and they are used to explain things, they want to get addresses they use to explain things from IPv4, and then they go and explain things how their system is running and then they mention oh, and we also have this neighbours server and our BIS partner's server in our rack, and they get denied by the RIPE NCC because you must be running just your services in your hardware if you want to have a PI space. And then with a bleeding heart I tell them well lie. And lying in IPv6 should not be a default, and I need ‑‑ I think we need to change and make it easy for people to get the IPv6 and deploy it because then they send an e‑mail to me and they complain to me. They come crying like a baby we were denied by the RIPE NCC, you are telling us implement IPv6 and then the RIPE NCC is not giving us space. What should we do? And then I tell them okay, just don't mention it and, you know, you will get it, but most of them say I will not deploy IPv6. I am done.
SANDER STEFFANN: So, at some point in the past, I have suggested looking at the text and saying you cannot host like a server in there, but actually look at who is managing the network, if it's your network, you are running the /64, then it doesn't really matter what's inside the /64. So, maybe we should go back to that idea and focus more on the network than on the servers inside the network. Are
JAN ZORZ: Exactly because there needs to be some grey space. It's not black and white.
GERT DOERING: I seem to remember why we have this and this actually goes back to the first slide. This one, about the N: 1 NAT. What we definitely did not want. Back then when we introduced PI, there was the worry because it's cheap, ISPs would just get the cheap PI block, not become a RIPE member, and give a single address to each of their customers, forcing them to do NAT. And this is what we definitely did not want, and we succeeded in not getting there, but they had had the side effect to actually kill garage ISPs, which ‑‑
SANDER STEFFANN: Maybe make a distinction between hosts and routers, say, on your network, you can run whatever hosts you want, but on PI, it has to be your routers, because then ‑‑ you know ‑‑ because the function of a router is ‑‑
GERT DOERING: We may just band on this part.
SANDER STEFFANN: Also true.
GERT DOERING: Back then we had very little, very few ISPs that actually offered v6 and we had no good models. Now we have sufficient access ISPs that give you a 56, so if somebody starts an ISP and say you can only have a single IP address, there is not even routers that can do the NAT. So, the market will, I think, make sure that this is not happening. So maybe we can just get rid of the third‑party clause.
ERIK BAIS: Excellent. We need to cut the time.
MIRJAM KUHNE: I do enjoy this discussion, I think it's really good to have and all I want to say is actually thank you and the Working Group to bring this up and all the good work you put in analysing this. I think it's about time we reviewed the policy. It's obviously a huge task and I also appreciate that you put in other Working Groups and BCOP for instance, IPv6 routing, I think we need to do this together but it's a great work you have already done, so thank you.
ERIK BAIS: Thanks for the presentation. Please do comment on on the mailing list and let's keep this discussion going on. Thank you, guys.
(Applause)
ERIK BAIS: Now, I believe it's time for coffee, and we see you, Leo what time do we need to come back?
LEO VEGODA: Half past.
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
