RIPE 72 Address Policy Working Group Minutes

Chairs: Gert Doering, Sander Steffann
Scribe: Antony Gollan

Session I - Wednesday, 25 May 2016 09:00 - 10:30
Session II - Wednesday, 25 May 2016 11:00 - 12:30

Session I - Wednesday, 25 May 2016 09:00 - 10:30

A. Administrative Matters

Gert Doering welcomed attendees and said that even though they didn't have IPv4, they would be discussing IPv4 as the IPv6 and ASN policies seemed to be working fine. He ran through the agenda and the minutes from RIPE 71 were approved without comment.

B. WG Chair Selection

This presentation is available at:
https://ripe72.ripe.net/presentations/85-wg.pdf

Gert said they used consensus rather than elections to select WG Chairs. It was Sander's turn to step down and he wanted to stand again for another term. There were 21 statements of support for Sander and no one else had volunteered.

Randy Bush, IIJ, said they had made them go through months of BS on the mailing list about this process and they were ending up the same as before. He said of course he supported Sander, but this wasn't the IETF and they didn't need to wrap endless process around everything.

Gert said there was a reason for the process: it allowed the Chair to think about whether they even wanted this position.

Sander added that it was also nice to have a statement of support from the community.

Randy asked if they were all going through this to save Sander the cost of a session with a psychiatrist.

Brian Nisbet, HEAnet, said the process gave people an opportunity to put themselves forward and while they had wasted a lot of time on it, it was good to have the process in place.

Peter Koch, DENIC, agreed with the process but said they should take it seriously by encouraging other people to stand for selection in the future. He said he wasn't saying they should aim for as much change as possible, but with the Chair standing on the stage perhaps it was a bit harder for other people to volunteer than it could be.

Gert said he hadn't seen any comments against Sander or from people who wanted to stand, only comments against the process, so he declared that Sander was renewed for another term as Chair.

C. Current Policy Topics

Marco Schmidt, RIPE NCC Policy Development Officer

This presentation is available at:
https://ripe72.ripe.net/presentations/96-Current_Policy_Topics-RIPE72.pdf

Randy asked for an official confirmation that if ARIN fixed its outbound ASN transfer policy, the RIPE NCC would accept ASN transfers from the region.

Marco confirmed that they would. He said RIPE Policies stated that as soon as there was a compatible transfer policy in another service region, the RIPE NCC would be able to transfer resources with them.

Tahar Schaa, consulting for the German Government, asked about the LACNIC proposals that had changed the criteria for an initial IPv6 allocation. He asked if Marco was aware that they referenced the change in the RIPE region.

Marco said that this wasn't specifically mentioned but the proposer was also active in the RIPE NCC service region and it was clear from the text that there was a relation.

F. Discussion of Open Policy Proposals

2015-04, RIPE Resource Transfer Policies

Erik Bais

This presentation is available at:
https://ripe72.ripe.net/presentations/83-2015-04-RIPE72.pdf

Remco van Mook said he was willing to drop his opposition to the proposal, though he added that it was still important to clear up all the IPv4 policies. He said he would also repeat this on the mailing list as this was where he needed to say it.

Elvis Velea, v4Escrow, said that even though Remco was withdrawing his opposition, he was concerned that adding the mergers and acquisitions process into the transfer policy was bringing a RIPE NCC internal procedure into policy.

Erik said they weren't talking about the actual mergers and acquisitions procedure – the only thing the document said was that changes in resource holdership would trigger a holding period. He said this had to do with abusive behaviour around the mergers and acquisitions process. If they assumed that the majority of the people in the room had good intent, they needed to have a policy that allowed as little abusive behaviour as possible. Having this in the document would fix this by saying that once a change took place, whether an allocation from the RIPE NCC or a merger and acquisition, a holding period was triggered. He said this was about making it fair.

Elvis said this was a major change and needed to be highlighted.

Erik disagreed that it was a major change but added that it had been clear in the policy from day one and it wasn't hidden in there. He said if a company bought another and merged, and was required to keep an LIR open for six months longer than it normally would, then this was just the cost of doing business. He asked if Elvis had a specific objection.

Elvis said he could see various reasons why this would create problems and so he was opposing it.

Peter Koch, DENIC, said Remco was not alone in his objections and he hadn't seen a reply to those. He said there were updates required for a number of documents where everything was time stamped and looked current but had outdated references. He said he hadn't seen a solution to how this would be handled – if they moved to a new document they would need to clean these up. He said there was more work needed than just changing a bit of text and giving it a new timestamp.

