RIPE 69 Address Policy Working Group Minutes

RIPE Meeting: 69

Working Group: Address Policy

Status: Final

Chair: Gert Doering, Sander Steffann

Scribe: Antony Gollan (RIPE NCC)

Session I – Wednesday, 5 November 2014, 09:00 – 10:30
Session II – Wednesday 5 November 2014, 11:00 – 12:30

Session I – Wednesday, 5 November 2014, 09:00 – 10:30

A. Administrative Matters

This presentation is available online at:

https://ripe69.ripe.net/presentations/65-wg.pdf

Gert Doering welcomed attendees to the “No More Addresses Working Group” and said he would not be repeating this joke again. He welcomed co-chair Sander Steffann. Gert introduced the agenda for the day and said one of the big topics would be the selection process for new WG chairs. He said this meeting had the most policy proposals on the agenda ever.

The minutes from the previous RIPE Meeting were approved without comment.

Gert addressed a rumour by saying that he was not stepping down as WG chair. He handed over to Sander to talk about the WG chair selection process.

B. WG Chair Selection Process

Sander Steffann, Address Policy WG Chair

This presentation is available online at:

https://ripe69.ripe.net/presentations/80-RIPE69-WG-chair-selection.pdf

Randy Bush IIJ, said one of the problems they had highlighted was the WG chairs making things overly complex. He asked if they could just get on with it.

Sander said if there were no more comments from the WG, he would put together a new text and post it into the list.

Gert said he had expected there to be more comments, as there had been some discussion about this on the mailing list.

C. Current Policy Topics

Marco Schmidt, RIPE NCC

This presentation is available online at:

https://ripe69.ripe.net/presentations/70-Current_Policy_Topics_RIPE_69.pdf

There were no questions.

D. Feedback from RIPE NCC Registration Services

Andrea Cima, RIPE NCC

This presentation is available online at:

https://ripe69.ripe.net/presentations/72-APWG_RS_Feedback_Final.pdf

Gert asked about the infrastructure use in IPv6 PI. He noted that the graph showed there were around 30 requests per month for IPv6 PI, and asked how many of these requests had to be turned down. He asked how many of these people wanted to use it for their own use, and how many wanted to run some sort of ISP-like service on IPv4 PI and couldn't do this with IPv6 PI.

Andrea said the graph showed only successful requests, and said about 20%-25% of total requests had to be gently declined. He said the requestors sometimes came back and said they would not use the assignment for connectivity, so the RIPE NCC had to issue the /48. He said this number was increasing.

Gert said this was intentional and they were aware that these clauses were different in the IPv4 and IPv6 policies and they had mentioned this in the WG at least three times before. He said so far this did not seem high enough for someone to step forward and say they wanted to change the policy. He said it was a useful exercise to point out that there was an imbalance, that it was an intentional imbalance, and that it could be changed. He said that as it stood, there was nothing the RIPE NCC needed guidance on, as the policy was quite clear.

Wilfried Woeber, ACOnet, asked if the requestors being turned down were long-established LIRs who should know that they could enter a policy proposal – or if this was about new LIRs who didn't have this background information.

Andrea replied that most of these organisations were not established LIRs but rather were smaller organisations that had IPv4 PI and would like to continue with IPv6 PI in the same direction. He added that they had suggested to some of these people that the RIPE NCC could help them to create a policy proposal if they would like, but they were not connected with policy development.

Gert said he thought that was all the RIPE NCC could do – clearly communicate the issue and the options.

Erik Bais, A2B Internet, referred to the 24 month holding period for temporary transfers and said that while the policy was clear and could apply to temporary transfers as well, he didn't think this was the intent. He said the intent for the holding period was to prevent the flipping of resources, but that was not the case with temporary transfers, as they returned to the original holder.

Andrea said what they were asking was once a transfer returned to the original holder, did the holding period apply to the original holder from that moment on, or could they make another temporary transfer right away?

Erik said he thought the holding period didn't apply to temporary transfers. He said there was a risk that the original holder would simply do a lease contract without updating the RIPE Database to get around this restriction. He said in that case it was only if the company needed to have the database updated that they would go through the RIPE NCC. He added that in his personal experience these were corner cases, as temporary transfers did not seem to be common.

