9 a.m.
Address Policy Working Group
24 October 2017
GERT DÖRING: Good morning dear Working Group. So, not counting, how many people are in the room? I cannot see anything because of these bright lights anyway so I assume the room to full of enthusiastic policy making people. Thank you all for being here.
I'm not sure if we need an introduction but as a matter of politeness, I obviously do. This is my co‑chair Sander Steffann, I am your Working Group Chair, Gert Döring. This is the Address Policy Working Group if you are interested in measurement, MIT is over there, but looking at your faces I know that you are the policy folks and not the measurement folks.
So this is what we do today. First block is well the usual stuff, administrative matters, current policy topic overview from Marco, feedback from NCC RSS from Andrea and a small update on the outdated policy references, work item we had on the agenda last meeting which didn't proceed anywhere due to well my laziness, more on that later on. Then we have actually exactly one policy proposal left to discuss, and that's the IPv6 PI tweaking from Max. The other two got withdrawn. We have Open Policy hour in case something new wants to be discussed, and then we have an AOB about Working Group Chairs rotation.
Agenda bashing. Anything we need to change, anything that's missing, anything you want to be discussed? No, so that's what we stick to.
Minutes. The NCC has, as always, done a wonderful job writing very, very detailed minutes, thanks a lot for that. These minutes have been sent to the mailing list in August. No comment on the list, so I assume that everything is totally accurate, or they were so long that nobody ever reads them. But I actually read them and they are impressively detailed and accurate. Any comments on the minutes? No, so, I declare the minutes final.
And we are in the first presentation from Marco Schmidt, policy development officer at the NCC, and the one who makes sure that we don't miss on all the details, the fine print and so on. Marco, thank you.
MARCO SCHMIDT: Hello, good morning everyone, also a warm welcome from me to all the early birds that make it ear after yesterday's social, and I guess we have a lot of remote participants today. As Gert just said I am the policy development officer for the RIPE NCC, and I would like to give you the usual update what's going on in the policy world in our region and globally.
As I just said, I will ‑‑ that's what I would like to present to you. First a bit some overview, which policy proposals are under discussion in the other four regions. Then a very brief summary of policy discussions that took place since the last RIPE meeting, and then I will close with a few numbers regarding policy topics.
But first, like usually, let's have a look at what's going on in the other four regions and I will start with our colleagues from Africa, AFRINIC. And I have grouped those policy proposes a little bit by topic. And first topic there is transfers. And you see here there is the pour resource transfers within the AFRINIC region. This one has reached consensus since quite a while, it's ratified by the board and just waiting for implementation. And I have heard that implementation will be finished in the next few weekends and this happens it will mean that all the five RIRs which have IPv4 transfer policies within their service region.
Another proposal in regard to transfer is Inbound Transfer Policy, this was inter‑RIR policy that would allow IPv4 transfers into AFRINIC region only, so a one way transfer policy. But it never received enough support during AFRINIC meetings, during the policy meeting there, and it has been withdrawn by the proposer.
Proposals that will be discussed at the upcoming AFRINIC meeting in a few weeks are regarding soft landing, so how to run out slowly of IPv4. And the first one on the list, IPv4 soft landing BIS was actually one that wants to make the soft landing a bit more strict. It would limit the amount of requests that a member can send to AFRINIC to one request every 24 months.
The second proposal, the route aggregation policy, goes a bit in a different direction. Because under the current AFRINIC soft landing policy, there is no limitation how many requests a member can send even at the same time, so, this proposal suggests that if somebody sends multiple requests parallel or after each other and they get all approved that he would get one aggregated block for all those requests together.
And for more proposals that will be discussed in a few weeks. The first one is the Internet number resource review by AFRINIC, this is something under discussion for quite a while. It basically wants to give a mandate to AFRINIC to check if the resources they have handed out are in use and eventually even reclaim unused resources. It was always quite some controversy about it because the question was how to implement it, how AFRINIC can actually find out how much an Internet resource is in use.
Talk about can't version, we have also still the anti shutdown policy under discussion in AFRINIC region, just to quick recall to do the ones of you that might not know. This proposal suggests actually that AFRINIC can stop providing Internet resources to governments and even eventually deregister government resources that have been given to governments in case they limit Internet access to their citizens. And as you can imagine, that was rather controversial and of course there was quite some discussion and I expect this will happen again soon at the AFRINIC meeting.
And two more proposals. One wants to get rid of lame delegations that are in the AFRINIC database, and another proposal actually wants to define a new policy development process to take some new elements in and, for example, there is a one to take some ideas from our PDP that policy proposal would go through three different phases, for example.
Moving onto the next region, APNIC. There was quite some topics about IPv4, quite some proposals there. The first one on the list is right now in last call. This one actually would prohibit transfers of IPv4 addresses from the final /8 block. To explain a little bit. APNIC had quite now deals with two IPv4 pools. One is the actual last /8 that they got, 103 /8 and another pool for all the other address space that they have received since then, returned address space and so on. And this proposal actually has reached consensus at the APNIC meeting that if you got an address block from the first pool, the final /8 pool, then cannot transfer this for five years, even not as part of a merger and acquisition. And while it has, as I mentioned, reached consensus and is now in last call, there were now quite some voices an the mailing list that were opposing that proposal and the people were saying I was not aware about it, and I didn't know about it and this would impact our business. So it might be that proposal has to be revisited.
Three other proposals regarding IPv4. There is still a no need policy in the APNIC region under discussion, which basically would remove all need evaluation for transfers.
Another proposal wants to allow the possibility of temporary transfers.
And the last one here on this final /8 pool exhaustion plan, this one wants to find the best solution, what happens if the first IPv4 pool runs out and only the second IPv4 pool is left, how to deal with that situation.
Two proposals that have reached consensus at the APNIC meeting were related to IPv6 and the updated subsequent in the initial IPv6 allocation policy, and if you would look at them, the text would sound very familiar to you because it was taking over the same requirements that we have in our policy, that criteria such as geographical segmentation or security requirements can be taking into account when requesting larger IPv6 blocks.
That's for APNIC. Next one on our list it ARIN. They have quite some proposals, or had, about make transfers more easy. The first two on the list have been already adopted and they basically take away some justification requirements or simplify requirements to make it more easy to allow transfers of small blocks, also if it's something related to acquisitions and mergers.
And one proposal that has not been reached consensus yet is about to remove the reciprocity requirement for inter‑RIR transfers. That's actually quite interesting. Because ARIN policy requires, in order to make a transfer with another region, that the other policy in the other region is fully compatible with them so everything must kind of match. And you just saw for AFRINIC, there was a proposal that only would have allowed transfers in one direction to AFRINIC. And according to ARIN, that would not be fully matching. And the same will be for LACNIC. And this proposal actually tried to tackle that problem and tried to find a way that there still would be transfers possible to those regions with a one way transfer policy.
IPv6. Something has reached consensus at the last ARIN meeting to make it a bit more easy, or more clear what you need to register in the ARIN database, that until now you need to register every assignment bigger than a /64. In the ARIN database, which is quite a lot of work as you can imagine, and once this proposal is implemented you only need to register blocks of /47 or bigger.
Two other proposals still under discussion at the ARIN community is to find a new definition for community networks, which is (still) a special type of networks Tor local communities that want to equate their own Internet access without involving a commercial broadband provider.
The last one here is the POC validation, POC is point of contact, so in the ARIN database and this proposal is a bit similar like one that is currently discussed in the anti abuse Working Group that ARIN would regularly validate those connecting information and mark the ones that are not responsive and mark them as invalid.
This brings me to the last of the four other regions, LACNIC, last but not least. They also just had the LACNIC meeting a few weeks ago. And only proposal that did not reach consensus is the one way inter‑regional transfer policies, which would allow transfers from other regions to LACNIC, but there is not enough support at this stage in the LACNIC region so it went back to the mailing list.
Two proposals that have reached consensus were related to IPv6. Both actually want to make it more easy to justify larger sizes. The first one, IPv6 allocations to end users, that's something similar like our IPv6 PI assignments, so, this one allows to make it more easy to give something bigger than a /48 to such end users.
And the second one, very similar to our policy again, very similar to what has been accepted in the APNIC region, because it was done by the same proposer, to extend the requirements for which you can qualify a larger IPv6 allocation.
Something that also reached consensus is a modification to the LACNIC resource recovery process. LACNIC is one region that has already right now a policy that allows them actively to look which resources are not announced to the Internet any more, and actually try to contact the resource holder to find out what's going on and even eventually deregister the resources if they are not used any more. And this proposal would make this process a bit more strict because it gives the right to LACNIC to even doing that contacting process, to take away the reverse delegation of that resource to get the attention of the resource holder in cases not responding before to LACNIC.
And the last one that has reached consensus is an adjustment to the LACNIC policy development process. Right now, consensus in LACNIC is found at the LACNIC meeting, and then the proposal stays for 45 days at the mailing list for last call. It was considered that's a bit long time, and now with this proposal, it will be reduced to 30 days.
This was the global overview. I will now talk very briefly about what has happened in our region since RIPE 74 in Budapest, and we have right now two open proposals in the RIPE community. And the first one, 2017‑02, the regular Abuse‑C validation will not be discussed at the Address Policy Working Group because it's something about anti‑abuse and that's why it will be used in the anti‑abuse Working Group tomorrow at 11 in the side room on the left‑hand side. And what is this proposal about?
It's right now mandatory in the RIPE database database that resource holders must have, or must enter an e‑mail that you can contact if you want to report any abuse. But it has been observed that quite often those contact information gets out of date and this proposal actually suggests that the RIPE NCC would regularly contact the resource holders, and try to find out if this e‑mail is still working or not. But, again, that's not something to be discussed here, that will be tomorrow in the anti‑abuse Working Group.
A proposal that will be discussed here just short after this presentation, is the 2016‑04, the IPv6 sub‑assignment clarification, so I don't need to say much more at this stage.
And I just want to mention that two proposals have been withdrawn since the last RIPE meeting. The first one is the 2017‑01, to publish the statistics on legacy updates. And the second one, the 2017‑03 to reduce the initial IPv4 allocation side. It was withdrawn yesterday. It was published about a month ago, it has caused quite some discussion on the mailing list and it also I was told caused quite some panic by people that thought that this allocation side to a 24 would even be decided at this meeting and so on, but there was quite some different reasons why people objected to that proposal and that's why the proposers decided that there is no way a second hearing and address those objections.
I want to close my presentation with a few numbers. In this year so far about the four policy proposals that I have mentioned we have seen about 500 posts and to respond to a request from Peter Koch actually I had looked at those responses, the vast majority are really ex incentive responses where somebody explains where (extensive) opposes or supports the proposal, so not many or even not at all plus 1s and minus 1s. And those posts came from more than 80 participants from 25 countries, which is nice because it ensures that more people from different backgrounds, from different regions, from different environment give their input to policy proposals. But it always can be better, and actually, I would like to address especially the local community, the regional ash I can community to really get engaged more in policy discussions (ash antibiotic) because these policies are made by you and you made them and so far, we have actually not much participation from this region and it would be really nice if this changes because you are all impacted by this.
(Arabic) and I will close my presentation with a few useful links on the current public ‑‑ so the ongoing policy proposal discussions available on that link that you can also download on my presentation. As well, the maps where you can see from which countries, how many people participate. If you don't want to be subscribed to too many mailing list, if you are new to this Address Policy, there is also a web based interface, where you can browse through the discussions of not just this Working Group but all the other RIPE database Working Groups, you can do that on that link and if all this was a bit too fast and too much for you, you are always welcome to follow me on Twitter and there you can be sure that you won't miss any update about policy developments in our region and beyond.
That's it. I am happy to take any questions
GERT DÖRING: Thanks for the overview. So we all know what's going on now. Any questions?
(Applause)
Well, actually, getting up here wasn't that much of a useful inter size because I am just here to introduce Andrea from the RIPE NCC registration service, who is sort of the victim of all our policies. So if we make policy that's not working, it makes work for him, and so we agreed a couple of years ago that the RS team would bring back issues of friction or things they see in the day‑to‑day operation and I am still convinced this was a very useful exercise to thank you again for doing this and the mike is yours.
ANDREA CIMA: Thank you. Good morning everyone. I am part of the registration services team at the RIPE NCC.
And as Gert just mentioned, the goal of this update is to report back to you, is to report back to you the feedback that we receive during the operations from local Internet registries that the difficulties they are having with existing policies, but also we want to height potential problem areas that we see in existing policies.
We will ask you for some guidance and we want to provide input for you as a community to discuss.
Now, what are the agenda points for today? First of all I will give you a brief update about the cleanup of allocated PI and allocated unspecified project, which will lead me to some outdated researches in the existing policy documents. We will discuss the up take of 32‑bit ASN assignments, and you know, how you want us to deal with that.
And we will furthermore discuss the term "Organisation" in IPv6 policy, what it means.
And finally, we will discuss assignments made to IXPs.
Starting with the allocated PI unspecified project, this is something that we brought up to you at RIPE 71, so we're talking about a couple of years ago. We brought up that there were 93 allocations which had a status either allocated PI or allocated unspecified which was both in contrast with existing policies, mean there shouldn't be any PI assignments made any more, but also, this status was really unclear and confusing for holders of those resources. What does it mean to have an IP range with status not set? What does it mean to have an IP range with status assigned PI by while there is a holder above you that is maintaining the less specific block.
So, during RIPE 72 you gave us the mandate to go to talk to those people, try to sort it out and to clean this out in order to have a more accurate registry.
The current status is that 58 of those 93 blocks have been converted to allocated parks. So a lot of cleanup has been done by the LIRs holding this space and I want to thank them for this. 20 hundred PI assignments converted. 000 not set. 200 assignments have been deleted and 10 hundred assignments still ongoing.
Now, this brings me to outdated text references ‑‑
GERT DÖRING: If I may inject a question here. Could you go back two slides. You say 2,000500 PI assignments have within concerted to PA. Do you have numbers, how many PI assignments have become sort of regular PI with a Proxy‑Arp contracts in place so they are normal PI now? Because that's sort of missing here.
ANDREA CIMA: I don't no this out of my head, but we're talking at least in the hundreds, but it's something that I would have to look up.
GERT DÖRING: So the vast majority actually has a contract that says this is not PI but it's PA. Similar that is correct
GERT DÖRING: Good to know.
ANDREA CIMA: So, this brings me to some outdated references in existing policies. Because, like I mentioned before, these objects have statuses. We were cleaning up allocated PI blocks, but also blocks with status not set. Now, by cleaning up those blocks by removing them, we got to a point where those statuses are referenced in the IPv4 calculation and assignment document, but they are actually not in use any more in reality. So we have policy and what is in RIPE database not being in sync any more.
As well the status early registration is not in use any more for a couple of years. Early registration status was given to all the objects which were transferred in the early registration project, meaning the legacy address space which was transferred from ARIN to the RIPE database. The status legacy, is not described in the policy, but is actually news, and is a status that we have given a few years ago during the implementation of the legacy policy to all objects which were ‑‑ to all assignments, to all resources that were issued outside of the registry system.
And this refers to IP addresses but also to AS numbers.
So, our recommendation is to remove the following statuses from the policy document: Allocated PI. Not set and early registration and to add a definition for legacy. And this is a potential definition that could be added to the policy which is the definition, which is actually taken from the legacy policy itself.
32‑bit ASN up take. Now, as you can see from this graph, I am happy to have at least one graph in these slides and not only text. As you can see from this graph, the green parts of the bars are 32‑bit AS numbers that are being assigned by the RIPE NCC, and the blue part of the bars are the 16‑bit. Now you can see that since 2009, the 32‑bit ASNs have actually taken up, we are assigning more and more of them. At the moment it's 69%, let's say almost 70% of all AS numbers assigned are 32‑bit ones. We can say you know this is pretty good, it looks good. But then if we look at what happened in 2017 in the other regions, you know, it makes me think. Because we see that in AFRINIC, APNIC, and the LACNIC regions, more than 95% of all the AS numbers being assigned is a 32‑bit one, while we are, let's say, stuck at the stable 70% over the last few years. So, what does this ‑‑ where does this come from?
If we look at the current ASN policy it is quite clear, it says that since 2010, we must not differentiate between 16 and 32‑bit AS numbers, and we must have one unique pool.
Now that's kind of what we do, because we issue by default a 32‑bit AS number, but we still leave an option for organisation to say choose a 16‑bit one in case they want it. As you can see here in the portal you just have to check my customer does not, or my equipment does not support 32‑bit AS number, you put any reason in there and usually the reason is the same. My equipment doesn't support it. And then we give you a 16‑bit AS number. No questions asked. So, where do we want to take it from here? Is there a concern about 32‑bit ASN adoption, are you fine with how things are going now or should we do something to increase the adoption of 32‑bit AS numbers like is happening in other regions?
When asking the other RIRs like why, you know, how is it possible that they have such a Rye rate of 32‑bit ASN being assigned, and they explain to me that they ask for justification, you can still ask for a 16‑bit, but you have to come with a proper technical explanation of why you need it, and then they will evaluate it on a case by case situation.
So, do you want us to go that route or should we leave things as they are? Just for your information, we still have at the current rate, we still have 16‑bit AS numbers for the coming three years, 36 months.
So, then this brings me to the use of the term organisation in IPv6 policy. This is the policy text about the initial allocation of IPv6. What should you do in order to be able to receive first allocation.
Now the policy text says in order to qualify for initial allocation of IPv6, an organisation must be an LIR.
So, this text was created a long time ago. It was made for a global policy and also the terminology had to be able to applicable in every RIR region. It also comes from a time where terms like "Organisation," "Members," "LIRs" were used inter exchangeably. There used to be one member, one LIR, so it didn't really matter what kind of word you were using. Nowadays the situation is quite different, one member organisation can have multiple LIRs, so, one RIPE NCC member, multiple LIRs. We have seen an increase in this, we have seen an increase in members that have multiple LIRs and what we have also seen is that for each of those LIRs, an IPv6 allocation is being requested.
So, to take an example, for about members that have IPv6, we see that there was 450 RIPE NCC members that have 670 LIRs, which have 800 IPv6 allocations. So, it means that for each of those LIRs, there is at least one IPv6 allocation, if not more.
We saw an increase in this, we saw an increase in requests for IPv6 allocations and we started asking like why do you need it, you already have an IPv6 allocation, it's not visible in the routing tables, are you using it?
Since you started asking questions, many people stopped coming back, so, it means that maybe they didn't really know why they were asking for it. But we also got some answers back and some people were saying oh I asked it by mistake, I thought I had to in order to receive my IPv4 address space, some people say just because I can, why shouldn't I? Others say hey I don't want to have to justify a very large allocation, which is more difficult so I just ask for many small ones. And we even got the answer like, you know, IPv4 is really valuable nowadays, maybe IPv6 will be as well in the future, let me stock up now while I can. This was the most interesting one.
So, as aggregation is very important in IPv6, we should also look like okay, where do we want to go from here. Now, either we can interpret or change the word in the policy from "Organisation" to "LIR." This would have some advantages, there would be policy alignment between IPv4 and IPv6. Things would be very straightforward, very clear, one LIR, one IPv6 allocation.
Disadvantages: Organisations can't receive a lot of IPv6 address space without actually having to justify it (can) or we could change the word "Organisation" in the policy to "Member." It would mean that organisations that want more IPv6 address space will have to justify the larger request. It will avoid waste and it also has some advantages because then you keep difference in the policy between IPv4 and IPv6, those two will be, will remain different.
So, where do we want to go from here?
Then my final point is for IPv4 IXP assignments. There is a slash 16 reserved out of the last /8 which is reserved only for IXPs. IP space that is also being returned by IXPs will also go into this pool. We made 96 assignments out of it, there was still 160 /24 blocks left so there is still quite a bit of space, now why is this /16 set aside? It's set aside for IXP peering lance, now the policy is quite clear, it says that (LANs (in this address space will be used to run an IXP peer LAN, other users are forbidden. I have to say the policy is very clear in its wording. Our interpretation is at the RIPE NCC peering LAN only, you know, visibility in the global routing table should not be needed, so, when we see that IXPs are routing this address space we contact them and we inform them that they are not allowed to use it for any other services. I think this is also good because it avoids the risks of the policy being abused, of people asking IXP space, while actually not need it go for their IXP peering line
Most people usually stop announcing the space, they say yeah we did it by mistake or we had a couple of servers we wanted to run on it, so we understand the policy and stopped doing so. The question though is that is our interpretation the right one? Is it correct? Is that what you want us to interpret it? You know, there are people that want to announce the IXP peering LAN address space in order for problem diagnose, it's the same for running out service peering LAN. What about web servers for the IXP website? Or what about the office network that you need in order to run the IXP? So, where do we draw the line and do you want us to be quite very firm about this, or do you want us to be a bit more lenient, so how do you want us to interpret this?
And I think that was it from me
GERT DÖRING: Thank you for bringing up these. I would suggest, since we have plenty of time to walk through the questions one by one, so if you go back to the first one, I think that's about the status values, and then we get a quick round of feedback from the room for each, and then decide whether and how to move forward. Okay, here we go.
AUDIENCE SPEAKER: Jordi Palete. I would like to ask something about the LIR organisation I think, so maybe ‑‑ or you want to follow the order
GERT DÖRING: Let's just focus on this point. Any comment on that particular bit?
So, since I have seen that material yesterday I already had a chance to make up my mind on this or form some thoughts, my suggestion is that we actually send a proposed textual change to the mailing list and then see what happens, combined with the other cleanup. So, as this is not changing policy, this is really just fixing the glossary in the policy where the glossary ‑‑ well, Petter, please.
AUDIENCE SPEAKER: Peter Koch. Good morning, I am making my usually remark at this point of the review, is like, the document is getting a new time stamp, so it might be advisable to look at other things that might be outdated rather than only these definitions, and I think that the old definitions wouldn't hurt, but sneaking in the new one is probably a good thing to do, but... please have a look at the, like, references and everything else there, otherwise it's confusing. Thank you
GERT DÖRING: That was the plan. We have these out dated references work items still sitting on my detection, which nicely goes along with outdated gloss RIS. That was the idea. Come up with a specific proposed textual change, send that to the list and sort of see whether everybody agrees on it or ‑‑ well what comes back.
AUDIENCE SPEAKER: My name is doing done a fury, I would like to give some feedback, and I agree that some misunderstanding have taken place in current RIPE documents like LIR organisation, so these issues should be fixed
GERT DÖRING: Focus on this please. The other one will be discussed but we do one by one.
AUDIENCE SPEAKER: Okay
GERT DÖRING: So right now only on the this. Okay, then we move forward with this, go to the next one.
So, 16‑bit AS numbers. The usual problem we had here was community settings and that cannot do full featured BGP with 32‑bit AS numbers because of the large communities, thanks to a few people doing really hard work at IETF. We have a proper standard for large community values with 32‑bit AS numbers now, thank you you know who you are. But implementations are not fully there yet obviously. So, I can see reasons why at least transit providers are still asking for 16‑bit numbers.
Personally I don't think it's a big problem, but let's hear what you have to say.
AUDIENCE SPEAKER: May I say I usually have some ‑‑ I usually have problems with RIPE NCC stuff about requests for allocations 16‑bit ASNs because time to time RIPE just requires something they don't understand, like the version of software of the router and we send them the version of the router software and they don't understand the text we send them. So it's usually become more and more complicated and more and more difficult an we just don't understand why that it should take so much time to explain to the RIPE staff why and what for we need 16‑bit ASN
GERT DÖRING: Well the point is that 16‑bit ASN are running out, so the Working Group gave the mandate to the NCC to give out 32‑bit by default and only if the need is justified, give out 16‑bit numbers.
AUDIENCE SPEAKER: How much ‑‑
GERT DÖRING: It's okay that they are asking and it's okay if they are asking twice, if it's not clear.
AUDIENCE SPEAKER: They should ask something they understand. If they ask for software version of the router, they should understand what we send them, what we just phrase that they don't understand the software version of the Cisco routers.
ANDREA CIMA: If I may say, we do indeed, as I showed in the form before, ask the question of why for 16‑bit ASN is issued. As far as I know we have never rejected a request for a 16‑bit ASN, so if it's asked, we will issue it. The questions that we ask is, also to collect information to see what are the issues that organisations are having, and indeed, it may be that specific cases we don't fully understand what it is that the issue is and in some cases indeed it very so technical that we may not know that at the moment. But we mostly collect this information in order to see why people have a need for 16‑bit AS numbers, but as far as I understand, we have never rejected the request and if you feel that that has somehow been the case we can take this off line after the meeting here, the session, to discuss, because I would like to look into it myself.
AUDIENCE SPEAKER: Third question, how much free 16‑bit ASN numbers does RIPE have?
ANDREA CIMA: We have 36 months availability. Three years.
AUDIENCE SPEAKER: But in numbers?
ANDREA CIMA: Numbers? I think, we issue about 150 a month... I will get the exact number.
Ingrid from RIPE NCC. We have about 1,900 roughly at the moment.
ANDREA CIMA: Let's say almost 2,000.
GERT DÖRING: So, if we keep up that rate, hopefully everybody has a 32‑bit compliant implementation in three years. Erik.
AUDIENCE SPEAKER: Erik bias. So, for the large BGP communities, I think it's about 17.3 Junos version where it's actually been supported which is now released or almost out of beta. So, it will actually, you know, I have seen the other implementation as well, where it's actually coming now into the router software for large communities.
I think the request for 16 bits from that perspective will actually go down. I don't see a current reason to change the current policy of working how it works, I think it works very well
GERT DÖRING: Thank you. Brian, please.
AUDIENCE SPEAKER: Brian Nisbet, HEAnet. Sorry, can I check those numbers? You are giving out 150 ASNs or 16‑bit ASNs a month? Because, 150 into 2,000.
ANDREA CIMA: That's in total.
BRIAN NISBET: I just wanted to check. Okay. Because if it's 17.3, that's... yeah, I don't think all the people are going to be deploying that software any time soon. So...
GERT DÖRING: Yes, but the thing is, who needs to deploy that? You need to deploy it if you are connected to a peering point or transit ISP that uses a large ASN. So of those few stick on 16‑bit AS numbers and leave sides can can he employ numbers, fine, the big pressure is gone.
I can understand not going to the latest router software release. We are very conservative in that respect.
So, I hear that you're making people's lives miserable on 16‑bit AS number which is exactly what you were asked to do. So keep asking, but I don't hear a strong mandate to be more complicated, so... the way you do it seems to do the job.
ANDREA CIMA: Okay. Very clear, thank you.
GERT DÖRING: Now we go back to that one. I have been around, as a bit of introduction, when that policy text came, it was the global coordinated policy text. So, "Organisation" in that context, we have had the discussion yesterday, is neither LIR or member or anything specific. It's somebody walking in from the street representing organisation can only receive a v6 allocation if they are an LIR. So, in the end, this means organisation is LIR.
Replacing the word "Organisation" with "LIR" would make the text sort of funky. And LIR can have an allocation if they are an LIR. So it's not just replacing the word. It's also thinking about what we want. What the text says is an LIR can have an allocation, it doesn't say a member can have an allocation. Erik.
ERIK BAIS: Yes actually brought this up as well in the last week. This is something where, that we noticed as well, specifically with customers not having ‑‑ customers that have the initial LIR, but if they want to have the the second LIR or the third LIR, this actually becomes a question, and from that perspective, the v6 policy is not in line with v4 where you would have one LIR, one /22 and a /32 or 29.
I would be in favour of having the same policy for v4 as v6, where it makes everybody's live a lot easier. This will actually have some impact if you start merging LIRs back to a single main LIR, and that's something that we need to discuss here.
However, it has happened in the past and I actually have an LIR with three /29s in it without providing proper documentation for it, but that was because I merged LIRs and that was before multiple LIRs actually existed or were allowed, or, you know, specifically allowed by the member choice. So, if looking at the member decision that was done a couple of meetings ago, this is actually out dated policy text which should be clarified and I think it actually makes it easier also for the NCC how to look at this. I can understand from a v6 perspective, that this may not be the best choice, but Jordi is standing there, why don't you give your view on it.
AUDIENCE SPEAKER: Jordi pallet. Can you go to the next slide? I'm not sure if it's that one or the other one, the next one please. One more... I am trying to remember. Okay, that one.
The point here is, do we really need to align IPv4 policies with IPv6 policies? I'm not sure about that. Or the other way around, it's the same. I mean, I think it's two different protocols and I understand that somehow the administrative issues may be about the same, but maybe not ‑‑ that's not the goal, right? Then, the potential disadvantage is, yes, you are receiving more IPv6 space without justification but of course that's true for the first /29, and the other thing is why will all for a single organisation multiple LIRs, they may have different internal infrastructures that require it, so, why then we need to stop them having multiple allocations because they have different LIRs? I think that's the summary of, let's say, the answer to this slide.
So I'm not sure we need to ‑‑ at the end it comes back to my initial point that I'm not sure we need to align both policies in that sense I mean IPv4 and IPv6.
AUDIENCE SPEAKER: Bogdala fury. I agree with the speaker, so we need some so ‑‑ we already face add lot of times with the problem when our RIPE staff says the difference in the infrastructure and equipment is not the reason why you can get for separate LIR in the allocation of IPv6. And as far as I know and understand, RIPE allocate and reserve some more space when they do initial allocations, so I would like to ask Andrea to give us information again, how much space does RIPE reserve doing allocation like /29?
ANDREA CIMA: When it comes to reservation strategy, we reserve for every allocation that is between a /32 or /29 we reserve in total a /26. For allocations larger than that, we reserve three bits. I think one important thing to note is that these are internal reservations, they are not reserved on the name of the LIR, so there is no guarantee that we will be able to give that address space to that organisation in the future. But, we tried to internally reserve that as much as we can.
AUDIENCE SPEAKER: Another one idea I want to bring for discussion is just to let LIRs allocate as much as IPv6 space as they may need. I am talking for allocations less than a /32, so for example if LIR needs less allocation, smaller, smaller one, so LIR is able to allocate this block the request. If they need more they can ask for more so we can just see how much LIRs...
GERT DÖRING: That would be a different proposal. So, that's a bit out of the scope of this. We could do this, change the minimum allocation size to be smaller. But that would have to be a different proposal. You two, and then we close the mike on this.
AUDIENCE SPEAKER: Jan Zorz. I currently don't knee any pressing need to put burdens on people to get IPv6 space if they want it. If they want it or if they need it. So, I would suggest that, to clarify, can you go a few slides back please ‑‑ so, cannot put in an LIR must be an LIR because that would not make any sense, but we can add point C that says an organisation can have multiple LIRs, and in this case they can receive an initial allocation per LIR. Would that make it clearer?
SANDER STEFFANN: I want to reply to that. Because I think there is, one of the disadvantages of the current text there is actually an extra point. If you read it, then it basically says that allocations are made to organisations that have to be an LIR. I think it would be, in practice we are allocating to an LIR not to an organisation. We are allocating to the LIR of that organisation. So I think, clearing that up would be better than adding a point C.
JAN ZORZ: What I'm saying is we should make it clear in point C that LIR gets the IPv6 allocation.
GERT DÖRING: Yes.
AUDIENCE SPEAKER: Erik Bais. An organisation can have multiple entities, business entities, and a business entity can have their own LIRs. Now, this is where it becomes tricky to actually use the word "Organisation" unless we actually use, or mean with organisation, one specific business entity. Because, this will actually ‑‑ you know, I know it's semantics, but specifically semantics is why we're here. And, you know, for reasons if people actually want to have v6 space and want to use it, you know, specifically the last one, want to use it, I would say, you know, why make it harder than it already is?
GERT DÖRING: Okay. What I'm hearing, I have to wrap it up because... I think everything important has been said. Organisation is a very ill‑defined phrase. It doesn't say entity. A business unit is an organisation. Sander and me is an organisation if we tried to organise ourselves. So, the text is not really clear in what it's trying to convey.
I would welcome one or two volunteers to actually write new text as this is a formal policy change. It might not change the outcome, but it's changing text that is very clearly policy so it has to be a PDP. Great, two volunteers found, we take it off line and then to the list.
As on the point of wasting v6 address space, a /29 is a huge amount of numbers, but on the global scale, how many 29s are there? There are many 29s, there are as many 29s in v6 as there are in v4. In the NCC /12 there are many 29s, so we can afford to waste a few. So we are not in immediate danger of running out.
ANDREA CIMA: No, that's really clear.
GERT DÖRING: Okay, a few words on that. I see Erik coming up.
ERIK BAIS: Actually, I am quite happy on the topic itself. On the route servers on the peering LAN it basically is a requirement, you can't go against that, they need to be there, otherwise continue won't work. Web servers, mail servers, those kind of things, should not be on the same IP space I think. Same as the office network, you know, doesn't need to be there, and it should not ‑‑ or there should not be a requirement to have the IXP peering LAN in the routing table, from my perspective. Well, you know, there is no requirement for why it should be there.
SANDER STEFFANN: Should there be a requirement that the peering LAN is not in the routing table? Or should we just leave that to the IXP themselves?
ERIK BAIS: I think they should shoot themselves in the foot if they do it. So let them. But, you know, it shouldn't be there. So it makes it easier to actually say you know, it shouldn't be there. So I would say not enforce it but recommend at that they don't. Or, I see somebody smiling there.
ANDREA CIMA: The recommend ‑‑ how strong do you want us to recommend something? Is it the shoot, is it the... no...
ERIK BAIS: I can understand the issue why we're debating this here, and let's go for it should, should not be.
The next slide ‑‑ shoot is should ‑‑ about the actual, the usage. The amount of assignments currently ‑‑ yes, this one.
How long will this actually last?
ANDREA CIMA: If we look at the last six months, I don't have a time estimate but we gave out four blocks, for /24s in the last four months, so you can imagine that we are talking about ‑‑ if it continues like that, more than 100 months, so, we have ten years of space there. At the current utilisation rate.
ERIK BAIS: Okay. So there is no need, from your perspective, to actually add a second /26.
ANDREA CIMA: Not at the moment. But I think the point is we haven't made many assignments to this because we have been quite strict on how it's being used. By saying you shouldn't be routing this space, people don't see a way of getting v4 address space masquerading it as IXP needs. So, they are actually just using it for the peering LAN and nothing else. If you are more flexible, it makes life easier for the IXPs that have the space, but on the other hand, it may also facilitate people trying to get the space for other reasons which are not IXP peering LAN related, so it's a bit of a balance. The easier to you make it to get the space, the more space will go out, will get out of the pool.
ERIK BAIS: What is the exact requirement to get the allocation?
ANDREA CIMA: You must be an IXP, show your to be publicly documented with an Open Policy, with the requirement themselves, you have to show the number of peers that you have. So, the requirements to get the space itself is not really difficult. But it's more than once you have it, people know that you can only use it for appearing LAN otherwise we will contact you if we see it as visible in the routing tables.
ERIK BAIS: But there is a minimum member requirement for...
ANDREA CIMA: Three, three members.
ERIK BAIS: All right. Thanks.
AUDIENCE SPEAKER: Rob from the RIPE NCC reading a comment from the chat room. This is a comment from Maximilian Whilhelm in response so Erik's comment on the statement that the IXP peering LANs should not be in the global table. The comment is how about IXP operators are strongly encouraged not to exporter the IXP peering line to the global routing table. This is me reading the text, I am assuming this is a proposal for the text, but...
GERT DÖRING: Well, more people on the microphone.
AUDIENCE SPEAKER: Aaron Hughes. Long time operator of IXPs and service providers. It's notable that IXPs connected lans generally get injected by members, not by IXPs from bad policy IPv4 redistribute connected. So I would not ding the IXPs for this problem. It is more traditionally all of the service providers that are connected that are making errors and that's out of the control of the IXP.
AUDIENCE SPEAKER: Jan Zorz. So, you have the list of these 96 assignments, do we have any idea how many of them are actually announced in the routing table?
ANDREA CIMA: There were 12 that we ‑‑ 12 had made the peering LAN /24 visible in the routing table. They all stopped but one I think, so ‑‑
JAN ZORZ: So that's not a huge ‑‑
ANDREA CIMA: No, because the other ones when we told them that the addresses shouldn't be used for anything else, any other services, they stopped routing it because they were using it for other services indeed. But they stopped, they were not aware maybe of the policy or it was done by mistake, let's say that there was no malicious intent behind.
JAN ZORZ: Can you go to the slide of where you ask where do we draw the line?
ANDREA CIMA: These are just examples.
JAN ZORZ: My personal feeling would be that if a peering LAN, would I draw the line just below running route servers peering LAN, my just personal feeling.
AUDIENCE SPEAKER: One more comment from the chat room, from Nick Hilliard. The comment is: Please do not insist IXP prefixes should not be announced into the default Freezone announcing IXP line prefix has benefits for debugging and remote monitoring
GERT DÖRING: Okay. So we encourage to the to do it but if they do it, it's their own decision. That's basically problem diagnosis which we have on the list. And what I'm hearing without somebody explicitly stating it, is that the policy is actually doing its job, because this is reserved for IXPs and it should last as long as new IXPs are built that need a peering LAN with v4. And if we have ten years ago, then that's a good number. Because new exchange points will be built. So I think the policy itself is doing the job quite well, and your interpretation is aligned with the Internet. So, I don't see the need to change anything here.
With that. Thank you for your time. Thank you for bringing these up. Thank you for the feedback, and microphone back to me.
ANDREA CIMA: Thank you.
(Applause)
GERT DÖRING: So, last meeting we had the issue about out dated researchess in policy documents that Peter also mentioned. We have a list, Marco did a very nice list of stuff he found. It's sitting on pretty much Sander's and my desk, and we were too busy or otherwise occupied to do much about it. So, apologies for that and we will get back up to speed on that after the meeting and also take the status discussion into account on that.
No discussion on this, we needed just to let you know why nothing happened there. Sorry, again.
Open Policy proposals. 2017‑01 "Publish statistics on intraRIR legacy updates." That was withdrawn. Because basically, it was intended to be beneficial to the legacy holders and the legacy holders didn't want it, so there was really no support to go forward. And the proposer did the reasonable thing, if there is no support, don't insist on it.
2017‑03. That was the attempt to reduce the initial IPv4 allocation size to a /24 to make the last scraps last longer. I think it was an honourable goal to sort of like, if you start a business in four years time, you need a few scraps of IPv4 to number your v6, IPv4 NAT gateways. The community didn't agree that this is a reasonable goal, so there were more voices that said no we don't agree to that. This is one of the proposals where it's very hard to find agreement because one side says get rid of this IPv4 runout to send a clear signal we need v6, and the other side side said yeah even with v6, need a bit of v4, so the first side said yeah, there is a market and you can get v4 if you want it. After the discussion phase, it was very clear that the positions were too far distant to get them into alignment, even twisting the proposal a bit, wording here and wording there, would not have changed that. So the proposer said yeah we're sorry, we did everything we could, but we have to withdraw that. Which, again, is the reasonable thing to do under those circumstances.
So, none of them are here, but if they are listening, thanks for your effort.
We actually have one Open Policy proposal left and that's the picks PI sub‑assignment clarification, which got discussed at the last meeting. Generally, it had support, but the specific wording to make the wording clear enough that the NCC knew what's desired and what's not desired turned out to be tricky, so it had a couple of iterations through RS to sort of finalise on a 2.0 text, and that has been published, the Impact Analysis has been published last week. I have been told that the Impact Analysis was more complicated than usual because of really trying to make the understanding very clear.
Anyway, the proposer cannot be here in person, but he will be connected over Skype for audio, since he is not having video, I said I will just present his slides, go quickly through them and point out the actual changes of 2.0.
That's sort of like the standard slide but you all know that this is webcast, please state your name and affiliation and so on but you all did this very nicely in the last round so this slide should have been earlier in the deck.
So can I have Max's presentation please?
Max is the proposer. It's been in the system since about a year. Their problem statement is they want to use IPv6 PI to number Fry function which is sort of the community wireless stuff, so anybody can connect to it and it's not customers, members, whatever, it's just people random from the street that connect to that service. They want to give them IPv6 of course and the IPv6 policy is interpreted in a way that says you are not allowed to do that, because it says, no sub‑assignment whatsoever, and the NCC interpretation is that means no third‑party can ever have any bit of it.
Which we knew, but it turned out to irk them so much that they decided to do something about it. I'm not going to go through all the details, I am leaving them here so you can read up the background if you want.
So, we tried this wording at the last RIPE meeting, and it turned out that it wasn't clear enough either. So, this is the new text, or specifically this and the next two slides are what's new.
The new approach is to tackle the sub‑assignment definition in the document and make it very clear what a sub‑assignment is and what is not, and then have the same clause in that says sub assignments are not allowed but make clear that there are specific practices that are not considered sub‑assignment. So these are allowed.
So, that part, 2.6 is the current definition in the policy, there is no change in that wording.
The new block is here. An addition to the definition of assignment, which basically boils down to if you run the sub‑net, somebody attaches to that sub‑net and gets one or more addresses from that sub‑net. But you are still the person operating, running, managing the sub‑net, then this is not considered a sub‑assignment because the single address is not considered an assignment in that context. And they have specific examples in here, visitor network, server networks, so that policy would then also allow, like, server hosting, provided you only give the server a single at that. Point and not route a network to it. And it would also permit sort of like DSL providers to run the old IPv4 way of single address to the customers, which was always one of the discussion issues here. If you permit Wi‑Fi, people will abuse this to do other things that we do not want. But, the feedback from the last round of discussion was, the market is mature enough now that we don't really worry about that any more.
So, enough ISPs are giving their customers 56s, so there is good examples on the market. And we should not worry too much about ISPs that are doing stupid things if there are other doing the right thing already.
And one small word was added to make clear that this is talking about sub assignments. The policy said assignment here, and you never can assign part of an assignment. So that was kind of moot, so that's wording clarification.
That's the intention of the policy change. What Max thinks that you should be able to do with IPv6 PI space. And what should not be the intention. The Impact Analysis is on the web, and now we are back into review phase. So, your feedback is desired.
I'll change the slide back to the actual wording, the gist of the proposal. I think Max is on Skype and can hear you in realtime and answer. Max are you there?
MAXIMILLIAN WILHELM: Yes, I am here.
GERT DÖRING: Any comments on the microphone, feedback, please? Jordi, coming up to the microphone.
SANDER STEFFANN: Before we start at the microphones, Peter Koch reminded me yesterday that we are really open community, your name does not have been to be Erik or Jan or Jordi to be able to walk to the microphone. Please, even if you are new, we would really like everybody's opinion here, so, don't feel that this is just for the well known people here, please everybody can participate.
AUDIENCE SPEAKER: So then I'm not Jordi. No worries, it's a joke. My concern with this is probably most of you know there is in basic stops in the last call document that explains that it's a good thing and it may be very useful to assign one /64 per host. So, if I understood correctly, the current text will disallow that
GERT DÖRING: Right.
AUDIENCE SPEAKER: So we are somehow making a policy which is in conflict with one standard, or it will be standard in a couple of weeks or so
GERT DÖRING: I am going to take this. Because it's not a mandatory thing for anything. It's if you run a public Wi‑Fi with customer isolation, which they don't, then it's a best practice to give them a 64 per host. But that doesn't mean cannot run your Wi‑Fi otherwise. It means that sort of practice would not be possible with the new policy text. It's not possible with the old policy text either. So maybe we need to come back and revisit it. But we shouldn't ‑‑ I don't think this is an argument to hold up this change.
AUDIENCE SPEAKER: A know it's not an argument because we are not mandated to follow policies, we can break it
GERT DÖRING: We are not breaking it.
AUDIENCE SPEAKER: But the point is, we are restricting, not breaking, restrict it go, you want to change the word.
SANDER STEFFANN: Jordi, the thing is, the prefix delegation also isn't allowed with PI space in this way. We're not saying we don't ‑‑ we restrict these RFCs, if you want to provide this kind of service, you have to have PA space not PI space.
AUDIENCE SPEAKER: I agree. My point is, either we do it correctly and we don't do this and keep the actual text, we don't change anything, or we do it in such a way that we give all the options, or alternatively, we get rid of the PI, PA differential. I know it's a different story, at the end it comes to the state your name. I mean, if we are going through this text, we are saying hey Max, you can do the way you want, but maybe tomorrow somebody wants to use the /64 for this wireless client isolation, so we change it again after tomorrow. Is that what we want? We can do that of course, but...
SANDER STEFFANN: If we try to get a perfect policy that includes everything we ever wanted we will never have to policy at all. So I think we need to take this one step at a time.
MAXIMILLIAN WILHELM: Two points. We had the PI versus PA discussion half a year ago in Budapest and we decided to postpone the PI/PA discussion and get on with this fix here.
Point two: To my understanding as I read the Impact Analysis, the /64 delegation part from the view of the RIPE is allowed with this policy change. Maybe Marco or Andrea or anyone can elaborate on that
GERT DÖRING: While the NCC folks are searching, maybe Peter in between...
AUDIENCE SPEAKER: I'm neither Jan or Jordi but breaking my own advice. Peter dock, DE‑NIC. I looked at the current policy text in the rest of the document, I think we are trying to introduce another complication here, which is that we use the word sub‑assignment without having a clear understanding what we mean by assignment and even less so what a sub‑assignment then actually is. The assignment is ‑‑ isn't ‑‑ sub‑assignment isn't defined in 684. The term is used and the whole thing is I am missing the transient nature of that thing that I guess is trying to be addressed by sub‑assignment here. And on the PA versus PI, if I am a PI holder and I have a guest LAN and I assign the /64, assign, no, I don't, I give out the /64 for the guest, I would be violating this policy. In the same way that Max thinks that he is currently violating the policy and I disagree on that
GERT DÖRING: Well actually the NCC thinks that he is violating policy. So that's where the whole thing started. He put in the request for PI with a very clear description of what he intended to do with it, and the NCC said no you can't. So, maybe he should have put in the request for just give me a PI and I intend to use it for me and he would have received it. So, he is trying to be very honest and upfront about it and colliding with the policy, so... can
PETER KOCH: We also have this ambiguity about organisation. Now, if I personally am a guest of somebody who has this PI space and assigns the /64 to somebody signing up on the wireless LAN, I am not an organisation in that sense, or am I? So, I guess we are on a slippery slope here trying to catch something that we should address in a different way. Again, I am missing the transient nature of this handing out of an address and the purpose and the holding and the responsibility and everything to be captured. I think we are going in the wrong direction with ever more trying to nail down and capture details of what this might be, and then somebody comes up like Jordi, or I did, with something that would still not be covered and the next has to capture that.
MAXIMILLIAN WILHELM: So what do you propose?
PETER KOCH: I said think about the transient nature and let's not call these things sub‑assignments or ‑‑ well, first of all, try to find a definition for that word if you really want to use it, what is the nature?
SANDER STEFFANN: That's what this policy proposal does at the moment
GERT DÖRING: Actually it doesn't. It says assign and then later on it's called something sub‑assigned without actually defining sub‑assignment, so there is definitely housekeeping to be done. Because, it says a seen here and it's not changing that. It doesn't say sub assign here. But, there it references sub assign, so, the balance is definitely not right, if we want to keep that track, there is more wording changes needed.
PETER KOCH: If I have a contractor working in my PI space, the contractor is not part of my organisation, is that another organisation that I sub‑assign address space to.
GERT DÖRING: Yes. You give them addresses. That's an assignment.
PETER KOCH: Let's continue splitting hairs. I think the problem is somewhere between the ‑‑
GERT DÖRING: The problem is that the original policy, the current existing policy says no sub‑assignment whatsoever and the NCC has brought this up a few times and said this is clear enough that cannot draw a line between things that we think are okay and things that we think are not okay so the NCC's interpretation is whenever you give an address to a different party that is not your organisation, whatever your organisation means, it's not very clear. We deny the request. And that's causing friction.
PETER KOCH: Yes.
GERT DÖRING: Marco has the answers.
MARCO SCHMIDT: I first want to respond to what Max asked. It is true when we create an Impact Analysis we also considered configuration mechanisms that would be needed to give a separate single address to a customer as being in line with this policy. Under the condition that it's a kind of dynamic assignment like, for example, what some Viber hot spots do and we did this, that was one of the reasons why we also took a long time to be also a bit more open to the different use cases. But all the discussion that is we have had now here, it shows that it will create a grey area and we are aware about it and we try to find a good compromise between being practical and comprehensive but yet not allowing an abuse of that policy basically.
GERT DÖRING: I think Romeo was first with Jabber feedback and then Jordi again.
AUDIENCE SPEAKER: Romeo with proxying a comment from RFC. Although I believe it's a comment with regard to another section of the document. So, you may want to consider taking this separately. The comment is from Tom Rishter, Fast Telecom, can you explain the transfer restrictions in section 2.2? This restriction does not prevent the resources from being transferred due to further acquisitions and mergers ‑‑
SANDER STEFFANN: That's definitely out of scope for this part.
GERT DÖRING: So please take that question to the list, feedback to the person who asked.
AUDIENCE SPEAKER: I will proxy that feedback as well
GERT DÖRING: Take it to the list or the Working Group Chairs list but it's a different scope. I think Jordi and then Erik.
AUDIENCE SPEAKER: Jordi Palete. Peter, I think it's even worse if you have an employee coming to your wireless network which is a smartphone, you are breaking the policy. I think that's my actual reading of the existing policy, right.
So it's really tricky, we are in a grey area. Then if I understood correctly what Marco said, basically you are saying that if you are assigning by means of DHCP you will not be following this and if you use router advertisement, yet? Or was that not the point? Because, the assignment mechanism... awed
MARCO SCHMIDT: Its are depends on the case it will make our evaluation a bit more ‑‑ we will look if there is any prefix Dellcation, the policy would not allow it, but if it's a mechanism that is needed to give a separate address and there are some discussions in the technical community that you know much better than I do, that where a /64 will be needed you give a single address, then this would be allowed, was our understanding.
AUDIENCE SPEAKER: So basically using route advertisement for the point‑to‑point link or for connecting the customer. It works but using the IPv6 prefix delegation, it will not work, I agree with that, but, again, following that, what I mentioned before is that because the single prefix per most is done by using routing ‑‑ sorry, a SLAAC, it should be inside this okay. So following that, so we need to fix our position one way or the other, about you not something in the middle. Then I wanted to comment: I think, in practice also following something that Peter said, when I volunteered a few minutes ago for the previous change with the organisation thing, LIR, and so on, I have been trying to define find a definition of organisation in the actual policy text, and there is not, so we have a bigger problem here, is that we need to define some additional terms and maybe defining that resolves some of these problems, I don't know, maybe we make it more complex, or maybe we need to review the complete text of our existing IPv6 policy. I think it's a broader problem that we are looking at here
GERT DÖRING: Okay. Please make it quick. We are already in the coffee break. I intend to not use the second time slot today because it's really, we have just five minutes more of discussion and wrap‑up and no need to use the full slot, so you can go to EIX.
ERIK BAIS: I'll keep it short. My definition for an assignment is something we actually register in the RIPE database. So ‑‑
GERT DÖRING: But does that mean that I can run a full ISP on this as long as I just refuse to register anything?
ERIK BAIS: No, because you will actually have assignments, you know, as a full ISP, you basically similar with v4, you have assignments in your infrastructure for your infrastructure in the RIPE database, and for instance, we do the assignments in the RIPE database for customer VLANs, those kind of things. The policy further down the line actually prohibits to provide certain services like allocation and those kind of things of third‑parties. If it's a temporary use of addresses, that is different in my definition than in actual assignment, and basically cannot do an assignment once you already have PI. So, that, by definition, will actually, you know, disallow this already. So the terminology for what is actually an assignment is actually the root cause of the issue here and I would not go down the line of adding a different layer of complexity and go for sub‑assignment for something that cannot assign already.
GERT DORING: I am hearing you. Jan.
JAN ZORZ: This time with the hat of Go6 institute, and I am not I am risking my IPv6 space but I will saying it anyway, I am causing trouble to myself. We are running O 6 lab recollect that's a lab for IPv6 experiments and stuff like this, and we have IPv6 PI space, right. There is plenty, /48, you you know experiments it's plenty. But people started putting in and asking me, this Google measurements labs, can we put servers in your lab to do some measurements, and you have this server, an owe net, a NANOG ring, all this stuff which is actually good for the Internet, and I am not able to do sub‑assignments, so all the complaints are coming to me. We are hosting the Atlas anchor and I'm not able to do the sub‑assignments if Atlas anchor would do any harm and go to the RIPE NCC. So I don't see any point, if I would want not to break the rule and not break the policy, I would have to become an LIR, and I see no point in that. So, why we don't just drop all these burdens and let people use IPv6 as they want. Thank you.
GERT DÖRING: I am hearing very clear words from the room, that and sorry to say that, Max, this version, while it might fulfil your requirements, is actually not what the room wants. So, to the room, please voice your concerns on the mailing list as well, because actually they are different concerns on this, it's not like a single word change could fix this, but it's more a wider problem. Which means that this, in the way it is, does not have the support I thought it would have after the last discussion and taking that into account, but we definitely need to discuss this on the list and then either come up with a 3.0 or restart it with a different angle of attacking the whole thing. Thanks for your feedback. Max, thanks for being here and thanks for doing quite a lot of work on this, even if it didn't work out as nicely as we all hoped for.
Please a round of applause for to Max for getting up very early to tune in.
MAXIMILLIAN WILHELM: Thank you. I am wondering as well about the new opposition, I was hoping that this would get more approval after the last discussions.
GERT DÖRING: Yeah, but we need to actually take that to the list because the arguments were differentiated enough and complicated enough that it's more than we can just sort out by creating a common understanding here. So, it's really to the list.
MAXIMILLIAN WILHELM: Sure.
GERT DÖRING: So. Thank you for that. I am fully aware that I'm in the coffee break and we only have one issue left on the agenda. That's AOB.
I will skip the Open Policy hour but I got no formal request to present something, so there is nothing here.
AOB, Working Group Chair selection. Sander is leaving the ship, leaving me alone here. He has done a great job since about ten years, ten and a half years, and he has decided that it's time for young blood. So his term ends in, at the next meeting, and he is not volunteering to take this on again. If you are interested in being a co‑chair of the Working Group, please approach Sander or me. What we are going to do is of course do it on the mailing list, announce it on the mailing list that Sander is stepping down and we are looking for candidates, and then we expect you to introduce yourself, but if you already know you are interested in this and you are here, please come and speak to Sander and me so we can give you the early warning what's to be expected, what the work load is, so you have some sort of understanding what you are getting yourself into.
We have a few people already that approached us and said, yeah, this sounds like I could do this and I would be willing. But more volunteers are certainly welcome. So...
And that's basically it. Apologies for stealing ten minutes of your coffee time, but the benefit is you can go to listen to the connect Working Group in the next slot and don't have to go to the other room and just stay in here, which I'm going to do.
Thanks for the discussion. Thanks for the feedback. See you on the list and see you at the next meeting in Marseilles. Thank you.
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