Sander said they would work with the RIPE NCC to update any references and agreed that it would be bad to publish old stuff in an updated document.

2015-05 v2, Revision of Last /8 Allocation Criteria

Riccardo Gori

This presentation is available at:
https://ripe72.ripe.net/presentations/106-2015-05v2-RIPE72-minutes-summary.pdf

Before the presentation, Gert said that this proposal had divided the mailing list between those who thought that IPv4 should be preserved for LIRs in a few years time and those who said that LIRs were hurting now and needed resources for their operations. He said there didn't seem to be any way to reach a consensus. After Riccardo's presentation he said they would have a brief Q&A followed by Remco's proposal from the opposite point of view and then they would have a general discussion on the way forward for both proposals.

Erik thanked Riccardo for the work he had done and said it was definitely an interesting exercise.

2016-03 Locking Down the Last /8

Remco van Mook

This presentation is available at:
https://ripe72.ripe.net/presentations/98-ripe72-ap-2016-03.pdf

Elvis said there was a bug in the proposal. He said Remco didn't want it to work retroactively but if someone already had two /22s from the last /8 and wanted to receive an IPv4 transfer in the future, they would have to return all but one of them.

Remco said this was a feature and not a bug.

Erik asked how Remco envisioned the new status working – he saw that there was an “ALLOCATED-FINAL” status that would be added to the long list of statuses that already existed. He asked what Remco thought about another status that was unique to the RIPE region and whether there would be any impact on legacy space.

Remco said he had talked with the RIPE NCC and couldn't see how this would affect legacy. He said the status was important as you needed to identify the resources as non-transferrable.

Riccardo said he opposed the proposal because it highlighted the difference between new and old LIRs. He said if he bought a company, the address space might be in use and it could affect the company.

Remco said he had addressed this in one of his slides – the /22 was there for IPv6 compatibility. If people were using IPv4 to assign to their customers, this wasn't sustainable.

Riccardo said this ignored the reality in many countries, such as where there was only IPv4 and CGNAT and there were issues that some LIRs couldn't deploy IPv6.

Hans Petter Holen, Visma, said his organisation had acquired many new companies recently and he wanted to know what restriction this placed on the address space when a company was acquired.

Remco said this proposal only affected /22s allocated from the last /8.

Hans Petter asked what would happen if they acquired three companies with /22s.

Remco said he either merged the LIRs and returned two, or he kept the three separate LIRs.

Elvis said he liked how they had different hats where they did one thing and used another hat for something else. He said with one hat they said return all the /22s unless they kept the LIRs open and with the other hat they said they used to have the idea that blocking the creation of multiple LIRs would fix something but now they were asking the membership to allow this. So they were basically saying that you were allowed to get as many /22s as they wanted, as long as they kept one LIR open for each.

Remco said he wasn't sure if this was a question for this session or the GM.

Alex Le Heux, Rakuten, said they'd done around 150 acquisitions over the last few years and were doing many various levels of mergers and acquisitions but some of these companies didn't exist anymore or their names had changed and he couldn't easily change their names, and asked how they planned to address this.

Remco said this was an issue to take up with the RIPE NCC and if they couldn't help him the Executive Board would like to hear about it.

Gert said they had two competing proposals on the table and they needed to decide on the way forward. They could say on the one hand that they were conservative and they would do nothing, or they could go on the other side and add more restrictions. Or they could decide they wanted to help newcomers today at the cost of new entrants in a few years' time. He said Riccardo's proposal focused on new LIRs, but IPv6 deployment was dependent on larger LIRs that already had enough IPv4 to last them. He said another idea was to restrict /22s to genuine new entrants. He said the topic of reclaiming IPv4 from big old LIRs also came up frequently.

Benedikt Stockebrand, Stepladder IT Training+Consulting, said the original intent of the last /8 was for transitions to IPv6 and this was often forgotten. He said people couldn't use the last /8 for other reasons and then say they needed more addresses. He said they shouldn't cater to these people.

Gert said maybe they needed to do more outreach to remind people.

Anna Wilson, HEAnet, said if they tried to use the RIPE Database to as a means to police how people used IP addresses, they often ended up with a less accurate database. She said an accurate database would always be her first priority. Her second priority was making the final /8 last.