Andrea agreed that they did not see many temporary transfers.

Erik said they should treat it as a leasing contract which was basically the same as an assignment.

Gert said he thought the holding period was put in there to prevent speculation and people didn't speculate with temporary transfers.

There were no more comments. Gert said they would take Erik's comments as the word from the room.

Lu Heng, OutsideHeaven, referred to the case of multiple LIR accounts being opened to acquire additional /22s from the last /8. He asked about the numbers and whether they were running out of /22s.

Andrea replied that they were not running out, as they still had more than a /8 available for allocation. He said that the RIPE NCC had issued around 4,500-5,000 /22s in total so far, and had issued around 1,000 over the past 12 months. He said that as they were looking at about 70 cases out of 1,000, it was not common, but it was a growing trend which was why they were raising the issue now.

Lu said he thought the community had time to make policy around this. He said the original intention of the policy was to reserve the final /8 for new entrants, not to make it available for the transfer market. He said that as a proportion of the total address space in the RIPE NCC service region, the last /8 was a very small piece, so it wouldn't affect the transfer market anyway. He suggested they put more strict rules in place so that the final /8 was preserved for people in the future to access IPv4 for a very minimum cost.

Gert said he heard Lu's comments, but he thought this would be difficult to achieve. He said he welcomed a policy proposal on the issue.

Erik said there were several ways to sort this out – one was to disallow mergers or transferring /22s into another LIR that already had a /22 from the final /8; another was to use a holding period so that an LIR couldn't transfer a newly allocated /22 to someone else. He said both methods were basically options to say that they needed to pay an upkeep. He said the reason this was financially viable and interesting for some people, was because if the LIR opened in the last quarter of a year and transferred their /22, they would increase their profit and get this address space for a minimum cost – there was no requirement to make them keep the LIR and pay a maintenance fee. He agreed with Lu about the intent of the policy and said he had previously asked the WG if they needed to fix this, and the feedback was that people weren't concerned by this. He agreed that this was a growing trend and would grow faster and faster.

Sebastian Wiesinger, Noris Network, said he agreed with the others that this was not the intent of the last /8 policy. He said they should do something about it as soon as possible. He said he didn't know how much work this was creating for the RIPE NCC if more people were opening and closing new LIRs.

Andrea replied that, regarding the workload, they had processes in place to help organisations enter into a contractual relationship with the RIPE NCC. He said this didn't add any extra burden on the RIPE NCC.

Sander said they could basically rephrase this part of the question to ask if the EUR 2,000 sign-up fee was enough to cover the RIPE NCC's costs.

Andrea said that in his opinion it was.

Sebastian said he thought they should do something about this, but he didn't know what the best way was.

Wilfried said he wanted to add that there was a perception that creating a new LIR and moving the address space was cheaper than going to the transfer market.

Gert said that it was cheaper.

Wilfried replied that if it was, then it was a strong incentive to look at the intentions they had when they created the policy and add some limitations.

Lu said the best way to do this would be to make these /22s different to other allocations – so they couldn't be used in the transfer market and people couldn't gain financially from them.

Elvis Valea, v4Escrow, agreed that it was cheaper to open LIRs and transfer the allocations and said they should change this. He said if they opened a new LIR at the end of the year and closed it, it would cost around EUR 2,400, and if they did this at the beginning of the year it would cost them about EUR 3,600 – as opposed to around EUR 8-10,000 on the transfer market. He noted that, as a broker, people were increasingly approaching him with these /22s for transfer, and he refused them. He suggested that they apply a two-year holding period before allocations could be transferred, as this would cause people to pay the RIPE NCC the membership fee for two years in addition to the sign-up fee – which would make it less attractive financially.

Gert said blocking these allocations for transfers for 24 months might be the least complicated way to make this a less attractive option and he liked the idea.

Christian Kroeger, Hofnetz IT Services, said that while there were a small number of these cases at the moment, it was easy to register an LIR, and so this number could increase quickly. He said they should do this sooner rather than later, while they still had time to address the issue.

Elvis volunteered to come up with the proposal.

Gert said he welcomed Elvis and perhaps Wilfried and Erik to submit a proposal.

