RIPE 73 Address Policy Working Group Minutes

Chairs: Gert Doering, Sander Steffann
Scribe: Antony Gollan

Session I - Wednesday, 26 October 10:00 - 11:30
Session II - Wednesday 26 October 12:00 - 13:30

Session I - Wednesday, 26 October 2016 10:00 - 11:30

A. Administrative Matters

There were no changes to the agenda.

The minutes from RIPE 72 were approved without comment.

C. Current Policy Topics

Marco Schmidt, RIPE NCC

This presentation is available at:
https://ripe73.ripe.net/presentations/97-Current_Policy_Topics-RIPE73.pdf

Alexander Isavnin, The Open Net, asked if the participation statistics Marco had provided in his talk related to people or emails to the mailing list.

Marco replied that this was people.

Steven Nash, Arbor Networks, thanked Marco for the changes they had made to the website and said they were useful.

Daniel Stolpe, Resilians, asked if AFRINIC was nearing IPv4 exhaustion.

Marco said AFRINIC had around 1.5 /8s remaining.

Daniel said RIPE should aim for symmetry when it came to transfers with other RIRs [regarding a potential inter-RIR transfer policy in the AFRINIC region].

Gert noted a comment via remote participation where someone said they could understand why AFRINIC didn't want to open the floodgates.

Marco said he would share this feedback at the AFRINIC meeting in about four weeks.

E. On Mailing List Discussions... (a reminder from the chair)

There were no comments.

F. Discussion of open policy proposals

2015-04, RIPE Resource Transfer Policies

Erik Bais, A2B Internet

This presentation is available at:
https://ripe73.ripe.net/presentations/105-2015-04-RIPE73.pdf

Gert said they were not going to discuss the merits of the proposal – this time was just for questions and answers.

Peter Koch, DENIC, said the general IPv6 policy document looked like it had been globally synchronised and asked if the policy would affect the symmetry or equality of these policies.

Gert said this was an artefact – all of the RIRs had since changed their IPv6 policies in various small ways.

Gert said they would go back through the list to see if there was enough support and ask for more comments.

2016-03, Locking Down the Final /8 Policy

Remco Van Mook

This presentation is available at:
https://ripe73.ripe.net/presentations/112-2016-03-v3.pdf

Elvis Velea, v4Escrow, asked if Remco thought he had addressed any of the newer concerns that had been raised on the mailing list since the impact analysis had been published.

Remco said he felt that they had addressed these issues in the past.

Elvis referred to Remco's point about accusations being made against the RIPE NCC Executive Board. Elvis said new members couldn't understand the concept of different “hats”, so they saw Remco's proposal as coming from the board. He said the RIPE NCC was neutral and suggested that the board should also be neutral.

Remco said that sounded like preventing board members from having any comments or showing initiative. He said the board had zero role in policy development and he had no special means as a board member to push a policy forward. He asked if Elvis was trying to cut him out.

Elvis said that new members who didn't understand how the PDP worked would see Remco's proposal as coming from the board.

Remco said in that case Elvis should clarify this when he was speaking with these new members and encourage them to read up on the PDP.

Sander said the board was just as much a part of the community as anyone else.

Gert said it was important to stress that the board didn't actually decide on policy. He said the Address Policy WG was not member-related and anyone could participate.

Tim Armstrong, speaking as someone representing more than one member, said he disagreed with Elvis and said this looked like a land grab from people who were late to the party.

Benedikt Stockbrand, Stepladder IT Training+Consulting, said the board was volunteer-based while RIPE NCC members were doing this for a job. He therefore welcomed participation from the board in RIPE policy development where there was no conflict of interest.

Elvis said the past couple of years had been crazy with this last bit of addresses. He said that putting together the board's decision to not allow multiple LIRs and then reverting this through a GM vote, along with this policy if it went ahead, would send a clear message that the board recommended that the membership allow the creation of additional LIRs to obtain multiple /22s. He said they were now coming to a point where a board member wanted to tell members that they had to keep multiple LIRs open.

Remco said Elvis was conflating the GM with the PDP. He said the board had tried to tackle this at the GM, only to declare that they thought the only way to solve this issue was through policy.