Radu-Adrian said there was big business to be done with IPv4, which was selling connectivity over IPv4 – not IPv6 which didn't sell. He said the current policy didn't state that they should use the /8 as a means of migration to IPv6.

Sander said when the policy was made they had consciously decided not to restrict how people used it and had said if people wanted to use it in a silly way, then that was their own problem.

Radu-Adrian said they were not in such a restrained situation. They had almost one /8 left and if they went to a proposal like Remco's they would lock out about 1.6 /8s, which was huge. They already had the most restrictive IPv4 policies and they wanted to make it even more restrictive. He added that ARIN had not run out.

Sander said that they were using one /8 per month in 2012 until they ran out – so this really wasn't much.

Erik said Radu-Adrian was wrong with his data. He said the intent of the policy was very clear. He said a /8 might seem like a lot, but it wasn't – if they allowed the people in the room to receive the addresses they needed they would be out before the coffee break. He said the /8 was for new entrants, not for current businesses that already some addresses (however small). He said there were brokers if people needed more. Turning back to the proposals, he said Remco's proposal had interesting topics but he didn't think it would reach a workable solution. He said that from various reactions in the room, there were likely things that might be unworkable in the proposal and he didn't think that it would gain enough momentum to get there. He said 2015-05 also wasn't an option. He said another option was to give it back to IANA. Another option was to keep things as they were, because they needed to provide for the people who would have a start-up in three years time and would need addresses. He said they weren't there with IPv6 yet and they needed to provide for the future.

The WG applauded Erik's remarks.

Elvis said he worked with Radu-Adrian on the first version of the proposal and he'd withdrawn when he knew it wouldn't reach consensus. He said he didn't agree with Remco's proposal which had some things that were really weird and impossible to be checked by the RIPE NCC. He said the board asking them to allow multiple LIRs per company would only work if they kept things the way they were – in which case they would run out in a year or so, because they were already seeing people who had registered dozens of LIRs last year coming back to register hundreds.

Gert said that since Elvis had brought up the topic, this was touching on RIPE Database accuracy. He said the reason the Executive Board had raised the issue was that people could just set up shell companies with fake names to get additional allocations which degraded the accuracy of the database.

Nurani Nimpuno, Netnod, said she agreed with previous statements and said they needed to be a bit more careful when talking about “restrictive” or “loose” policies – they had run out of addresses. At this point they were giving people addresses to move to IPv6 and they needed to do more to help with that. She agreed with Erik's proposal, but said she was starting to lean towards Remco's proposal. She said it was about how to manage things in a responsible, workable and accurate way, not about how generous they wanted to be.

Jim Reid, representing himself, said he thought both authors should withdraw both proposals as the WG wouldn't reach consensus. He said they should take a break and come back when they had calmed down. He said at this stage, all they could do was to make small tweaks to the policy to clarify things. He didn't want to go much further than that, and didn't want to create limits on what an LIR could or couldn't do with the address space it had received.

Randy Bush said he thought he was entitled to comment on the original intent of the last /8 policy, as he had originally proposed it. He said it wasn't to promote IPv6 – though this was good – the policy was strictly to allow new entrants to ENTER the Internet. He said the problem was that they were doing big proposals that tried to fix ten things at the same time. Any proposal that tried to fix the fact that they were out of IPv4 was a fantasy. A proposal that tried to change human behaviour was a fantasy. They had a problem with phony LIRs and maybe this was something they could address. He said that getting into the details of a merger between two companies was a bad idea.

Sander summarised by saying the WG seemed to be leaning towards Remco's proposal but saw too many problems with it. The WG also seemed to feel that they should encourage IPv6 but not put anything in the policy – as it was the LIR's decision what they want to do with their addresses.

End of first session.

Session II - Wednesday, 25 May 2016 11:00 - 12:30

G. Market Concentration in the Transfer of IPv4 Space

Alain Durand and Gabe Fried

This presentation is available at:
https://ripe72.ripe.net/presentations/102-IPv4-Transfers-Indicators-RIPE72.pdf

Sandra Brown, IPv4 Market Group, referred to an earlier slide and asked if this showed that in the RIPE region, where there was no needs justification, the percentage of addresses transferred to the top ten recipients was less concentrated than in other regions with needs justification.

Alain said that he thought there was needs justification in the RIPE region. He said he would let the people from the RIPE NCC comment on this. He added that their data showed recorded transfers as reported by the RIPE NCC.