F. Discussion of open policy proposals

2014-03 Remove Multihoming Requirement for AS Number Assignments

Job Snijders, NTT

This proposal is available online at:

https://ripe69.ripe.net/presentations/88-ripe69_apwg_2014-03.pdf

Erik said the intention of the policy was correct and he fully supported it. He said he was looking forward to the next impact analysis.

Kurtis Lindqvist, Netnod, said that rather than having an arbitrary 1,000 ASN limit, perhaps they could instead say that you could have an AS Number when you had a separate routing policy from the rest of the organisation, which was the definition of an Autonomous System. He said that way random numbers wouldn't be needed.

Job agreed that this made sense. He said that the reason they had included this number was that there was no way to prove that you had separate routing policies and this couldn't be verified. He said with the 1,000 ASN limit, there was no need for fact checking, there was no need to lie, and no need to dig into people's networks. He said the criteria of having separate routing policies became more complicated because it was difficult to check.

Kurtis said he didn't think it needed to be checked or verified but just wanted to say that this was the definition that was used. He said there had been bad policies with arbitrary numbers in the past and he didn't want to add to this.

Job said his personal preference was to have a yearly cost of one euro per ASN per year. He said then they would not need this arbitrary number, as there would be a system that forced people to pay for the resource. He said if a per-ASN cost was reintroduced, he would create a new proposal without the 1,000 ASN limit.

Gert noted that charging for AS Numbers was on the agenda for the RIPE General Meeting. He said it was an arbitrary number but from the mailing list feedback it was clear that they needed something to stop people requesting four billion ASNs. He said the 1,000 ASN limit was found to be higher than anything that they could reasonably imagine, but low enough to provide a sanity margin. He said if this cost per ASN was approved in the AGM, they could remove this limit from the policy, but in the meantime he felt it was a reasonable compromise. He added that the WG had no formal power to make the GM do that, but said this would be a good approach.

Sander said to come up with the 1,000 ASN number, they had looked for the entity with the most ASNs, which was 100, and had multiplied this by ten.

Tahar Schaa, Cassini / swiss.gov / de.government, asked how they came up with these numbers.

Job replied that it was ten times the biggest amount.

Tahar asked if there was something that documented why an organisation needed 100 ASNs.

Job said they had looked at usage, and the RIPE NCC had documentation why that organisation had 100 ASNs. He said he didn't why know the organisation needed those ASNs, but they had obtained them according to the current policy and that was good enough for him.

Tahar suggested they produce a document to justify this large number, otherwise there was a risk that someone with no clue would request 2,000 ASNs by default, and there was no document to correct them.

Job said there were guidelines (RFCs) for assignments of Internet number resources that were noted in the policy text and elaborated on scenarios where you would require an ASN and when you would require more than one ASN.

Gert clarified that the 100 ASNs were simply the highest number that the RIPE NCC had found to be held by one organisation. He said if they extended beyond that, the RIPE NCC would give them advance warning.

Tahar said that perhaps these 100 ASNs weren't justified.

Job said he couldn't judge this organisation's needs.

Elvis said he didn't like the arbitrary 1,000 number either, though he saw the reasons behind it. He suggested they start with 100 ASNs and then change things if they run into it.

Job said if they did this, they would run into conflict with the organisation that already had 100 ASNs.

Elvis said he thought this might be something to do with an organisation that held legacy resources.

Job said that it was excluding legacy, so a limit of 100 ASNs was incompatible with reality.

Marco Schmidt, RIPE NCC, said he just wanted to answer the question about the organisation with 100 ASNs. He said it was a large provider in Russia that needed a lot of networks and ASNs due to the geography of the country.

Gert said the proposal would go to the mailing list for the review phase, and they would have the impact analysis that would tell them what the RIPE NCC thought about this.

2014-04 Removing IPv6 Requirement for Receiging Space from the Final /8

Martin Pels (presented by Sander Steffann)

This proposal is available online at:

https://ripe69.ripe.net/presentations/62-RIPE69-IPv6-Req-in-IPv4-policy.pdf

Erik said he really liked the intent to remove the IPv6 allocation requirement entirely as it didn't make sense, and didn't help any deployment.