Nurani said the discussion about the board was a distraction and they should focus on the policy. She thought it was a good effort to put forward the proposal and they should ignore the recent craziness on the mailing list. She agreed with Nick Hilliard's analysis and wasn't sure the proposal had enough support to go ahead. She nevertheless thought it was good to have had the discussion.

Marco Schmidt, RIPE NCC Policy Development Officer, said he wanted to respond to Elvis's earlier comments and make an official statement that Remco as a board member had received the same treatment and support from the RIPE NCC as any other proposer.

Riccardo Gori, Net-IT, said the question was how the policy dealt with a company that was split in half. If he shared space with a downstream he wouldn't be able to give them space and they wouldn't be able to give it back.

Remco said if you were splitting a /22 you were already in trouble. He added that if a business partner wanted to split off they would need to open a new LIR anyway.

Erik Bais, A2B Internet, agreed with Nurani and Nick and said he saw issues with where this would lead. He thought the policy opened a can of worms as they had it currently. The room was divided between new members and those trying to protect against a land-grab. He didn't think the policy would provide a consensus on where they needed to go.

Remco said that in effect they had made a policy change with how they handled the last /8 without the Address Policy WG having any say on it. He said he was dropping the proposal and welcomed anyone else to take it up if they wanted to. He said he was embarrassed by the tone of the previous week's discussion on the mailing list and said the RIPE community had embarrassed itself. He hoped no one would read the archives.

Sander said that what disappointed him about this was that they were trying to reach a consensus but many people had been working to block the proposal rather than find solutions.

2016-04, IPv6 PI Sub-Assignment Clarification

Maximilian Wilhelm

This presentation is available at:
https://ripe73.ripe.net/presentations/103-RIPE73-IPv6-PI-Clarification-v2.pdf

Gert said he wanted a clear statement from the RIPE NCC's Registration Services department on how they interpreted the policy.

Andrea Cima said the policy text was quite specific about the limitations of an assignment – it couldn't be sub-assigned to other organisations. There was a difference between IPv4 and IPv6 PI – there was an exception in IPv4 that was not there in the IPv6 policy text, which was why they interpreted the policy this way. He said Maximilian's issue was shared with many other organisations. This was why the RIPE NCC had raised the issue on at least two previous occasions. He said changing the policy might do a lot of good for users of PI.

Sander summarised by saying that IPv4 PI had been abused and the community hadn't wanted this to happen with IPv6, so had instructed the RIPE NCC that this strict interpretation was what they wanted.

Jordi Palet Martinez, Consulintel, said he was the author of the original IPv6 PI policy and when he wrote it he had been looking at section 2.6 of the policy that said an End User device was not infrastructure. He said the right way was to clarify section 2.6 and not the text in the PI proposal.

Elvis said this wasn't an attempt to fix the problem but rather sweep it under the carpet. They needed to fix the part that banned assignments from /48 PI that multi-homed. He said he understood that they needed baby steps, but they ultimately needed to remove the distinction between PA and PI.

Erik said he had written a lengthy email on the list about this. While he understood Maximilian's troubles, the question was what was an assignment. Using IP space on DHCP or Wi-Fi was not an assignment and in this respect the RIPE NCC's interpretation was too strict. However, if they relaxed this, then most of the IPv6 PI policy was also redundant.

Gert said what he was hearing was that the WG was perfectly fine with the usage that Maximilian needed. He wondered if a policy change was needed or if the RIPE NCC could just interpret what was already written differently. However, he noted that the RIPE NCC had already said that a policy was required.

H. Supermarket Checkouts, Airline Hand-Luggage and Other Trivia

Nick Hilliard

This presentation is available at:
https://ripe73.ripe.net/presentations/99-inex-ripe-apwg-2016-10-26.pdf

Andrew de la Haye, RIPE NCC, said after a discussion with IANA they expected to receive a /19 in March 2017, a /20 in September 2017, and a /23 would be the final allocation in March 2019. He said they expected the current /22 pool to last for another four years. He said this was just for perspective, and it was up to the community to decide what they wanted to do.

Sander added that they would have some LIRs closing in this time period and they needed to decide what to do with these returned addresses, so they did need something.