Andrea Cima, RIPE NCC, confirmed that there was no needs justification for transfers within the RIPE NCC service region.

Sandra said these graphs indicated to her that needs justification in the other regions was not having the effect of preventing hoarding of address space. The hoarding was more concentrated in the regions with needs justification.

Alain said he was merely bringing the data to the various policy development bodies so they could draw their own conclusions and he did not want to draw any conclusions himself.

Randy said Alain had showed the amount of address space held by the top ten holders and concluded that no one holder held an unusual amount of address space. But he didn't see that conclusion from what was shown.

Niall O'Reilly, UCD Maurice Kennedy Research Centre, asked what the obstacle was for the RIPE NCC to report on legacy transfers.

Andrea said this was not in the legacy policy and the RIPE NCC was not part of the process for transfers between a legacy holder and another organisation and so it was difficult to gather statistics about this.

Erik said the RIPE NCC was involved in legacy transfers, because to update the RIPE Registry, legacy holders had to supply a transfer agreement to the RIPE NCC. He said this was because legacy holders couldn't delete the top level inetnum to split it up and needed to file a ticket. He said legacy transfers were therefore known to the RIPE NCC and asked why they couldn't use this information.

Andrea said this was partially correct. For some legacy transfers the RIPE NCC was involved, where the legacy holder contact them and notified them because they wanted the RIPE NCC to update their internal files. However, if legacy holders just wanted to change the registration data within an inetnum in the RIPE Database, they could do this themselves and didn't need to notify the RIPE NCC. He said Erik was correct that they had a part of the data but they didn't have the whole picture.

Sander summarised by saying that if the whole block was transferred they could just update the information in the RIPE Database but if they wanted to split it up they needed some paperwork.

Erik said that even for the update of the internal registry you needed to provide documentation to the RIPE NCC to provide chain of custody – so if someone wanted to prove that they owned the block, they would need to update their information with the RIPE NCC.

Andrea said that not everyone did this and there was no obligation for the legacy holder to inform the RIPE NCC.

Carlos Martinez, LACNIC, said he was there as a representative of the Engineering Coordination Group for the RIRs. He said they were in the process of standardising the way that transfers would be reported in terms of which fields the RIRs would be publishing. There were some policy requirements that were different, but overall this would provide a lot more clarity and the data would be more analyst friendly. He said transfers were relatively new so this was to be expected, and while LACNIC didn't provide statistics yet, they planned to use the same fields.

Alain said any efforts to make reporting more transparent would be appreciated by those who were using the data.

Geoff Huston, APNIC, said the community should direct their RIRs to provide the type of information they needed to make policy decisions, not the other way around. He said APNIC had tried hard to record as much of these transactions as it could, and he encouraged them to look at this and what the RIPE NCC was recording and to be clear on what helped them when making policies.

Randy Bush noted that in the RIPE region there was a separation between Address Policy and RIPE NCC services.

Gert said that when he looked at the table on the slide showing available transfer data, the RIPE region wasn't doing so badly.

Geoff said he'd worked with the RIPE NCC's data and it was okay – the dates were a problem, the JSON format was interesting and the country information was a bit dull and hard to extract. He encouraged them to fill in the missing fields and see if they could find some more.

Alain encouraged them to look at the previous registration date. He said this was something that was very useful in one of his graphs as they could see how old address blocks were before they were transferred.

Milton Mueller, Georgia Tech (in the ARIN region), said he'd done some studies of IPv4 transfer markets several years ago and when they were talking about concentration, Alain and Gabe's research was taking an economic concept and then doing a lot of technical measurements. He wasn't sure if they were identifying what concentration meant and what its relevance was. He asked why the top ten transfer recipients measurement was relevant.

Alain said they'd found interesting things like the majority of addresses had been going to large service providers under the allocation model and under the transfer model this had since shifted to large cloud providers. He said he would be willing to work with Milton on the economic aspects of this.

Milton said price was also an important factor. He said he had been the first to propose that the RIPE NCC collect transfer data a few years ago but had been informed that price couldn't be included as a data point.

Alain said Milton was correct that the price was missing. Also missing were the private contracts that were happening as options. He said there was no way to size this option derivatives market.

Elvis Velea referred to the slide regarding how old ARIN transfers were and asked if he could get this for the other RIRs. He asked if he could do this for APNIC, as they provided this data.

Alain said this was transfers from ARIN to APNIC, but this was the only place where he had the data to do this.