Marco said the RIPE NCC was currently working on the impact analysis and had been asked to provide a preliminary analysis. He said the number of IPv6 allocations would decrease, and there might be the need to increase communications efforts as there could be a mistaken perception that support for IPv6 had been withdrawn.

Gert said that could be addressed by reminding LIRs when they requested their IPv4 /22s that the world was moving to IPv6.

Elvis said he supported the proposal, as organisations would always be able to request IPv6 from the RIPE NCC and all the policy did at the moment was require four more clicks (to request the IPv6 allocation) which didn't achieve much.

Gert said there had been a suggestion on the mailing list that they should do much more to incentivise IPv6, but there weren't any concrete suggestions. He said a lot more voices had said this requirement should just be removed from the policy. He said the updated proposal would be on the mailing lists soon.

[End of first session.]

Session II – Wednesday 5 November 2014, 11:00 – 12:30

2014-05 Policy for Inter-RIR Transfer of Internet Resources

Sandra Brown, IPv4 Market Group

You can find this proposal online at:

https://ripe69.ripe.net/presentations/82-RIPE-69-2014-05-Inter-RIR-Transfers.pdf

Elvis said he liked the proposal, but he wasn't sure that ARIN would accept the five years / 50% needs threshold.

John Curran, ARIN, said that when the inter-RIR policy was discussed within the ARIN community, what came up was that any other RIR transfer policy had to require the recipient to have operational need and for this to be demonstrated. He said, to that extent, if RIPE adopted an inter-RIR transfer policy that required an operational need for 10% of the addresses in the next 50 years, that would be acceptable to ARIN – and they had told their community that this would be their interpretation. He added that if the requirements were overly specious, perhaps the ARIN community would go back and change the policy, but he couldn't speak for the community.

Erik asked if there was any reasoning behind the five years / 50% threshold

Gert replied that this was somewhat arbitrary, and as they had heard from John, anything that met this minimum requirement would be deemed acceptable.

Erik said he really liked that they had removed from the policy the requirement that the RIPE NCC establish operational procedures with the other RIRs to accommodate their needs requirements.

Gert said they had received good feedback on the list and there was enough to go to the next version of the proposal. He said if there was something in the text that people couldn't live with, they should send this to the mailing list by next Tuesday. He said he wanted to avoid Sandra creating a new version of the proposal only to have this stopped by complaints in the review phase that could have been voiced earlier. He said what he heard from the WG was good and positive. He thanked Sandra for her work in putting together the proposal.

“SHOULD” and “MUST” in the Policy Text

Andrea Cima, RIPE NCC

This presentation is available online at:

https://ripe69.ripe.net/presentations/73-APWG_Should_Must_final.pdf

(Gert said they would approach these policies together, rather than separately.)

Gert said on the mailing list they had received feedback from Nick Hilliard that they should not implement the change in the IXP policy, as IXPs had been interpreting this as a “should” and had used the allocations to number non-IXP-related things.

Jan Zorz, no affiliation, said that as the person who introduced the idea, he wanted to thank the WG for taking it further.

Gert said that one counter-argument he had heard was that they should review the policies in their entirety to ensure they still made sense – rather than having an old policy document published as a new one with only one word changed.

Kenji Shioda, Nebula Online, said that the point that Gert had raised was not a good idea – as this would require much more discussion for each policy individually. He said it was better to do this one step at a time.

Daniel Stolpe, Resiliens, said he had a general question. He said they had mentioned IXPs and asked if they had seen any cases where this clarification had revealed diverging interpretations, or if the text was ambiguous but everyone had always been sure of how the policy should be interpreted.

Andrea replied that the IPv4 policy for IXPs was very strict and said that IP addresses used for the peering LAN could not be used for any other purposes. He said the text in the IPv6 policy was a bit more vague and less defined. He said they rarely saw cases where an organisation wanted to use these addresses for other purposes. He said this exercise (the policy proposals) was about looking in general at all policy documents to see where there was ambiguous text – but this didn't necessarily mean issues were arising from that text in all of these cases. He said that there had been some issues, such as one organisation that had asked if they could use these resources for other purposes, and they were told that according to the RIPE NCC's interpretation, they could only be used for a peering LAN.

