RIPE 70 Address Policy Working Group Minutes

Chairs: Gert Doering, Sander Steffann
Scribe: Antony Gollan (RIPE NCC)

Session I – Wednesday, 13 May 2015, 09:00 – 10:30
Session II – Wednesday, 13 May 2015, 11:00 – 12:30

Session I – Wednesday, 13 May 2015, 09:00 – 10:30

A. Administrative Matters

Gert Doering welcomed attendees and introduced his co-chair Sander Steffann. He went through the agenda.

The minutes from RIPE 69 were approved.

B. WG Chair Selection

Sander Steffann, Address Policy WG chair

The WG reconfirmed Gert as WG co-chair without comment.

Gert said it was a bit ridiculous stepping down and stepping up again, but it was important to give people from the community an opportunity to step-up.

C. Current Policy Topics

Marco Schmidt, RIPE NCC Policy Development Officer

This presentation is available at:

https://ripe70.ripe.net/presentations/65-Current_Policy_Topics_RIPE_70.pdf

There were no questions.

D. Feedback From NCC Registration Services

Andrea Cima, RIPE NCC

This presentation is available at:

https://ripe70.ripe.net/presentations/82-APWG_RS_Feedback_Final_AG.pdf

Eric Bais, A2B Internet, asked if Andrea had seen cases of people requesting /22s, merging them and then transferring them as larger allocations when they were consolidated.

Andrea replied that they had.

Eric asked if this was considered to be out of line with the intent of the existing policy. He asked what the RIPE NCC's view was and whether it had tried to stop this behaviour.

Andrea replied that the RIPE NCC had highlighted this as a potential issue in its impact analysis when the last /8 policy was being discussed. He said the community had asked them to keep an eye on it and report back if it was happening – and this was what they had done at the previous RIPE Meeting. He said the RIPE NCC had raised this issue because it did not seem to be consistent with the intent of the policy and it was up to the community to decide whether it was or not.

Andrew de la Haye, RIPE NCC, noted that they had contacted the person Eric mentioned (who was consolidating /22 allocations into larger ones) and told them this was not in the spirit of the policy, but nevertheless it was continuing.

Tahar Schaa, consultant for the German Government, referred to Andrea's comments on rejected IPv6 requests and asked if they were all initial allocations and whether they had similar problems with subsequent allocations.

Andrea replied that the cases he had raised were all first allocations, as the subsequent allocation policy was quite clear with regards to the HD-ratio.

Gert asked if they saw many subsequent allocation requests.

Andrea said he thought they'd only ever seen one additional allocation request. He added that there were cases where they discussed with organisations how they could qualify for an additional allocation, but this had not resulted in formal requests.

Gert said he thought the policy was working as the intention was not to have people coming back for additional allocations.

Jens Ott, Opteamax, asked if Andrea could give them a rough percentage of how many new LIRs were made for the sole purpose of obtaining and transferring the /22.

Andrea replied that it was about 9-10% and this had been referenced in a recent RIPE Labs article. He added that this only included transfers and not mergers and acquisitions.

Jens replied that this was far too much.

Elvis Valea, v4Escrow, said that (as author of the policy proposal 2015-01) the first step was to close the gap with a policy proposal that would bring allocations made by the RIPE NCC in-line with transferred blocks. He said this would not affect mergers or acquisitions or the possibility of opening multiple LIRs. He asked if it was possible to reject multiple registrations of LIRs by the same company, as if not then there was not much they could actually do. He said they could request that the RIPE NCC came up with some arbitrary number to limit people to opening so many LIRs under the same company name. He asked if the RIPE NCC could see any solution for this.

Andrea said there were legitimate businesses with administrative reasons for having separate LIRs (such as separate divisions or separate geographic locations) and they would be affected if this was limited.

Gert added that it wouldn't be hard to create shell companies with a new company name. He said they might take this to the GM as it was more of a membership matter.

Radu-Adrian Feurdean, CCS, asked if they could have more transparency around mergers and acquisitions, as much of this activity was slipping under the radar and the RIPE NCC had this information but the community did not. He said one of the cases that had been presented on wasn't in the IPv4 transfer statistics as these did not cover mergers and acquisitions.

Andrea said the community had asked the RIPE NCC to publish information relating to transfers via a policy proposal and there was no such policy for mergers and acquisitions. He suggested that a policy could be created for this.