Elvis asked what they could do to require the RIRs to fill in the missing dots on the last chart.

Gert said he would ask the RIPE NCC to provide the missing fields. He said this information was already in the stats file, so they wouldn't be leaking any information if they included country of origination and registration and previous registration date.

Andrea said they had this data and it wasn't available in the transfer stats, but it was in the delegated files on their website. He said the transfer stats were required by policy, though he added that the policy didn't say that they couldn't publish additional statistics. He said that as part of their process to harmonise transfer data with the RIRs they would be looking at what they could provide.

Sander asked Andrea to report back to the WG if there was anything they thought they would need a policy for.

Carlos noted that even though the RIRs were working to harmonise this information, analysts should be prepared for policy differences between the regions which could limit some of the information that was provided.

D. Feedback from RIPE NCC Registration Services

Andrea Cima, RIPE NCC

This presentation is available at:
https://ripe72.ripe.net/presentations/112-FeedbackRS-RIPE72_final.pdf

Andrea asked for feedback on the issue of “ALLOCATED-UNSPECIFIED” / “ALLOCATED-PI” address blocks.

Elvis said that PI was PI – regardless of whether it was assigned by the RIPE NCC or assigned by an LIR – it had always been PI. He said now that the community had changed the policy and required that there be a contracts in place, he believed that this should happen. He said customers with assigned PI should have the same liberty to move between LIRs with their assigned PI.

Enno Rey, ERNW, said he represented an LIR that joined two years ago and held some large UNSPECIFIED/PI blocks from the 90s. He said he'd reached out to the other LIRs who held the covering aggregate and no one knew how to deal with the situation. He said they couldn't do anything with these blocks until this was sorted out and he would be grateful if this could be resolved. He said that maintaining the status quo would be the worst option.

Daniel Stolpe, Resilians, said that as one of the LIRs involved, the status they had today didn't mean much as they didn't have any status when they were first assigned and this could easily be changed. He thought it was best to look for a solution for each LIR on a case by case basis.

Gert said he thought that 2007-01 (“Direct Internet Resource Assignments to End Users from the RIPE NCC”) applied to these PI blocks, so the policy said where they should go. However, he said he could see the problem with contacting thousands of resource holders with no formal contract for their resources and outdated contact data. He said he wasn't sure what to ask the RIPE NCC for: for registry accuracy it would be desirable to clarify the status of every inetnum and make sure it was real PI with a contract or put it back into the LIR and convert it to PA. He said it was complicated because no contracts existed.

Sander said the main goal was to keep the RIPE Database accurate, so this was what they should focus on wherever possible.

Erik said that to give an indication on the “huge” amount of the work that needed to be done – he said they were talking about 22 entries in the database.

Andrea said they were talking about 68 allocated blocks. He said the issue was what lay beneath them. He said when they looked at 915 related PI assignments, they were talking about 915 potential networks that could be impacted by this. There might be disagreements between the LIR holding the allocation and the organisation that had the space below this. He said the question was really who the actual holder of the address space was – whether this was the LIR that held the allocation or the PI holder that was using the addresses.

Erik said they'd had this question coming up at the last RIPE Meeting. He said he saw the difference in the numbers, but the majority of these companies were LIRs, and as the RIPE NCC they needed to address them first so they could sort it out with their customers.

Andrea said that what Erik was suggesting was likely a good way to handle this – to let people discuss the issue with their customers and report back to the RIPE NCC.

Erik asked if this came up with the ARCs and if not, wasn't this the point of the audits.

Andrea said that they didn't ask these questions in the ARCs. Regarding these address blocks, he said it wasn't clear that there was a mandate for the RIPE NCC to take action on them. Even in the room were differing opinions on the matter. He said if the RIPE NCC contacted them and said they would take action, all hell would break loose, as there was a complicated history. He said that was why they had raised the topic – so the community could tell the RIPE NCC how they wanted it handled.

Erik said the RIPE NCC's mandate was registry data and if they asked the room then they would say this definitely fell within their scope of work.

Andrea said the main question here was who was the holder of the address space.

Gert said the mandate from the community on RIPE Database accuracy was definitely given. There was no clear mandate on how the status field in the database should be changed, but this wasn't needed. He said he thought the RIPE NCC should contact the LIRs in question and ask them to provide the updated documentation, which put the onus on them. If they claimed it wasn't real PI, then they would need to provide documentation. If they said it was PI, then they would need to comply with the rules for PI and provide contracts. He said it would take a long time and these LIRs might not be happy with this, but they were responsible for maintaining the RIPE Database entries.