Daniel asked if this was about more than just cosmetic changes.

Andrea said that it would make the interpretation of the policies stricter in many cases, which could have an operational impact on some organisations.

Gert said he saw the need for an impact analysis that would show how the RIPE NCC would handle existing cases if they went forward with the proposals – for example if IXPs had been using addresses for other stuff, as they had been interpreting “should” as a “should” – how would the RIPE NCC deal with this? He said their decision whether or not to accept the proposals would depend on the operational impact they had.

Sander said it was important to be clear in policies and, in the case of the IXP policy, this exercise had uncovered a fundamental flaw in the way it had been written. He said maybe they needed to go further into the policy and fix it in more detail, and if they decided that this was the case, this had been a good exercise to start with.

Jan referred to Daniel's comments and said if you suspected you had a ticking bomb in your hands, you didn't want to wait for it to go off if you knew how to stop it.

Gert replied that on the other hand, if organisations' services were likely to be impacted by this, it might be easier to just block the policy change.

Tahar referred to the previous slide about information security/confidentiality and said he interpreted the silence from the room as broad support.

Gert said he liked that statement, because if there were any objections people would voice their disagreement at the microphones.

Erik referred back to the IXP slide and asked if these organisations were able to request an additional IPv6 block for their own usage.

Andrea replied that they could request IPv6 PI or IPv6 PA for themselves.

Erik asked if there was any blocking way that implementing this as a “must” didn't cut out the rest of the organisation because they already had an assignment or an allocation.

Andrea said that this was correct.

Ole Jacobsen, the Internet Protocol Journal, said that the IETF had a document that talked about should, could and must and they always appeared in uppercase. He asked if they should apply this to RIPE Policies.

Gert said this was what started this process – there was ambiguity and Jan Zorz pointed out that there was RFC 2119. He said that as this wasn't an RFC, it wasn't directly applicable, and so they decided not to use uppercase and just keep it in plain English. He said a “must” in English was about as strong as one in uppercase according to RFC 2119.

Ole said as long as they had the definition of what they meant by “should”, “shall” and “must” that would be fine.

Gert said they tried to make it as unambiguous as possible, and this was not always easy.

Andrea said that Marco Schmidt, their Policy Development Officer, was now spending more time with proposers to ensure that this was being incorporated into new policy proposals as well.

Gert said he was taking the silence from the room as a decision to move forward with these proposals. He said if people supported individual changes, they should voice their support on the mailing list – especially if they thought something should not be done. He noted that Nick Hilliard had clearly stated he didn't like the change for the IXP policy. He said if they decided not to go ahead with one of the policies or all of them, it wasn't a major disaster – and it was a useful exercise in any case to look at the policies and document exactly what they should be.

2014-13, Allow AS Number Transfers

Erik Bais, A2B Internet

This presentation is available online at:

https://ripe69.ripe.net/presentations/86-2014-13-ripe69.pdf

Tore Anderson, Redpill Linpro said he had some objections on purely cosmetic grounds, as Erik had basically copy-pasted text from the IPv4 policy into the IPv6 and ASN transfer policies. He said this resulted in a lot of redundant text being repeated. He suggested they create a new resource transfer policy for IPv4, IPv6 and ASNs instead.

Gert said they were being presented as separate proposals because they allowed the WG to discuss IPv6 and ASNs separately. He said he had advised Erik to do this. He agreed that Tore had a point and suggested that if they came to the end of the process they withdraw one of the proposals and rework it to combine both.

Erik said he wanted combine all of the text once the separate policies were accepted. He said separate proposals were best as they meant people could say they liked one and not the other.

Tore said he was happy for them to aggregate all the content once the separate proposals had been accepted.

Erik noted that he had said that they could combine all of this content in Warsaw. He said the end goal was to have one policy document all about transfers.

Sander said the current policies were in separate documents and in future they should look at all their policies to combine them – not just for transfers, but for the whole set.

Heather Schiller, Google Fiber, referred to the proposal to allow ASN transfers. She asked why an ASN couldn't just be returned if it wasn't in use.

Erik replied that the problem wasn't with ASNs not being used, it was about having to return ASNs that were being used under the current policy.

