You're viewing an archived page. It is no longer being updated.
RIPE Meeting |
RIPE 78 |
Working Group |
Address Policy |
Status |
Draft |
Chairs: Gert Doering, Erik Bais
Scribe: Antony Gollan
Erik Bais welcomed attendees and said there were some adjustments to the agenda – they had a new proposal that had been pushed to the front, because it overlapped with the Connect WG. Before that, they would give Hans Petter some time.
The scribe was thanked and the minutes from RIPE 77 were adopted without comment.
- Erik Bais/Hans Petter Holen
Gert Doering was re-selected as WG co-chair.
Hans Petter Holen, RIPE Chair, spoke for a few moments on the RIPE Chair selection procedure. This had now been created and he hoped that they would reach consensus on it at the meeting. He asked people to review the document and share their opinion, so there could be a clear consensus.
- Remco van Mook
This presentation is available here:
https://ripe78.ripe.net/presentations/76-revised-ixp-assignments.pdf
Gert said the WG had discussed the routability of exchange networks two meetings ago and had been warned not to make assumptions about this. He asked what kind of assignment a small IXP would get if it had ten members and wanted to be globally recognisable.
Remco said the default remained a /24. The smaller /27 size mentioned in the proposal was really about doing something with the scraps that were left over – these would only be assigned if an IXP requested it or if they were all that was left.
Wolfgang Tremmel, DE-CIX, asked if there was any text that allowed for growth. If an IXP outgrew its assignment, could it return it and get a larger one?
Remco said it followed the current policy in this respect. If an IXP outgrew its /24, it returned this and received a /23. However, the option to grow into a /22 was dropped in the new policy.
Wolfgang said he liked everything except for the fact that an IXP could not grow beyond a /23.
Remco said that was not surprising, given that Wolfgang was from of the only exchanges on the planet with more than a /22.
- Marco Schmidt, Policy Development Officer, RIPE NCC
This presentation is available here:
https://ripe78.ripe.net/wp-content/uploads/presentations/71-RIPE78-Current-Policy-Topics.pdf
Hervé Clément, Orange, thanked Marco for his presentation. He tried to keep track of policy discussions in the different regions and a thematic overview like this was very helpful.
- Nikolas Pediaditis, RIPE NCC
This presentation is available here:
https://ripe78.ripe.net/presentations/72-RS-Feedback_Final.pdf
Gert said he thought the way they had been dealing with /12s was good, because their previous allocation had lasted 20 years, which reduced the RIPE NCC’s overhead in terms of making sure they didn’t have to keep going back to IANA every couple of months for a new allocation. The issue of IPv6 /32s being stockpiled was interesting – it might be worth looking at but the numbers did not seem dramatic.
Erik asked if the RIPE NCC expected the stockpiling of IPv6 to continue once they had run out of IPv4 addresses.
Nikolas said they anticipated a big reduction in multiple LIRs after IPv4 run-out, as the incentive to create them would be gone.
Erik asked if they saw a need to fix this through a policy, assuming that it would take around four months to get a policy done, maybe the issue would be fixed by then anyway.
Randy Bush, IIJ, said he didn’t understand the motivations or expected results of the actors. He thought as a community they should be more concerned with accuracy of the database – this had to be their first principle. Beyond that, stockpiling IPv6 was like stockpiling air and he didn’t think they needed to worry about it yet.
Nikolas said they had wanted to present this to the WG so it could consider if this might affect the registry or if it meant they would have a problem in the future.
Gert wondered if they should hand this back to the RIPE NCC. In cases where they saw something weird, they could have a friendly chat with people to find out what they were doing and whether there was something broken with the policies that made them feel the need to, for example, get a /29 and announce /32s from ASNs that are totally unrelated to them.
Jordi Palet Martinez, The IPv6 Company, agreed that multiple LIRs would be less of an issue once they ran-out of IPv4. However, he wondered if they should consider asking for some kind of justification for organisations that wanted multiple LIR accounts. He asked if they should also consider a justification for IPv6 transfers.
Sander Steffann, Global NOG Alliance, said he had an example where he had given a sub-allocation to a small non-profit with zero budget. They had a /32 sub-allocation from him, which was one way this could occur.
Randy asked what AS they were announcing it from.
Gert said if this was all well documented in the RIPE Database, then this sounded like a good plan to him.
Sander replied they were using their own AS.
Randy asked why Nikolas thought these allocations were unrelated. He asked whether they had they looked at things like their AS-path or their customers.
Nikolas clarified that they had only looked from a registration point of view and were aware that reality could be more complicated than this.
Gert, replying to Jordi’s point, said the issue of multiple LIRs had been debated by the membership. The reason they were permitted was for the accuracy of the registry, because people could just open up other legal entities to get around any restrictions. Allowing multiple LIRs had therefore been a conscious decision. The idea was not to create rules that couldn’t be enforced.
Hans Petter Holen, RIPE Chair, said they had touched on something that was close to his heart, which was the border between RIPE policy and RIPE NCC rules. The RIPE community had made a policy to restrict something while the RIPE NCC then made mechanisms that made it easy to circumvent the policy. This was just food for thought for the community – how to draw this line and unify these two processes. Charging for PI resources was another feature of these things. Long term, they should look at a complete separation between the policy process and the commercial processes of the RIPE NCC and shouldn’t mix them. This wasn’t something they could solve there, but rather something to think about over the long term.
End of first session.
- Sander Steffann
[There were no slides for this presentation.]
Erik said one thing that was overlapping between his policy and the IXP policy that Remco had proposed was the issue of IPv4 “dust”. He had asked the RIPE NCC to provide insight into how much IPv4 dust they were talking about. He said Sander’s position was that if they had a piece smaller than a /24, they should put it aside until the remaining parts became available, which could take a very long time. However, it could be useful to simply put all of this into the IXP pool and hand it out for smaller IXPs. He knew there were /29s and /27s out there, he knew of some which had been transferred from an LIR to their customer (after being created by the LIR).
Sander said they could simply remove this part from his proposal so it would be compatible with the IXP Pool proposal.
Peter Koch, DENIC, said he was concerned by the idea of a “first-come, first-served” waiting list – you either had first-come, first-served or you had a waiting list. This was a regulatory principle. He thought the legal impact analysis might allow them to get a more academic or regulatory insight into the balance between different possible approaches. This would be just as a protection for any challenges that the policy might receive in the future.
Sander said they had intentionally decided not to micromanage the RIPE NCC. They would definitely take any concerns the RIPE NCC had (legal or otherwise) into account.
Peter clarified that he wasn’t talking about micromanaging the RIPE NCC. Usually they didn’t call on external experts to assess the regulatory part of what they did. They would be at a very interesting point in time when the policy was executed and he was just asking for a kind of safety-belt for this.
Marco Schmidt said they’d looked at this from a legal perspective in their impact analysis and didn’t see any concerns. “First-come, first-served” made sense from their perspective, and it was good that this was explicitly named in the policy.
Peter said first-come, first-served could be interpreted in a number of ways when you had no resources to allocate. He wasn’t saying their interpretation was particularly wrong, but they were making a decision and it would be worth understanding some of the theory behind it, which he didn’t.
Marco said he just wanted to comment on the potential for conflict between the two policies proposals on the issue of IPv4 dust. He suggested they finish this proposal before the IXP pool proposal reached consensus to avoid problems later.
Randy said on the routing implications for IPv4 dust – he thought they would eventually go there. This had implications for what they were going to give out. Proposing to give out dust today before something more formal had caused the routing system to change was not kind.
Sander clarified that this policy said dust could not be allocated - only the IXP proposal allowed this.
Randy asked if they could have this part of the discussion in the Routing WG.
Erik clarified that the IXP proposal said you could get a /24, but smaller assignments could be given out – but only if requested by the IXP.
Randy reiterated that the Routing WG should discuss this.
Owen DeLong, Great Home Technologies, said a system where people were not able to register for a waiting list until the RIPE NCC had addresses was problematic – it turned the registration process into a lottery where people would try to time their request for when new addresses became available. This made things unpredictable and created haves and have-nots through pure dumb luck. He thought a queue was a better approach.
- Rüdiger Volk
You can find this presentation here:
https://ripe78.ripe.net/presentations/78-trouble-with-NRO-data.pdf
Erik said he’d had a small discussion with David about this. In the case of inter-RIR transfers, things changed as allocations that were removed in the RIPE region and popped up in another region a few days apart. Normally it took one business day to move from one region to another. You needed people in the office to do this, as it was a manual process, so there was only four days where transfers were actually being processed.
Rüdiger Volk, Deutsche Telekom, said how transfers were processed and reflected in the data should be documented. If this said that there may be two days of overlap with something, the user of the data might be able to deal with it.
Randy asked how much of the checks could be automated.
Rüdiger said he was pretty sure they could be automated. What he observed was that the RIR information that was used to produce the report appeared to be different for each RIR, and the process of changing data structures/files in the RIRs seemed to not be coordinated with the process of producing the Delegated Extended report. If the NRO took this up, he would like to see an explanation of the sanity checks they were applying to the results.
Randy suggested they could help the NRO to automate these checks on a regular basis and publish this in the way they published Philip Smith’s route aggregation report every week. The point wasn’t to name and shame, but to indicate issues with the data and to help the NRO get a handle on these issues.
Rüdiger said what they had on Monday was a format issue with several of the columns containing garbage. This was something that never should have been moved to publication by the NRO – it should have been checked before it was published.
Paul Wilson, APNIC, said he would only talk for APNIC and there were other RIR CEOs who could talk. He was surprised and alarmed by what Rüdiger was saying. He hadn’t been aware of this level of inconsistency and would have taken actions to fix what was broken. There were a number of consistency checks that were done at APNIC and for years they had been checking between their stats and their registry. Obviously, they had been doing this badly. He was very interested in fixing this and apparently they could use some help. As for converging on what all the RIRs did – they had five fiercely independent communities and organisations here, and he didn’t know how much appetite there was to change all of their legacy systems to magically converge on something that worked without error – so this was easier said than done. But he did think these consistency checks and documentation that Rüdiger was talking about were important and could be implemented. He said the RIRs took their global coordination responsibilities seriously and he really was surprised to hear about this and wanted to know more.
Rüdiger said how they were operating was not very transparent to him and there were many things that he would not care to know. His suspicion was that the activities of the RIRs were focused on the other side of maintaining this data (registries/RDAP). While this had been done some time in the past, he would guess that none of the RIRs had defined resources for caring about the stats end of their business. They would need to define that and how it would work within the NRO.
John Curran, ARIN, said this wasn’t unknown problem. The RIRs had coordination groups that spanned various departments such as the Registration Coordination Group and the Engineering Coordination Group, that looked at these issues. When they were alerted to these issues, they were addressed. What John noticed was that there was no clear way for him to report an issue, which was something that needed to be fixed.
Rüdiger said he did want to admit that he hadn’t formally reported any of the issues he had been talking about.
John said they should have a clear contact for these issues and a documented format. He said this should be monitored, not only by the RIRs but by outside. Nothing apart from this kind of visibility will instill such a focus on accuracy. This was a case where it was good to do the cross-checking and publication, if for no other reason than to alert others who may be using the data for something. He suggested Rüdiger’s Weekly Delegated Stats Report.
Rüdiger said they needed to first install quality assurance. The community should be able to expect the NRO to put out data, at least the format of which was alright. He didn’t have a problem if small mistakes happened, they were all human. But they should really set the goal that what they published was reliable and could be used in an operational environment.
Jordi said he had done a change on something had reached consensus in other regions in the IPv6 policy regarding assignments shorter than a /48 to a single End Site. He had never sent a proposal for this specific topic, but it was part of other changes. He really thought this section of the policy should be completely removed in the RIPE region, as in the other regions. Before creating a policy proposal, he wanted to know what people thought.
Gert said this was a very old piece of policy text from when where they didn’t have so much experience. Gert said he saw a thumbs up from Marco and some nodding in the room, which indicated that there was support to go ahead.
Jordi said he would start work on another proposal immediately.
End of second session.