Anna Wilson, HEAnet, said her employer held one of the ALLOCATED UNSPECIFIED blocks but mercifully it was clean and they knew the way forward. She said she was one of the people who kept banging the drum about RIPE Database accuracy and when it came to RIPE community policy, she fully supported that. However, as a RIPE NCC member that had to pay for this, it couldn't be a blank cheque. Before moving ahead, she wanted to be clear on the problem they were solving and if it was worth the money they would be spending on it.

Andrea said the problem was that there were concerns from organisations that were not free to move their PI assignments and use them in a way that was consistent with PI and they needed to decide how to handle these cases. The problem was figuring out who was the legitimate holder of these resources.

Ana suggested the question could be less about what the RIPE NCC had to do to clean up the data and more about a policy change that allowed people to do what they wanted to with these addresses.

Andrea said it could be a policy change or an action from the RIPE community on how they wanted the RIPE NCC to act in these cases.

Enno said they had these complex situations for historical reasons. In cases where both parties could agree, he thought the RIPE NCC should do what they wanted.

Andrea said he agreed with him in those cases where there was agreement – but the complication came from those cases where there was no agreement.

Hans Petter Holen, speaking for himself, said that in the case of the last resort registries that were acting as a proxy for the RIPE NCC, it should be treated as any other PI – unless there was some other written agreement in place. He said it was complicated and Andrea's question of who was the legitimate holder was the key question and without a clear answer you couldn't resolve these conflicts. He said it wasn't a matter of how much resources to spend on it or how to do it – if they as a community couldn't answer that key question and do so in writing, one or other party would get angry. And if the solution was vague when it was decided it would also not be very good.

Sander asked if Hans Petter was saying they should treat those addresses as PI that were registered in the database as PI, unless proven otherwise.

Hans Petter said yes if it happened in the time when it was a last resource registry or the inheritance of that, but then you were going into the grey area. He said it was pretty clear when it was a last resource registry but in those cases where the addresses were kept after that date that it became less clear. He said he didn't have a clear answer to that.

Elvis said it was not only those that kept it, some LIRs received allocated PI from the RIPE NCC to make assigned PI. He said these were actual LIRs and not last resort registries that became LIRs.

Hans Petter said the question was what was the contract, agreement or policy in place when this was done.

Elvis said the policy no longer allowed for PI, however someone could circumvent policy by going to one of these registries and asking for a PI assignment. He suggested the RIPE NCC should somehow block the possibility of creating more PI assignments from these allocated PI or allocated-unspecified blocks. He agreed that if there was an agreement between both parties then they should convert this into PA or transfer it to a new LIR. However, he said that IP addresses were now considered to be assets by some people, and the question was who held that asset. He finished by saying that if anyone received a PI block from an LIR then it should be treated as assigned PI.

Gert said he tended to agree with Elvis on the allocated PI blocks and said these were fairly easy policy wise. He said it was the allocated unspecified blocks that were bothering him as these were less clear as to what was what.

Sander said they should avoid banning new assignments from allocated PI space. He said it was allocated space and it would need a strong proposal if they wanted to change that.

Gert said it had been given out to be distributed according to RIPE Policy and the policy said no more assigned PI. He said LIRs should therefore not be making these assignments.

Andrea said there were nine LIRs that they had spoken to who were making PI assignments or planned to in the future.

Gert said he didn't think the policy permitted this. He said he didn't know what the contract they had said, but he was sure it would have said that the policies had to be followed and he didn't think they should be doing this.

Gert said they were running out of time so they could run through the rest of Andrea's presentation and they could discuss it on the list.