Heather said there was a separate policy for transfers and name changes of organisations that covered all Internet number resources.

Erik said the current text said you must return unused ASNs and they were changing this to a “should”.

Heather replied that the examples given in the document sounded like they were already covered by the mergers and acquisitions document.

Gert said this was accepted if the RIPE NCC considered that it was a merger or acquisition and there were legitimate cases where they would not.

Andrea Cima, RIPE NCC, agreed that there were legitimate cases where organisations couldn't transfer an ASN. He said, for legal reasons, they did not consider it a merger when a mother company owned a lot of LIRs and wanted to transfer ASNs and IPv6 resources between LIRs – as the RIPE NCC had agreements with the LIRs and not the holding company. He said there were also cases where an organisation transferred all of their IPv4 resources to another organisation, and wanted to transfer all of their other resources as well, but were prevented from doing so by the policy.

Gert said what he was hearing from the room was that they might need to hear some more examples to explain why this was a real problem even though they had the mergers and acquisitions document. He said he wasn't hearing that transfers were evil, which they had heard in the past.

Erik said the people he had talked to in the corridors had liked the proposal and comments on the mailing list so far had been positive.

Kenji asked if it would be possible in future to transfer just ASNs (without any other resources being transferred) if the proposal went ahead.

Gert replied that it would.

Elvis said he wanted to state that they had his support for the policy.

2014-12, Allow IPv6 Transfers

Erik Bais, A2B Internet

This presentation is available online at:

https://ripe69.ripe.net/presentations/87-2014-12-ripe69.pdf

Gert said he had seen enough support on the mailing list to go forward to the impact analysis and the Review Phase.

Erik said he believed the Discussion Phase was until 28 November. He said he didn't expect a lot of issues on the mailing list for either of the transfer proposals.

Sander said there seemed to be organisations that wanted this and no one seemed to have any objections, so it looked like that the proposal would go ahead fine.

Open Policy Hour

Elvis suggested they use the remaining time to discuss a proposal to stop IPv4 /22s from being sold in the transfer market. He said this was unfair and they could add some limitations to the policy.

Gert invited Elvis to take the microphone and lead the discussion.

Elvis said there were two problems he could see: the first was that /22s could be requested and transferred immediately under the transfer policy, and the second was that if they added a restriction on transfers, a company could sell the server that was used to justify the /22, and the merger and acquisition process would be applied. He said the way he saw a policy proposal working would be to say something like a /22 received from the RIPE NCC could not be transferred within the first two years – as it was received from the RIPE NCC in order to help the company migrate to IPv6. He said in the case of a merger or acquisition, if the assuming company did not have a /22, it could keep it, as it could be considered its last /22. He said that if the assuming company already had a /22, then it should be returned to the RIPE NCC.

Gert asked about the corner case of a new LIR that might want to sell its business in five years' time. He said if the buying LIR also had a /22, they would have to return this to the RIPE NCC.

Elvis said this limit would only apply for the first two years. He said if an organisation received a /22 and wanted to transfer it through either a merger or acquisition, or through the transfer process, they would either have to return it to the RIPE NCC, or not be able to transfer it. He said if it was not within the first two years, then it was fine.

Gert said this seemed to deal with the corner cases he could think of, and seemed to remove the financial incentive.

Wilfried said he didn't like the idea of returning address space, especially if it was being used operationally. He said he preferred making it almost impossible to re-transfer addresses. He said this would be a limitation on the receiving end – if an LIR had already received addresses, it should not be able to transfer either the same address block or a different address block in the same period. He said people getting additional /22s was against their intentions when they created the policy. He said this was a good opportunity to fix this particular issue – but they could also go wider with this.

Gert said this was a worthwhile goal, but it might be better to fix the /22 issue right away, while looking at the broader picture and putting that into a separate action to avoid being rat-holed into endless discussions on the transfer policy.

Sander asked if Wilfried's suggestion meant that any organisation with incoming transfers was then blocked from making outgoing transfers for 24 months.

Wilfried said that was more or less the idea. He said if an LIR received a /22 and already had a /13, it should be blocked from selling a /15 out of its legacy address space.