Gert asked if a policy would be needed or if it would be enough for the room to say it wished the RIPE NCC to publish these statistics.

Andrew replied that they would need to discuss this internally.

Radu-Adrian suggested they introduce the term “organisation” instead of “LIR” to make things clearer, because at the moment you could have multiple LIRs within an organisation and there were policies that considered one LIR as one company. He said it might be an idea to start talking about organisations instead of LIRs.

Gert replied that LIR was a precisely defined term – one entity that had a contract with the RIPE NCC and paid a yearly membership fee. He said an organisation would be much harder to define – an organisation might be a multinational with tens or hundreds of sub-organisations. He said it would be hard to define this without a specific proposal.

F. Discussion of Open Policy Proposals

2014-03, Remove Multihoming Requirement for AS Number Assignments
Job Snijers (Update by Gert Doering)

Eric said it was possible that after the GM they would reach a point where they weren't going to charge for AS Numbers and they would be stuck with a proposal that not everyone was happy with, and would have to start a new version without those limitations.

Gert said it would depend on the outcome of the GM. He said he would go through the mailing list and see if they would go forward with the text they had or if they needed to develop a new version and re-enter the Review Period. He said they needed to ensure there was an anti-abuse or garbage collection mechanism.

Eric said that currently ASNs didn't have a charge and it was possible to request a lot of ASNs even with the multihoming requirement. He said it seemed silly to have this additional limitation in there, and if it became a problem they could face it similar to what they were doing with the /22 issue currently.

Gert said they needed to have some garbage collection mechanism in there, even if it was just the inconvenience of having to pay ten euros per year for an ASN you didn't need. He said they would take it back to the mailing list.

Eric suggested that they could come up with some requirement similar to 2007-01 where people actually needed to reach out to the RIPE NCC to retain their ASNs. Maybe they could make something where they needed to contact the RIPE NCC before the assignment “expired.”

Gert said 2007-01 had actually intended to do this but hadn't been written clearly enough enough and so there was no formal mandate for the RIPE NCC to actually install a garbage collection mechanism. He said they could create something that required the RIPE NCC to establish this mechanism. He said it would depend on the outcome of the GM.

Hans Petter Holen, Visma, said that when the proposal was created, he had supported the intention to remove bureaucracy. He said that garbage collection and reclaiming resources was important and suggested they go back to the drawing board to think about how to do this with a neutral, technical criteria that would be best for the RIPE NCC to implement. He said they should identify simple criteria that were concrete.

Gert said they had found that checking from the outside how an ASN was used was about as difficult as checking from the outside how IPv6 addresses were used.

Sander said they had intended 2007-01 to be a garbage collection mechanism and they were going too much into the implementation details by forcing the RIPE NCC to charge for this.

Elvis said there were multiple ways of doing garbage collection and he said they shouldn't leave it to the GM and they should do this in the policy. He suggested they ask the RIPE NCC what was feasible. He said this was a good policy proposal that aimed to reduce lies to the RIPE NCC. He also suggested the RIPE NCC could do a ping to check whether an ASN was in use and creating a process where users had to confirm every year whether an ASN was needed.

Gert said he wanted to task Andrea with seeing if they could come up with a sentence to go into the proposal with something like: “The RIPE NCC is tasked with ensuring the ASN is still in good use and if not it should be returned” and seeing whether they could find some way of working with this.

Andrea said as this was an operational detail they could take care of that. He noted that Gert had said the ASN holder “should then be encouraged” (to return the ASN) and he asked if they could be more specific – to clarify whether the RIPE NCC needed to ask them to hand the ASN back.

Gert said they could come up with some new text.

Sander said it was about creating a balance between descriptive or loose policy text.

Nick Hilliard, INEX, said this discussion was because they had imminent depletion of a finite resource. He noted that they had problems with 32-bit ASNs but an almost endless supply of them. He said he'd brought up the idea that the IETF should fix the technical problems with 32-bit ASNs. He said that from a global view, they had a perceived need to come up with a slow-down policy for the assignment of 16-bit ASNs. He said he wasn't going to suggest how people should vote at the GM, but at its root this was an IETF problem and they needed to talk with the IETF seriously about this.

Gert said he wanted to point out that the proposal only dealt with 32-bit ASNs and 16-bit ASNs retained the multihoming requirement.