Geoff Huston, APNIC, said he'd done some modelling and the last /8 would last around 4.5 years at the current burn rate. He said the returned IANA pool would run out long before then. Whatever queue they might have wouldn't be from the issues they had raised here. There was a certain amount of return and recycling going on. The question was whether they wanted to address it now, in four years time, or somewhere in the middle. It didn't seem like this was a burning issue they needed to address right now.

Nick said Geoff was correct but the haste at which people were trying to scramble for the last remains in the IPv4 in the pool showed that they did need to deal with the issue before the crunch phase, even though it was not a burning issue right now.

Elvis said they needed a queue for whatever would be continually returned to the RIPE NCC.

Lu Heng, Outside Heaven, said to a certain extent it should be first come, first served, while taking consideration for some key infrastructure organisations like IXPs.

End of first session.

Session II - Wednesday, 26 October 2016 12:00-13:30

D. Feedback from RIPE NCC Registration Services

Andrea Cima, RIPE NCC

This presentation is available at:
https://ripe73.ripe.net/presentations/102-FeedbackRS-RIPE73_final.pdf

Gert said they would go through the issues Andrea had raised one by one.

Proposal to return unused ASNs to the free pool

Radu-Adrian said in France they used ASNs for interconnection with several external entities that were not visible in the routing table. This should be taken into account as one of the reasonable explanations. He wasn't sure that the people dealing with the checks had this information, so there were a number of cases that should be described quite clearly. He asked if they needed to start compiling a list of these cases.

Gert replied that they didn't need to make a list.

Andrea said this was an example of a reasonable explanation of a good use. He said if the community supported this idea, the RIPE NCC could provide definitions of what they took to be reasonable.

Gert asked if they wanted the RIPE NCC to do this. He said the RIPE NCC would be careful and wouldn't bully people if they were using their ASNs.

Erik Bais asked how much time this would take the RIPE NCC to do.

Andrea said they would have to look at this, but he didn't expect that it would be too onerous, as they would automate as much of this as possible and use email for contact.

Erik suggested they look at addressing this in the ARC.

Andrea said that was reasonable and they could look at adding this in there.

Daniel asked what the current practice was with returned ASNs. He asked if they were reassigned.

Andrea said there were several goals – maintain an accurate registry (i.e. ASNs assigned to organisations that didn't exist anymore shouldn't remain assigned to them). He added ASNs would eventually be reassigned after they were kept in quarantine for a while.

Kenji Shioda, Nebula Online, asked what would happen if the resource holder was unresponsive or there was a misunderstanding.

Andrea said if there was no response from a resource holder and the sponsoring LIR didn't have any information, they would reclaim the resources. However, as the goal was to clean up data rather than reclaim resources, they would return the ASN if someone popped up and said that they were using it. He said they would be flexible and would take a very light approach.