Gert said he agreed with that personally, but as WG chair he thought it would be complicated to do.

Erik said they could have a 24 month waiting period for transfers and they could do this on newly-issued or incoming resources. He noted that it would also be possible to do mergers or acquisitions of LIRs and there was no policy or 24 month waiting period for that. He said that after a merger or acquisition, one of the LIRs was “killed”, and the merger or acquisition was not something they could stop from happening, so limiting the amount of /22s within a single LIR was not going to be the final solution.

Gert said what he was hearing from them was something like: an LIR couldn't be closed or merged within two years, which meant they would have to pay the yearly fee twice, which would block the business model of opening and closing LIRs.

Elvis said he wanted to cover all the corner cases because there were several different ones. He said if an LIR requested a /22 and wanted to transfer it, that would only be possible if two years had passed since the moment they received the /22. He said that would cover all the transfers. He said if an LIR that had received a /22 was merged into or taken over by someone else, then again that /22 must have been received at least two years previously – and if it happened within the two years, then it should either be returned to the RIPE NCC, or it could be kept by the new LIR receiving it, if that LIR didn't already have a /22 from the last /8. He said in this case, it would be considered as an LIR receiving its last /22 from the RIPE NCC.

Gert added that if the receiving organisation already had a /22, the LIR being purchased would have to keep its account open for two more years.

Erik said that this still left it possible open multiple LIRs.

Gert replied that this wasn't what they were trying to fix. He said people could still open multiple LIRs and there was nothing they could do to stop it.

Elvis said this would only stop the speculation.

Sebastian Wiesinger, Noris Network, asked if making people pay the membership fee for two years would be enough to stop this practice.

Elvis said they would be investing EUR 5,000 into something that would make them around EUR 6-10,000. He said it wouldn't really be worth investing when you couldn't know what the price would be in two years.

Gert said the market might even go down in this time.

Sebastian said it would be worth keeping an eye on these numbers over the years.

Gert said the RIPE NCC would keep them informed.

Sander said basically what was suggested was what they allowing people to do what they can do currently, but adding limitations that would make it difficult to make a profit out of it.

Jason Schiller, Google, said in the event that there was a legitimate merger and acquisition of two LIRs, he was happy to pay the fees, but it might not be possible to pay from two separate companies for legal reasons. He urged them to allow this to be paid by one company.

Sander said this would be difficult, as it would need to go via the GM. He said they needed to be mindful of the barrier between policy and RIPE NCC membership discussions.

Erik said if they actually had a merger or acquisition, they could simply add the LIR to the company entity, as one company could hold multiple LIRs, so the problem didn't exist.

(An audience member) said he was wondering if this proposal was an anti-stockpiling policy. He asked if it would result in a faster run out of IPv4 or a faster uptake of IPv6.

Elvis replied that the RIPE NCC still had more address space now than it had in the beginning. He said it had over a /8 and had a /12 returned to it by IANA.

Gert said that speaking to people he heard that there was actually large amounts of IPv4 address blocks being sold off today, so the /22s were just a tiny fragment of the total volume being traded. He said the incentives behind the /22s were wrong, as the policy was there to give people in ten years' time a tiny chunk of IPv4 to run their NAT64 boxes on – not to be acquired cheaply and sold on the transfer market for a profit. He said the last /8 would not make a dent on the market because there was hidden liquidity in the market, like the /8s belonging to HP.

Sander said they had two different cases. He said one was that they were talking about closing the loophole where someone started up an LIR only for the purpose of selling off the addresses again. He said the other one was that if someone needed addresses for themselves, they could still set up multiple LIRs. He said the second cases would still be possible, they were just aiming to block people who were just there to make money out of it.

Wilfried said he took the position that he didn't want to propose a policy where they tried to balance on a long-term basis the cost of becoming an LIR and getting a /22 compared to the price they could sell it for. He said what he would like to try and do was to come up with a policy proposal that was more or less agnostic to the price issue, but at the same time try and limit the rate at which the /22s were being used up. He said their goal was to have as many of them available for as long as possible for people who needed to deploy these addresses in a real network.

Gert thanked Elvis for making good use of the remaining time and said he looked forward to seeing a proposal on this issue.

[End of session two.]