Nick replied that the current proposal, which was based on imminent resource depletion for one type of ASN, while making it easier to request another type, just didn't work as a policy. He said the requirement that the RIPE NCC record but not evaluate need didn't really work. He said the existing policy had lasted them for the last 25 years and they needed one for the next 25 years.

Brian Nisbet, HEAnet, said he wanted to caution against including a requirement in the policy that the RIPE NCC check ASN use every year. He said he was worried that if this mechanism went into place, other verification requirements might be added to it later (such as checking abuse-c or other things).

Eric noted that the RIPE NCC was already doing its Assisted Registry Check (ARC) and this might be an extra question when the RIPE NCC was already reaching out to LIRs.

Brian replied that there was a difference between an audit and something that went out to every LIR every single year. He added that he was making no value judgement on whether this was good or bad.

Alignment of Transfer Requirements for IPv4 Allocations

Elvis Velea, v4Escrow

This presentation is available at:

https://ripe70.ripe.net/presentations/89-20150513-2015-01.pdf

Sander noted there had been some confusion on whether this would be applied retroactively. He said he thought it was quite clear – transfers would not be reverted, but they would apply the new transfer policy in future. He said if this conflicted with people who had opened the LIR just to sell the addresses, this was kind of the point.

Gert noted that Elvis had created the proposal because the room had wanted a proposal and he had volunteered. He said that since they were in Review Phase, most people had made positive comments on the mailing list, except for a few concerns about whether this was retroactive which he thought had been addressed.

Eric thanked Elvis for writing the policy and said he didn't deserve the personal attacks he'd received on the mailing list and it was frightening to see the tone of the discussion. He said it was really uncalled for. He said he hoped they could leave it at that and have a good discussion moving forward. Eric said the current text said that LIRs were prevented from transferring address space to another LIR for 24 months from receiving the allocation. He suggested that, to move this further, they add a 24-month cooling period for any depleted resource, which would also include mergers and acquisitions.

Sander clarified Eric's comment, saying that after somebody received a resource, no matter in which way they received it, they could not transfer it for 24 months.

Eric said that was correct.

Sander said this was simple and effective wording.

Eric said it was very effective wording, to the point and basically it aimed to what they wanted to achieve: if people have received a depleted resource, they had a 24-month waiting period, no matter how they got it. He reiterated that this would only apply to depleted resources – IPv4 PI and PA and 16-bit ASNs.

Elvis said they would have to define what a depleted resource was.

Eric said that was why he'd put it into the text.

Elvis said they couldn't include it in the text as this was changing the |Pv4 policy and not the transfer policy that they would be talking about very soon.

Sander said that as 16-bit ASNs and IPv4 were close to depletion, while 32-bit ASNs and IPv6 were nowhere near, he thought they could safely enumerate them.

Gert said that, as a matter of process, if Elvis's proposal got enough positive feedback and no show stoppers, they would go through with the current text to get this into place quickly and stop the abuse. He said Eric could then work on his unified transfer proposal later. He said if they had to do another round on Elvis's policy, then they could look at wordsmithing it further.

Eric asked if there was some way that the RIPE NCC could implement the proposal immediately once it was accepted.

Andrea Cima said in this case it was a procedural issue and so he didn't see any issue with implementing it immediately once the proposal reached consensus.

Gert said it was now up to the community to give enough positive feedback on the proposal. He said what he had right now on the mailing list was enough but he wasn't making any promises on the future.

Chris Kroeger, BCIX, said he thought the comments against Elvis had been out of hand.

Peter Hessler, Hostserver, said he strongly supported the new policy as at a previous company they were a small hosting provider and a policy that allowed them to get some IPv4 had really kept them running. He said they needed to preserve this for people in the future.

Gert thanked Peter for confirming that the last /8 policy did actually work.

Sebastian Wiesinger (speaking for himself) said he'd predicted this in the past and had said then that they needed to close this loophole. He noted that the RIPE NCC Executive Board had also put in place a requirement that one full year's fees be paid before a merger or acquisition could be processed for any new LIR – to make it more painful for organisations that were abusing the policy. He said he had asked the RIPE NCC for closure statistics and noted that these cases had been increasing and they'd seen 100 more closures in 2014 than the year before, so they needed to act quickly. He said it was easy to be relaxed about IPv4 exhaustion when you had enough addresses but he wanted to preserve IPv4 for newcomers for years to come.