Janos Zsako, RIPE NCC Executive Board, said an ASN might appear in the AS path but was not necessarily originating (as in Andrea's bullet point) so they should clarify that. He supported the effort to clean up the data. As there was no price tag associated with ASNs, there was nothing to incentivise their return. He suggested they prioritise cleaning up 16-bit ASNs first.

Gert said there were no strong objections and suggested the RIPE NCC put together an implementation plan and share that on the mailing list.

Andrea said he would do that.

Organisations with multiple IPv6 allocations

Gert asked if they through this was a problem.

Janos said this wasn't a problem right now but they should keep an eye on it.

Radu-Adrian agreed with Janos that they should keep things the way they were for now. He added that there were a lot of LIRs that still believed you needed to request IPv6 in order to receive a /22 IPv4 allocation – he suggested more education might help to avoid this problem.

Erik said that looking at the numbers, there didn't seem to be a relation with people who were setting up multiple LIRs for extra IPv4 – otherwise there would have been parties with 30 or so /29 IPv6 allocations in there. He agreed they should keep an eye on it but he didn't see a problem at this point.

IPv6 first and additional allocation policy out of sync?

Tahar Schaa, as a consultant speaking on behalf of the German Government, said they had been involved in the policy proposal which changed the initial allocation criteria. Since then they had decided to create a policy proposal to adapt the subsequent allocation criteria as well, as they thought these should be in sync. They wanted to see some support and discussion for this, and also wanted a co-author. He said they planned to start immediately after this meeting.

Enno asked how many applications for larger than a /29 the RIPE NCC had seen and how many of these had been successful.

Marco Schmidt said they had received tens of such applications and none had been rejected. He added that several were currently ongoing, as they required a lot of documentation.

Andrea said the numbers did not seem very high but those were the requests that were very difficult to approve in the past. He said the changes to the policy had really benefitted organisations that were doing large IPv6 deployments.

Carlos Friacas, from the Portuguese National Research Network, agreed that this issue needed to be addressed and volunteered to help develop the policy proposal.

Janos agreed that a policy proposal was a good idea. He asked if the RIPE NCC had been keeping track of what basis the allocations were made on originally. If they did, they could consider allowing the new criteria to be used by people who received an initial allocation under these new criteria.

Andrea replied that all of the large allocations were made with the new criteria.

Janos replied that it therefore made sense to treat these a bit differently.

Tahar said from his perspective the large allocation requests took so long to document and justify that it proved that until now there had been no abuse of this policy – they all took it seriously and were committed to following the policies, and he thought this was a good thing.

Gert said that speaking as an individual, he didn't think they shouldn't make special treatment for additional allocations depending on how the initial allocations were made, as there were allocations going back 15 years and this would make their lives more complicated. He supported modifying the additional allocation policy and thanked Tahar for volunteering a policy and Carlos for offering to help.

Inter-RIR legacy resource transfers

Erik said that all resources, whether they were legacy or not, were listed in the inter-RIR transfer statistics, so people could see where they came from. He said looking at the resources and how they were used, this was well within the parameters of 50% usage within five years – as the majority of transfers would be used within three months. From that perspective the addresses were actually used. He said if they wanted to change this, they would need to change the actual legacy service policy and he had no opinion if this was something they should do. He said this may not be the intent of the transfer locking – he didn't believe this was stockpiling.

Gert asked if legacy holders approached the RIPE NCC for the transfer.

Andrea said they could, but there was no guarantee that they would – legacy holders could update the registration themselves without telling the RIPE NCC. He said the RIPE NCC's only concern was that if an organisation received resources stating that they would use 50% of them and then immediately gave the addresses to others – this seemed inconsistent with the policy.

Sander said that sounded fraudulent.

Andrea said that according to the policy they were allowing legacy holders to do this.

Sander said he didn't think ARIN would be happy if people just started filing faked documents. He said the solution seemed to be to apply all kinds of rules on legacy space – but they had deliberately decided not to do that, so this was a tough one.

Erik said the company getting resources out of the ARIN region needed to provide documents on how it would be used. He said there was nothing preventing you from stating in that plan that you were going to split up a block and give it to other entities to use. He said the biggest issue in the process was dealing with the originating RIR. He said it was a fine line between being honest and lying to the RIPE NCC.

Sander said it seemed to be an education thing – the RIPE NCC could tell people that they didn't need to lie to them about it.

Erik said if you were going to buy a block and break it up, be honest about it – because it would still be in use.

Billy Sylvester, Addrex, said that in all the transfers they had done, they had never seen any evidence of speculation – all of their customers had used all of their addresses. He said RIPE space was some of the best in the world because they didn't have restrictions in their policies. He asked if there was actually a problem or they were chasing a boogeyman. He asked the RIPE NCC to provide details if they thought there was any evidence of people changing their plans once they received addresses.

Andrea said he hadn't been talking about speculation of resources and he wanted to stay away from that. He was simply raising the concern that recipients were providing plans for how they would use resources, and then afterwards the RIPE NCC could see that block being split up into many different pieces.

Gert said it sounded like they just needed to educate people with incoming resources to be honest about what they were doing, even if their intention was to distribute these resources within the RIPE NCC service region. He said this was about being open and not speculating on what people might be doing with their resources.

There were no more questions.

G. Consequences of the End of IPv4

Erik Bais

This presentation is available at:
https://ripe73.ripe.net/presentations/93-AP-WG-Erik-Bais-RIPE73.pdf

Sasha Luck, speaking for himself (via remote participation), said he would support a move to a centralised Policy Working Group. He also noted that there was an IPv6 policy proposal in the Address Policy WG rather than the IPv6 WG.

Radu-Adrian suggested this needed to be discussed in the plenary. He said it could also affect other WGs such as Routing. He thought they had so many different policies that it was easy to got lost. He suggested numbering-related policies should be kept somehow together.

Jim Reid, speaking for himself, complained that Peter would speak next and would disagree with him. He said he was grateful for Erik's presentation. He didn't support taking more of a proactive role on filtering proposals, as this lowered the neutrality of the Chairs. He suggested a policy proposal that stated the WG would not entertain any more proposals about IPv4 allocations. Then they could go back to IPv6, ASNs and housekeeping.

Erik said another option was to use the Discussion Phase to discuss whether there was a consensus that there was actually a problem to be addressed. He thought using the existing PDP in this way could have a similar result.

Jim said they wouldn't get consensus on IPv4 in this WG anymore, so the solution was to stop talking about it.

Peter apologised because he couldn't completely disagree with Jim. He said Erik had found some issues with the PDP in general but not necessarily with this WG. He said Jim's proposal might have political significance and might have some merit, but it would conflict with the PDP, which wouldn't allow you to lock policies. Another argument was that eventually there might be a small loophole or something that needed to be fixed and then they would have problems. He said policy proposals would come from anywhere, but the RIPE Chair could address this if necessary via the PDP.

Erik said you couldn't just do create a new WG. You needed two BoFs, Plenary consensus, etc.

Peter said the threshold was not that high and you didn't necessarily need a Plenary majority. He said a good example of problems with the PDP was the Anti-Abuse WG making decisions that affected everyone which flew under the radar – while following the PDP. He said they had some blunt discussions recently, but this wasn't the end of the world – they didn't need to change their system because of this. He said they didn't need stronger moderation or filters, as the existing structures worked.

Gert suggested they needed to converge on the problem statement before a proposal entered the PDP.

Sander said this was actually how the PDP was intended to work.

Filiz Yilmaz, Akamai Technologies, thanked Erik for raising the topic and said it was worth looking again at their procedures as the community evolved. She said there was merit in creating smaller WGs which were deep divers with specific interests. A broader WG lost some of that expertise and was diluted. She suggested they introduce more cooperation with the other WGs to discuss which WG a policy proposal belonged in, and making announcements regarding which WG a proposal would be discussed in.

Marco Hogewoning, speaking as someone in the RIPE NCC's External Relations Department, said he had been at the IETF when they had this discussion. He said there were external entities who were watching the RIPE community closely, and if this group stated that it might stop working with IPv4, there might be other international entities who may want to fill that gap. He encouraged the community to take a step back and consider how this might appear to external parties unfamiliar with the workings of the WG.

Benedikt said both Jim and Peter were right in a way. He said they should be careful, as the IETF had really screwed up with its statement. They should focus on not prolonging the misery of IPv4 – the WG should focus on moving to IPv6 as soon as possible and not worry about the perceived needs of the IPv4 diehards.

Erik said there was a phrase in consultancy: “If you're not part of the solution, there's a lot of money to be made in prolonging the problem.”

Janos thanked Erik for his presentation. He said it would be a bad idea to decide not to talk about IPv4 in this WG – because that would be against the intention of the last /8 policy, which aimed to save this for people. As Peter mentioned, there might be an unexpected loophole that could deplete the IPv4 pool in days, for example. But he agreed they should definitely focus on the future and not on dealing with the last /8.

Radu-Adrian asked if they needed to revise the PDP itself. At the moment you needed to submit a proposal to start a discussion phase. He said maybe there should be an approach of: problem definition – then discussion – then proposal.

Gert said they didn't need to change the PDP to achieve this. If someone needed a formal proposal number, they had to send the proposal to the RIPE NCC. However, there was no requirement to start the conversation – they could send something initially to the list. This was in line with the PDP and was a more lightweight approach. What he was taking from this discussion was that they should be a bit more lightweight and try this approach to see how it went.

Nurani said it was valuable having an avenue to discuss IPv4, even if there was nothing to discuss. Having an Address Policy WG that was only one slot and only took 30 minutes wouldn't be a bad thing. She said they shouldn't overplay the turbulent discussion on the mailing list recently – the WG could still have constructive discussions.

Daniel said in the Database WG you were not allowed to enter a proposal until it was agreed that there was a problem. He suggested they follow this approach as it would save a lot of time.

End of second session.