[Andrea went on to talk about the issue of whether they applied ARIN's 50% usage requirement to legacy resource transfers into the RIPE NCC service region. He said once the address space came into the RIPE NCC service region the receiving party could transfer the resources the day after, despite having supplied a plan for their use].

Erik said he was one of the people who had done this. He said his motivation had been that they were splitting up the prefix as soon as it went into the RIPE region. He said this was policy compliant and was consistent with having the resource in use. He said could have been a bit of a stretch but they weren't selling space just to stockpile it.

Andrea agreed that it was compliant with the policy and said they were just raising the issue for transparency.

Sandra said the only comment she had would be if an organisation transferred legacy resources into the region but then wanted to send it to a subsidiary that was fine, but to do what Erik was explaining seemed somewhat speculative.

William White, Hubs, (via Remote participation) said the conditions on the recipient outside the ARIN region would be defined by the policies of the receiving RIR. From what he could tell, ARIN did not impose needs-based policies on the receiving RIR.

Gert said they could have a very good discussion on this but unfortunately they didn't have enough time. He asked people to reply to Andrea's remaining points as separate emails on the mailing list.

Y. Open Policy Hour - Defining IPv6 PI Sub-Allocations

Maximilian Wilhelm

This presentation is available at:
https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf

Sander said it was important to realise why the policy prevented sub-allocations. He said in IPv4 it was very common that someone could give one IP address to a customer and the customer would NAT. If they allowed people to do this with PI space, people might think that it was too expensive to become an LIR and they could just get a PI assignment and give everyone one IP address so they could NAT. As this wasn't intended in IPv6, at the time it was explicitly said that they wanted to close this loophole that had existed with IPv4. He said it was therefore important to note that the current situation was created intentionally.

Gert said the policy wasn't created with people like Maximilian in mind, but rather big telcos that wanted to continue their single IP address/NAT practice. He said they knew what they had wanted back then, but maybe this had changed.

Elvis said that it wasn't just one IP address in IPv4, several sizes could be considered by the RIPE NCC to be a point to point connection. He said at one point they had considered changing the IPv6 policy but it was considered too complicated. He said maybe they should consider changing the policy to make it possible to sub-assign /64s from PI assignments as PI holders were already doing this, and the fact that they couldn't register this in the RIPE Database was a bad thing. He said it would be good if /64s could be registered for consistency of the registry.

Gert said they wanted to encourage ISPs to give their customers a /56, so making it possible to give /64 sub-assignments from PI allocations might send the wrong message.

Elvis said that allowing the customer to connect to your network was not really making an assignment and using a /64 for that was enough. He said giving your customer a /56 was something else and should remain forbidden by the current policy.

Erik Bais said PI was not intended to allow services to be provided to third parties, so the RIPE NCC was right to deny the PI request. He said if you were a service provider, you needed to become an LIR. If it was for your own infrastructure, then you could use PI space – but this was not intended to give it out as a service or sell it. He said changing that definition would be bad because they didn't want people to decide to use PI resources as a cheaper option.

Maximilian said he wanted to add that they were totally non-commercial and didn't receive any money or have any money.

Erik said he was very sympathetic and if Maximilian needed an LIR that held an IPv6 prefix so he could do it properly he should let him know. He said kudos to organisations that wanted to provide IPv6 connectivity but doing this over PI space was not a good idea.

Sander said to clarify, Erik was talking about sub-allocated PA space from a different LIR.

Peter Koch said when he opened his laptop he had received an IP address from the meeting network and he hoped that he wouldn't end up in the database for that. He said they had also had the discussion that End User assignments would not show up in the database for data protection reasons, so he wasn't sure he understood the suggested model. He said they had a similar discussion years ago about hosting providers and the infrastructure they rented or sold to their customers while the gear remained in their racks. He asked if Maximilian would consider people participating in his group as members of his organisation or not.

Radu-Adrian said that while he agreed that the best thing for him to do would become an LIR, he disagreed with Erik. He said the difference was between providing WiFi for an office and offering WiFi in the street and asked what the difference was at the end of the day. He said from this point of view a PI block should be fine for them, just as it was for an organisation that provided a connection to its employees. He said that globally it would be better to become an LIR, have some form of legal organisation that could become an LIR and do this the way it was expected.

Maximilian said this did not work in reality but that was another topic.

Scott Leibrand, speaking for himself, said he looked at the IPv6 address that was being used on the meeting WiFi and found that it was assigned PI in the RIPE Database. He said that RIPE NCC itself was therefore doing what was apparently illegal. He said maybe they should be making a distinction between things like self-assigned addresses on a LAN using slack versus DHCP allocations as they seemed different to him.

Sebastian Wiesinger (via remote participation) suggested they create a new category of non-profit LIR that had lower fees but added that this would have to be something for the GM.

Erik said that maybe local NOGs could help out with this and he volunteered to help Maximilian himself. He said he liked the idea of a non-profit LIR.

Sander said he had also done this for a German non-profit organisation, so it had been done before.

End of second session.