Sander added that he wanted to thank the Executive Board of the RIPE NCC for adding in the one-year requirement because he thought that had already been a major improvement.

David Huberman, Microsoft, said if they put a two-year waiting period in place, it might encourage bad actors to request even more addresses due to their predictions that IPv4 would be worth more in two years time.

Elvis replied that they couldn't know whether IPv4 would be worth more and it would be a big risk for a bad actor to request 20 to 30 allocations.

David said that was Elvis's opinion, and it might also be his opinion, but he said the only opinion that mattered was that of the actor. He said if they wanted to solve the problem they needed to empower the RIPE NCC to stop the bad actor. He added that this didn't actually stop you from selling a /22 to someone who needed it.

Elvis replied that they could just register the addresses in their name in the RIPE Database.

David said you didn't need to have addresses registered against your name in the RIPE Database to have it routed.

Gert said he was sure the RIPE NCC's board had heard these comments and tackling this issue was partly the Address Policy WG's responsibility and partly the board's.

Tahar said he supported the proposal but was worried it would fail. He said people could still merge LIRs and get allocations that way.

Elvis agreed that the proposal didn't cover mergers and acquisitions said and they would need to continue to discuss how to handle this as this was a RIPE NCC procedure and not a RIPE Policy issue. He said they could discuss this further during Eric's proposal after the coffee break.

Janos Zsako, Hungary, said he didn't think the proposal would encourage stockpiling and he supported it. He added that this proposal didn't fix the entire problem and they needed to remain flexible when looking at processes and react as quickly as possible.

- End of first session.

Session II – Wednesday, 13 May 2015, 11:00 – 12:30

F. Discussion of Open Policy Proposals (continued)

2015-03 Assignment Criteria for IPv6 Initial Allocation Size

Mathew Newton and Alexander Brinkman

This presentation is available at:

https://ripe70.ripe.net/presentations/72-20150513_NCC-Presentation_AddressAssignment.pdf

Gert said it was a case of the current policy only really taking into account large ISP-like entities and occasionally there were very large requests that couldn't work with the current policy. He said the proposal took away the requirement on the number of customers or existing network structure, and gave more flexibility to the RIPE NCC. He asked whether as a community they wanted an open policy that left it up to the RIPE NCC to evaluate requests (which might backfire as the RIPE NCC could use criteria that they didn't like) or did they want to list the criteria themselves, which they might have to revisit to ensure it covered all cases.

An audience member said they were talking about 50% of the current IPv6 routing table for one entity and this made him very concerned. He urged the RIPE NCC and other RIRs not to give these organisations one global prefix and at the very least to give them one block per RIR, as this made it easier to route traffic from other regions. He said it was nice to be on nibble boundaries, but if they were going to be using blocks like a /28 then they could work a bit harder and not waste address space.

Alex Le Heux, Kobo, said he understood that they wanted to use bits in the addresses to hardcode their hierarchy because they wanted to do aggregation on lots of levels. He said if they had 10,000 locations with 10,000 entries it was very small. He asked why they wanted to do this.

Alexander Brinkman replied that they wanted to have their internal routing table and routing summaries as good as possible. He said the main need for these IPv6 addresses was for their internal network – only a very small number of these addresses would be public on the Internet. He said they currently had two companies that were merging together and this kind of segmentation helped them a lot – they had to make smaller parts of this to not use as nibbles. He said the idea was to have the same logical structure everywhere, with the risk that they would waste some IP addresses. He said the structure was more important that the efficient usage of addresses.

Alex said this still didn't entirely answer his question. He said even if they had no hierarchy they ended up with 10,000 routes which wasn't very much. He said even with a /29 they did have some bits to add in hierarchy. He said even having a flat structure didn't seem like a problem to him so they needed to explain to the community why they needed this structure.

Sander added that within the military there were also different security zones.

Alex said there was already some hierarchy available and asked why they needed as much hierarchy as possible.

Gert said they might want to discuss this further on the mailing list to give a little more background on things and the onus was on the proposer to convince the community that the change was worth supporting.

