Address Policy
Wednesday, 22nd May 2019 at 11 a.m.:
ERIK BAIS: Welcome back to the second slot. I hope you all had a good coffee. So, Sander, you are up next. How is your voice doing?
SANDER STEFFANN: Reasonable. Better than expected.
When my voice starts failing I will delegate to Erik, he knows what I want to say.
So, discussion of policy proposals. We have a policy proposal about making a waiting list when RIPE NCC runs out of IPv4 addresses. Used to have a different title, we rebranded it to make it more clear what the goal of the policy is, to make that more consistent. So the basic idea was already presented in the previous session. There is basically a couple of things: At some point the current pool will run out. When that happens, we have to think about what we do. There will be, as you saw, like roughly 80,000 IP addresses coming back to the RIPE NCC every year.
Now, we could just throw them away, we could give them back to IANA, I see Owen looking the first idea. But basically, from what we discussed with people in the community, not handing out those addresses would be like in direct opposition to the actual goals of the RIPE NCC. So, if we don't want to just hand them back to IANA or throw them in the bin, we have to have a policy on how to do that. So, we think this is the best solution for such ‑‑ for that situation.
It will not be perfect but, you know, it's IPv4. So that's basically the idea behind the policy. Has anybody read the second version of the text? Okay. I see a few hands. Like I said, in the first version we kind of focus on the wrong things so we tried clarify that in the second version. And yes, is there any feedback on Version 2 of the proposal? Is this something that has support from the community? Do you think we should do something completely different? But yes, I have to warn you, we thought about this for quite a while and it's not easy to find the best solution, like the ‑‑ considering it's IPv4, it's out, so we have to go for the best realistic policy here. So, yeah, I would like your feedback on that. What do you think? Where should we go? I see Randy raising his thumb. Everybody else didn't have enough coffee yet.
ERIK BAIS: So I have, there is one thing which is overlapping in your policy and the policy that Remco proposed.
SANDER STEFFANN: Yes
ERIK BAIS: That is the part for the IPv4 dust. I have asked the NCC to provide insight how much are we talking about. Your policy specifically states there is ‑‑ if there is something which is smaller than a 24 we should keep it aside and wait until the complete 24 is actually, you know becomes available. That might take quite a long time.
SANDER STEFFANN: A couple of decades
ERIK BAIS: It could be. And well it might actually be useful if it's not so much and that is why I asked for the information from the NCC, to basically decide well just put everything in the IXP pool and hand it out for smaller. I know there are 29s and 27s out there. Some actually have been transferred 27s from an LIR to one of their customers. So there are some that were creating and some were actually handed out in decades ago by the NCC as PI or something alike. So we will see how that goes. We will wait for the numbers on that.
SANDER STEFFANN: So, the reason why we just said, okay, everything smaller than a /24 is just dust and it's unallocatable. That was before the IXP pool proposal came up. Now, that proposal is there, we can just remove that from our policy. They can, I think they can coexist perfectly fine.
PETER KOCH: DENIC. So, at the risk again of making things a bit more complicated ‑‑ things are already complicated ‑‑ and while I don't think it is particularly wrong what you propose, I get a bit of a headache when I read first‑come/first‑served waitings you either first come or first served or waiting lists. It's a regulatory principle in a way, and if there is no resources to assign at that particular moment, you could also argue that, sorry, you were the first in line but we have nothing to provide so sorry you go home. And implement it in a different way. What I'm getting at is, maybe by way of getting the legal impact analysis, we try to get a bit of, say, more academic insight or regulatory expert insight into the balance between different possible approaches to this, just as a protection for any challenges that this policy might receive in the future.
SANDER STEFFANN: Yeah, we inattentionly didn't try to micro‑manage the RIPE NCC and just leave ‑‑ leave it to them, just set up the basic principles. So, yeah, if the NCC has feedback on this from a legal perspective and from their perspective, we would definitely take that into account. We don't want to make things any more complicated than they need to be.
PETER KOCH: Sorry, probably I expressed myself wrong. It's not about micro‑managing the NCC, also not in the impact analysis usually we don't call out for external experts for an assessment of the regulatory part of, if we like the word or not but that's where it comes from, of the things we do. I think we are at the very interesting point in time when this gets into execution and what I'm asking for is a safety belt so some outside expert opinion on this and an assessment, if we can get to that.
SANDER STEFFANN: Marco. Response?
MARCO SCHMIDT: RIPE NCC. We looked at it from a legal side as part of ‑‑ we didn't see any big concerns there so we will, once it's there we will look at the most reasonable and fair approach and in general the first‑come/first‑served makes against and it's good it's also stated in the policy.
SANDER STEFFANN: And the word waiting list because ‑‑ the combination of those two.
PETER KOCH: First‑come/first‑served if you have no resources to allocate can be interpreted in different ways and I am not saying this is particularly wrong but it's not implied so we are making a decision and it might be useful to not just make that decision but understand bit of the theory which I don't.
RANDY BUSH: In the IETF vein send text.
MARCO SCHMIDT: While I use my chance to cut the queue, I want to make a quick comment about what, the arguments the potential of the conflict of these two policy proposals that might challenge or tackle this issue about small IPv4 dust. I would like to remember if your proposal would need to be changed to a new version to take that one out it would need another review phase with even if it takes less time, for something you can at this stage not be certain that the IXP proposal would reach consensus, so I would keep that in mind would be thinking about it, might be a idea for the second proposal, let's say one would reach consensus, the other one, the ongoing would then adapt and adjust that part in the second proposal.
SANDER STEFFANN: So you are basically suggesting we should hurry up and finish this before the IXP proposal gets consensus?
MARCO SCHMIDT: Basically, yes.
RANDY BUSH: IIJ and Arrcus. The routing implications of dust and I think, as I have said over the recent years, I think we are going doing there. I think that has intersection here with what you give out and proposing to give out dust to somebody today when something for formal and larger has not caused the routing system to start to change, is not very kind to the recipient.
SANDER STEFFANN: No, so this policy proposal explicitly says one /24 as a whole, no dust. Dust is ‑‑ not allocatable in this policy proposal.
RANDY BUSH: Right. But it is in the other.
SANDER STEFFANN: But IXPs don't need to route it
RANDY BUSH: That's something that is not clear. Some think they want to leak.
ERIK BAIS: That is ‑‑
RANDY BUSH: What I want to know is, can we have this part of the discussion in the Routing Working Group, please?
ERIK BAIS: So the proposal from Remco and Will and Will states you will get a 24 but you can request if you want smaller, if you are not planning to route your peering LAN. So it's by decision of the IXP holder that requests the allocation. And that's ‑‑ so nobody says we are going to hand out dust, well at some point there is going to be, but that's because, you know, it's something that we will have at some point. If somebody decides we don't want to have it routable anyway it needs ‑‑ it doesn't need doing into the DFC, then and they are more than happy to take a 27 or 26 and that's available in the pool, then they can request that. But typically, the allocations are going to be 24s or multiples of that.
RANDY BUSH: My apologies for not making my hat clear. I am taking off my language lawyer hat and putting on my routing geek hat and I think I need to start ‑‑
SANDER STEFFANN: I will make the group aware of this.
Owen: Great home technologies. I think that the idea of a queue is perfectly fine. I think that the idea of, we don't have anything left so go home, is a very bad one. I think it turns the registration process into a lottery where everybody tries to time their request for when the new space becomes available and you get this run on the bank phenomenon that just doesn't lead anywhere positive for the community. It makes things unpredictable, it creates haves and have nots through pure blind dumb luck even greater than that tends to happen normally. And I don't see any benefit to it, so having the queue is a better process.
SANDER STEFFANN: Thank you.
ERIK BAIS: Anybody else? Any comments, questions?
(Applause)
Good. That brings us up to open policy hour. We have one person that came up for, to talk about the extended stats file. David, Rudiger?
GERT DORING: Word of warning in advance, this is not really technical Address Policy, but it's sort of like all the people from the regional registries are in this room and this is a topic that should be discussed, so we decided we have time on our agenda, everybody who is affected is here, so it's a good place.
RUEDIGER VOLK: Thanks for giving the slot and yes, this is kind of abuse of the formal set of the whole conference but there are some problems with the formal set‑up.
Can we have my slides?
ERIK BAIS: They are coming up.
RUEDIGER VOLK: Okay. So, they are disappearing very quickly again. We know that the RIR data ‑‑ RIRs are forming the NRO and sometimes it is not completely clear what the NRO is actually doing. There is actually data that is formally provided by the NRO and it looks like not too many people are using it for operational purposes. I'm actually ‑‑ I actually started to do that and I have seen problems there and it escalated on Monday when the data for one of the RIRs essentially went completely bad and misformatted, so I felt the drive to speak up.
So what data and what is the significance of it? One can have a look at what ‑‑ have some questions and issues for the data, the main point for me is talking about the observation of problems and then of course there is the question of conclusions. So much for the overview.
So, the data I'm talking about is the delegated extended file which actually the big underlines are supposed to be links ‑‑ are to be supposed hyper links pointing to something, well okay the file you are seeing the URL completely, there is actually a accompanying documentation about the format and the meaning. That the file itself is used as normative reference in Internet draft that is given and, yes, that draft didn't receive much positive response but, nevertheless, the NRO moved on and did an official announcement about what they are doing in their RPKI and that official statement used the reference to that Internet draft as essentially the technical justification and as reference for the details. So, going through these three ‑‑ no, four bullets, I conclude the NRO, in fact, has, in some way, published that information officially and made it something where I would think they are promising to provide that data in a reliable way. The statement, the statement essentially ‑‑ the Internet draft essentially points out that this file can be used by parties that find information in the RPKI ambiguous and questionable, which is a potential due to the announced change of the NRO's handling of RPKI, so kind of the delegated extended is pointed as a last resort of truth in the resource delegation thing.
Well, regardless of what's the state of that commitment and the technical background, anyway I think it makes a lot of sense for a well‑run registry or a well‑run coordinated cooperating registry system to provide a unified aggregated form of the registry data. So, one can have a look at the NRO delegated extended.
And there are a couple of questions of, well, okay, how can this be generated and main in maintaining or is it how is it generated and maintained? Lots of technical stuff that for the end user of course is something in a black box that needs to be run by the NRO, and I'm not ‑‑ I'm not going through these things with all the separate bullets, in the end there is quite certainly one question, how reliable is the data that is being provided.
So, for observing the stuff, sometime in late 2017 actually after the NRO statement had been put out, I started to look at the ASN information in that file and what I was doing is, essentially looking at ‑‑ taking that information and comparing that with the occurrence of ASs in the actual routing system and the specific questions for me are typically which IANA reserved ASs are showing up in actual announcements which should not be there? And that's a kind of a very interesting part. Which of the ASs that the RIRs have in their reserve and free pools and that obviously should not show up in real life, which of those are showing up? In actual announcements, in the databases and in RPKI? And you can hit matches of in all of these three cases, and kind of each occurrence of such a hit raises interesting questions, the thing that I have been doing over the past couple of months has been to tell peers and customers, hey guys, you are giving me this IRR information and, hey, have a look how much garbage there is, should I trust the rest of your data even if I ignore the obviously outdated fat fingered, whatever? So, kind of looking at the ASN data in delegated extended is look at a fairly small and simple part of that data and I have seen, I have seen kind of once in a while, strange things happening there. There was an incident last autumn when IANA delegated a couple of ASN blocks and, yes, well, okay, integrating the IANA assignment, led to data in delegated extended that was completely inconsistent with IANA's delegation, and it took a couple of weeks until that was figured out and fixed. Since early ‑‑ since early this year, the AS 0, according to delegated extend, is in the free pool of AFRINIC. Nobody noted except me or at least nobody did make noise, including me. This Monday morning, I was look at my regular stuff and I found, yes, for one RIR all the AS information went bonkers. In my evaluation it looked like it had been moved all over into the IANA free pool, looking more closely at the actual delegated extended the data looked completely garbled. And that that pushed me to do the very unusual thing that I write slides and prepare for going on to the stage with slides.
Of course, circumstances here at the conference are very special so on Monday morning I was talking with a few people in the audience and, as it happens, the hacker who has been hacking the stuff for many years, got the error report and fixed things quite quickly and I can report today it looks fine and it already looked good yesterday. But can I depend on something that, if something goes wrong there, that I happen to be in the room with someone from down under? I don't think so.
So, conclusions:
After such observations, I wonder whether I can trust that that database over time and over all of its content, I guess that's at this point in time obviously a rhetorical question. NRO I think has to explain what their understanding of their joint responsibility in this case is and how they will actually ‑‑ how they will actually act to address that responsibility. There also is the question, I haven't been looking at the data for many years, but it is known that this data has been flakey over all those years and as a joint activity, publicly visible, presented to the operators, delegated extend has been there, how can it be that NRO actually has not acted on this over so many years where it has been known that this is flakey. I think I remember certain people who were saying you can't use that stuff. I ignored that, I ignored that, when I started to use the stuff. On the other hand, if the NRO is doing stuff that cannot be used, what's the use of doing this? Is this for confusing the community and the world? Or I am already clear what is useful for then?
So, for the slightly softer notes on closing, yes, we have good circumstances here for fixing the problem on Monday. Oops, but quite obviously we cannot ‑‑ we cannot prevent go for conferences for getting things fixed because they shouldn't be broken in the beginning and so go back to the conclusion slide and any comments? I think it may take NRO representatives sometime to figure out how to respond. This will go by me into the GM this evening because that's the RIR that we are discussing here.
ERIK BAIS: I have a question for you. In your ‑‑ I had a small discussion with David on this as well prior to this. In the case of Inter‑RIR transfers, things change with, allocations get removed in the RIPE region and it pops up a day or two days later in the ARIN region or the other way around. This is also typically inter RIRs are one business day that it takes to take from one end to the other and as it's a manual process, you need to have people in the office so, you know, there is only four days where actually Inter‑RIR transfers are being processed.
RUEDIGER VOLK: Yes. Kind of from my point of observation, these could look like short time glitches that kind of recover quickly. However, I actually have ‑‑ sorry. I actually put in even a bullet for that. When you look at the data and how it is processed and what it is promising, the question of is the process of the transfers and how it is mapped into this data and other data, is that actually documented? I know that I have been asking for documentation of that stuff in particular in the RPKI environment and, yes, what I'm saying is, for making full use of this data ‑‑ data documentation ‑‑ of this data, documentation of the transfer process and how it is mapped here would be at least a very good idea and in the context ‑‑ in the context of the documents that I was referring to, the Internet draft essentially says yes, look at this data for this completing claims in RPKI for resources between the RIRs but be aware we are not giving you exact hints about how that's going to happen for transfers. Well the wording is a little bit leaner and streamlined and a little bit less pointy when I am speaking here but yes, that is a problem and if the documentation says there may be ‑‑ there may be two days of overlap with something, an operator, a user of this data might be able to deal with it.
RANDY BUSH: IIJ and Arrcus. How much of this can be automated? The idea of replicating Ruediger Volk's is daunting so could the checks be automated?
RUEDIGER VOLK: I am pretty sure that checks can be automated and some of the bullets on the screen are kind of pointing to the possibility that this could be. What I observe is that quite obviously, the RIR information that is used for producing this looks to be different for each RIR and the process of changing data structures and files in the RIRs seems not to be very well coordinated with the process of producing delegated extended, and yes, if the NRO takes this up in a responsible way I would expect an explanation of what checks they are applying to the results.
RANDY BUSH: My hope is that you could help the NRO wherever we can get a handle on them to automate these checks on a regular basis, publish just like we publish Phillip Smith's fragmentation thing every week, etc., etc., and it's not the point to name and shame but to ‑‑ first of all, telling those of us who are trying to use these data where it's good and where it isn't and whatnot to trust this week and, secondly, to give the NRO a handle on how to maintain these data with more accuracy.
RUEDIGER VOLK: Well okay, what we did have on Monday was really a format mess‑up where I have no insight and I'm not interested to see the details of what in the RIR data changed, the delegated extended actually looked like, yes, it was still a CSV file but several of the columns were garbage. And kind of, that's stuff that never should be moved to publication by the NRO. That's checking that has to be done before the publication.
PAUL WILSON: Head of APNIC. There are other RIR, CROs, all of us part of the NRO EC here. And whether anyone else wants to comment, I don't know. I am actually really surprised and honestly alarmed by what you are saying, Rudiger. I haven't been aware of this level of inconsistency at all, and people might laugh at that but that's absolutely true. If I had been, that I would have been taking, as I have done in the past, actions to make sure that we fix what's broken. There is a bunch of consistency checks that happen at APNIC that ‑‑ and where is Geoff Huston when I need him, but he has implemented most of this stuff, we have been doing it for years, consistency checking between Whois, between our internal registry the delegated stats and identifying issues that come up, and I hope acting on them. So I am not ‑‑ obviously we have been doing that very, very badly and please don't confuse incompetence with disinterest here because actually I am very interested in fixing this stuff and I think, as Randy said, we apparently could use some help with it.
As for converging in what all of the RIRs do that's easier said than done. We have got five fiercely independent organisations and communities here and I don't think any of us are particularly good, I'm afraid, at sort of ‑‑ at bending and changing our own extensive sort of sets of legacy systems to magically somehow converge on something that works marriagically Wouterer. So that's easier said than done, but the kind of checks that you are talking about and documentation about where the data comes from, what should be the expectations of the data and how it should be interpreted etc. Are all pretty important. One of the things that we are talking, and I don't think it's a problem for me to mention this, one of the things we are talking about is the convergence of RIR systems on, for instance, consistency in our RDAP implementations which is fairly notoriously divergent at the moment, sort of having gone from experimental into production without the proper sort of convergence in that process but that is just one of several and I guess this stats publication is another one of our adopted global coordinated responsibilities that I think we all do take seriously and maybe my, some of my counterparts are less surprised than I am but I really am very surprised and would like to hear about specifically what the problems are. Thanks.
RUEDIGER VOLK: Let me comment a bit on it. How you are operating, of course, is not very transparent to me and there are many things where I would not care to know. My suspicion is that the activities at the RIRs have been kind of focused at the other side of maintaining this data like the RDAP and the usual access to registry data. While this has happened someone ‑‑ sometime back in the past and I would guess that none of the RIRs actually has defined, sometime slot and some person to actually be responsible for caring for that end of your business. And okay, I guess you will have each to define that and figure out how to make that into operate in the NRO.
PAUL WILSON: Sure. Thank you.
John Curran: ARIN. So it turns out that this isn't an unknown problem. The RIRs have coordination groups which span various departments so we have a registration coordination group made up of the leads of those areas, we have an engineering coordination group. And they do actually talk about the formats of some of these files and how they get published and how the feeds get put together. But you are right, it's not a primary focus. And they do handle concerns that come in about inconsistencies, even if Mr. Huston generates two‑thirds of them because he generates a lot of stats off these. When we hear about it, it does get addressed. So, there is no clear way for you to report when you see something wrong, and that's obviously a miss and needs to be fixed.
RUEDIGER VOLK: Actually, I have to admit that, for none of the problems that I mentioned here, I did formal problem report and I was looking at the NRO pages and I found that I think there is essentially a pointer if you have anything to ask the NRO send it to German.
John Curran: Shouldn't have doing through that. We should have a contact for the sacky of these files and a documented format and that's very clear. The other thing though is that I always know it's an unusual day when I find myself agreeing with Randy, but in truth, this should be monitored, not only by us, but by the outside, okay? It would be good to have someone watching this and producing the same sort of reports we do for other things and publishing them and saying this is what's inconsistent today, nothing like having that visibility will instill as much focus on accuracy. So I encourage you and the others in the room, start looking at it and publishing it. Do tell us about it and we will also do the same. You shouldn't be the only one having to worry about that. But yes, this is a case whereas he said, it's good to do the cross‑checking and publication, if nothing else other than to warn others who may be using the data for something. So do it. Rudiger's weekly delegated stats report. We should it too but there is nothing wrong with both.
RUEDIGER VOLK: Kind of for the sequence you first have to install quality assurance. Kind of, I think the community can expect from the NRO to put out data that at least formally is correct, and occasional inconsistency and inaccuracies happen all the time, we are all humans, we have not been completely replaced by Bots and kind of for small things to happen I don't have a problem, but you should really set the goal that you produce something that is quality‑checked so that it can be used in an operational environment and in an operational environment you do not want to have the alarms going off, oh shit today we got garbage input.
John Curran: I agree, we did believe publication was having on reliable basis so it's good to bring it forth. It's good for you to publish and say publicly this is what's wrong, here is the discrepancies I see.
ERIK BAIS: Thanks, Rudiger.
(Applause).
GERT DORING: Thanks John and Paul for coming up and taking the ball, that was good. I am not sure what Erik is discussing with text report. But if I'm not mistaken, we are coming to the end of the session because we really did not have that much to discuss this time. Handing back the microphone to Erik.
ERIK BAIS: Yes. As we don't have any other requests currently, there we are. Any other business? Jordi.
JORDI PALET: I have done a change on this with reached consensus in other regions. Is in our IPv6 policy point .5.42 assignments shorter than /48 to single end site. I never sent a policy proposal for this specific topic. It was part of working out policy proposal ‑‑ IPv6 policy in other regions, but there is a text which says there is an experience at the present time with the assignment of multiple network prefixes or bigger LAN and so on. I really think this is clearly not true any more and I think this section should be completely removed as we did in other regions. So before sending a formal policy proposal which is what Gert always suggest, what do we think? That's it?
GERT DORING: A quick round of feedback from the room. I see one thumbs up. So indeed, that's a very old sentence, that I don't know, 25 years old and we did not have experience back then, the NCC has more experience today. I see Marco nodding. So this sounds like you have enough support doing forward and this is what it's about.
JORDI PALET: Okay. So you will have a new policy proposal today. I will wait for another week. Don't worry.
ERIK BAIS: Anything else? Gert, any other business?
GERT DORING: No, I'm good. There is still 40 minutes of Connect Working Group so if you want doing. Otherwise, thanks for being here.
ERIK BAIS: Then I would like to thank you all for your input and see you all in Rotterdam.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