Tahar said the German Government really supported the proposal and if they looked on the mailing list the Spanish and Swiss governments also supported this. He said he'd like to go a bit higher and explain why this mess was there. He said that with IPv6 something changed – some big companies thought it was a good idea to have their own addresses, and a split was made. With IPv4 you had address providers that were also network providers. With IPv6, large companies or countries were becoming address providers, but without their own infrastructure – so the count of users and infrastructure was senseless because they didn't have any. This was a change in the situation and motivation for providing addresses – you didn't have your own infrastructure, you wanted to provide it for your own organisation regardless of the provider that implemented it. He noted that in the beginning of the IPv6 policy it said that it aimed to be fair to all users of the Internet – and big companies or countries were also legitimate users of the Internet and they needed to be fair to them also, they simply had different requirements. He said the question now was should they list all the possible sense-making criteria – as this could be a long list. He asked if instead they should trust the RIPE NCC to assess this. He said it was up to the community but he would trust the RIPE NCC. He said maybe rather than stating the criteria that were positive, it might be better to list criteria that would not be reasonable or acceptable.

Gert asked Marco how much guidance the RIPE NCC needed.

Marco Schmidt, RIPE NCC, said if the current proposal was accepted, the organisation would need to provide documentation that reasonably justified the request. He said they had a team of IP Resource Analysts that had experience at evaluating these claims, but they would welcome guidance from the community regarding issues such as hierarchy as there could be different opinions on what was reasonable.

Benedikt Stockbrand, Stepladder IT, said a lot of people weren't that comfortable doing IPv6 address plans. He said that during the trainings he gave people often started out conservative and treated it like IPv4 but within minutes began thinking of IPv6 as infinite and wasted addresses. He said they needed to make sure that large allocations weren't given out to organisations and operators that didn't know what they were doing.

Tasha said that these large organisations supplied address requests that took a year of effort – so he assumed that every organisation which had paid for this effort had made up its mind and its request made sense.

Sander said that for many organisations, IPv6 was new, and they shouldn't just make these kinds of assumptions.

Gert said he'd heard a number of comments that they should loosen up the initial IPv6 policy, along with some guidance for the proposals. He said the proposal had enough backing to go forward, the caveats had been pointed out, and deaggregation was something they needed to be careful about. Gert thanked the proposer and said the discussion would continue on the mailing list.

Keep IPv6 PI When Requesting IPv6 Allocation

James Kennedy (presented by Gert Doering)

This presentation is available at:

https://ripe70.ripe.net/presentations/73-2015-02.pdf

Gert said he would cover the presentation as James had lost his voice.

An audience member asked if the RIPE NCC could clarify how many PI resources had been returned in this way.

Marco said about 50 resources that had been returned. He said there were 1,700 PI holders that could potentially become LIRs and have to return their assignments.

Gert said he wouldn't spend any more time on this, and said people were very happy with the proposal.

H. Will It Be Routed? - On IPv6 Address Space Allocation & Assignment Approaches in Very Large Organisations

Enno Rey

This presentation is available at:

https://ripe70.ripe.net/presentations/94-ERNW_RIPE70_Will_It_Be_Routed.pdf

Gert said an easy solution for the WG would be to pass the issue to the Routing WG and say it was theirs to solve, however it was starting to touch on address policy so it was good to have background information to make educated decisions.

Eric said he found it interesting in Enno's presentation that the networks of those companies and their locations were not interlinked. So they were basically assigning a portion of the acquired allocated space, assigning it to a location and just announcing it there as if it were PI space. He said his question was why use the space that you had from the ISP at that location. That way the ISP locally could handle the aggregation. He said if it was because someone was too lazy to do their own firewall policy, which was quite easy to do, then they had different issues because that wouldn't work. He said if the networks and the locations were not interlinked, why go that route? Because he would filter the /48s for any prefix that came from a /32 or larger.

Enno replied that the networks usually were interlinked. He said they were like a global MPLS network and there were organisations that used this public internet for offloading. He said that from a technical perspective, they had this, but on the other hand, he was only speaking as a representative observing certain trends. He said some of these were very large organisations with network teams that mostly knew what they were doing and they should be cautious in assuming otherwise. Enno said that, regarding Eric's comment regarding filtering every /48 that came from an allocated /32, this brought them to the fierce debate of strict filtering.

Eric replied that this was best practice.

Enno said he respectfully disagreed. He noted that he had presented on this at RIPE 69 with research data from five IXs throughout Europe using data they collected quarterly. He said that on 1 January 2015, for the first time, the number of /48s announced without covering aggregates was larger than the number of /48s with covering aggregates (all from PA space). He said there was a growing trend towards not doing strict filtering out there. He said it was the market that decides – customers paying for providers transporting their traffic. He said they'd have to agree to disagree on this.

Gert said he wanted to introduce something that Enno had explained to him but hadn't explained to the group – that an easy example was when you had a global multinational company with its own backbone that wanted to offload traffic to its peers in Europe or the US – but they weren't ISPs and their stateful firewall required that the packets would come back when they were sent out. He said the only way to do this was to have a more specific announced in Europe and a more specific announced in the US. So if they insisted in having multiple interconnection points and multiple firewalls, some trade-off had to be made.

An audience member said that was ridiculous.

Gert replied that this was technology as they had it today and he was just explaining why this was coming up.

Enno said he could only re-state that the research data now showed that since January the number of more specifics without covering aggregates was larger than the other way around.

An audience member said he had a comment regarding asymmetric routing and firewalls – if you put one firewall in Europe and one in the US and you expect all the traffic you received in Europe to go through the firewall first and then across the Atlantic, then you had an insane network design and RIPE shouldn't cater to those people.

Gert said it was the other way around, he had a /29 and used a /32 of that for the European network and a /32 for the US network. He said he would expect traffic sent from the American network to the American Internet to really pass through America and not have the response packets come via Europe because someone's routing policy said Europe is much better.

An audience member said this was the Internet and it happened.

Gert replied that this was true but asked whether they wanted people to use IPv6 or did they want them to use NAT. He said with NAT you could get around all this easily. He said there was a trade-off to be made. He said he wasn't saying that this was right, only that there was no perfect solution today.

David said this was a very good presentation and his experiences completely mirrored what Enno had said. He noted Enno had asked if they considered this a problem. He said the only problem he could see was that organisations didn't want to have to go to multiple LIRs for their IPv6 needs. As an operator that was active in all regions, he said that he liked the RIPE Address Policy WG's liberal attitude – which was about giving people numbers they needed with as little amount of crap as possible. He said it'd be great if the WG could say strongly to the world and to the RIPE NCC that if you were based in Europe and needed IPv6, you could receive it and could use it wherever your need took you.

Milton Mueller, ARIN Advisory Council and Syracuse University, said they'd gone through a very intense debate of the out of region policy at ARIN and had gone through several iterations of this, though ultimately it had been abandoned. He said there was a lot of support for the idea, but they had bumped into a lot of high-level principle disagreements regarding what the RIRs should be doing and this needed to be discussed in a broader context. He said he wanted to raise the question of whether number resources were truly global and the RIRs were regional facilitators because of linguistic differences and geographic distance; or did they conceive of RIRs as exclusive distributors of resources where they had to conform to the territorial jurisdiction of the RIRs. He said they wouldn't resolve that issue but one of the issues that they hadn't mentioned that had come up in ARIN's discussions was ICP-1, which was an ICANN statement of policy about criteria for the establishment of new RIRs. He said they had been told by ARIN staff members (incorrectly he believed) that the out of region policy conflicted with ICP-1 – that is, the statement that one RIR should not overlap another RIR's region meant that there was territorial exclusivity. He said he believed this language was intended to surround the establishment of AFRINIC to create general criteria for when you'd want to create new RIRs. He said the community needed to have a broader discussion about the reason for the “regional-ness” of RIRs and whether the number space was global and whether they wanted to facilitate the global use of addresses or not.

Sander said complete territorial exclusivity could never be absolute because networks did not stop at borders.

Milton noted that in the United States, part of the push behind this discussion was the LEAs, who wanted addresses to be territorial and to map to geographical jurisdictions. He said if you wanted to do that, then why not have National Internet Registries (NIRs) instead of RIRs.

Jen Linkova, as an engineer operating a global backbone, said she couldn't understand the idea of regional usage of IP addresses as the network was global. She said she couldn't understand how to limit the use of IP addresses to a particular geographic region, networks did not stop at borders. She said the only way to do traffic engineering to receive traffic through the link she wanted was to advertise more specifics sometimes. She said she knew it might be evil to deaggregate, but sometimes it was the only way if you wanted to be multihomed and use your own address space. She said as soon as they applied some common sense it wasn't such a problem. She added that they did see this in IPv4 and it was even worse because people didn't want to use NAT. She said she couldn't see why this was a problem and why they even needed to talk about out of region use.

Thomas Schmidt, Continental AG, said they were a global acting enterprise and were an LIR in the ARIN, APNIC and RIPE regions for the same reasons Enno had pointed out. He said they had an internal MPLS backbone and acted as an ISP internally but they also had all kinds of independent Internet access – sometimes because it was faster to get access over the Internet and they also had some failover requirements that they sometimes had output in the US and input in Europe. He agreed that the community should face this issue and cater a little bit more to enterprises that were not acting as a normal ISP carrier.

Gert replied that the onus was also on representatives from these organisations to speak up and state their issues. He added that it was good that they were there today.

Hans Petter Holen, speaking as former Address Policy WG Chair, said he remembered having this same discussion back in the 1990s, though then it was about IPv4. He said the consensus (though it had been different across the Atlantic) had seemed to be that you could use addresses on your network, wherever that was. If you built a global network you were welcome to get your addresses for your network. He said large organisations often made nice attractive network plans before realising that they should have made this according to their topology rather than their organisation chart, as they ended up with three of four islands that were not connected internally and they had to redo their plan. He said he didn't think there was one size fits all, and maybe some of people's past experiences could be taken into account here.

Lu Heng, Outside Heaven, said his organisation only had around 70 staff, but he had been having this issue with using IPv4 addresses out of region. He said he thought this was one global network so they should be able to use addresses anywhere. He said this was an opportunity to allow IPv6 to become truly global. He added that it would be good to get rid of the hassle of out of region usage in IPv4.

Y. Open Policy Hour

Unified transfer policy

Eric Bais

This presentation is available at:

https://ripe70.ripe.net/presentations/74-General-Transfer-Policy-ripe70.pdf

Gert said unfortunately they didn't have time for comments. He said, as a shortcut, if there was something that people absolutely couldn't live with they should make a comment now, otherwise they would have time to discuss this on the mailing list.

Change size of last /22 allocations

Elvis Valea, Radu-Adrian Feurdean

This presentation is available at:

https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf

Eric asked how much address space would be enough. He said this was a problem they couldn't fix by giving someone enough space for six months or 12 months or two years – they needed to detox off IPv4. He said the last /8 was reserved for new entrants, not for existing LIRs.

Radu-Adrian replied that it was about easing the pain. He said they were throwing organisations out of the market and also signalling that IPv4 would be around for some time by holding onto a big chunk of IPv4.

Elvis said retaining a /8 was sending the wrong signal to the community. He said for those organisations that really needed it, receiving another /22 could make a big difference. He added that there had been so much noise on the mailing list between those that wanted more addresses and those that wanted the last /8 to deplete as quickly as possible.

An audience member said one thing seemed obvious – it didn't make sense that when someone requested a /24 they had to receive a /22. He asked how long they needed this /8 to last. He said at the moment it would last for around 15 years and they should make this a bit shorter.

Lu said he had to agree with Eric's point that it would never be enough. He said there were limits and people had to consider that IPv4 was a cost now and deal with it in their business plans. He agreed that the burn rate was slow and said he wouldn't object to burning through it faster.

Marco noted that in the impact analysis for Elvis's proposal they had said the RIPE NCC's IPv4 pool was expected to last for around five years.

An audience member said that this five years seemed shorter than the length of time they needed the last /8 to last for. He said he'd talked about this with Eric the previous night and they had agreed that IPv4 would still be needed for a further seven years. He said he couldn't see why they should burn these future companies just because organisations couldn't deal with it now.

Radu-Adrian said an important part was the message that holding on to the last /8 sent to the community.

Sander said he thought their homework was to do the numbers and look at what kind of burn rates they were talking about.

Lu Heng said companies would cost more in four years and IPv6 would be cheaper. He said they couldn't predict what the future would be in ten years. He said it wasn't a problem if IPv4 lasted a little bit longer.

(Before the session closed) David said he'd come up with an inter-RIR IPv4 transfer policy to allow IPv4 transfers to the LACNIC region. He said if anyone had opened a network on multiple continents or wanted to provide services in the region, he urged them to go into the mailing list and register their support.

- End of second session.