RIPE 67

Chair: Gert Doering, Sander Steffann

Scribe: Antony Gollan (RIPE NCC)

Session I - 16 October 2013, 09:00 - 10:30

Session II - 16 October 2013, 11:00 - 12:30

Session I - Wednesday, 16 October 2013, 09:00 - 10:30

A. Administrative Matters

Gert Doering welcomed attendees and noted that the day was 15 years since John Postel died. He asked that they take a moment of silence to remember him.

Gert presented the agenda for the “No More IPv4 Addresses Policy Group” and introduced the Address Policy Working Group Co-chair, Sander Steffann. The agenda was finalised.

Gert thanked the scribe, stenographers and chat monitors.

The minutes from RIPE 66 were approved without comment.

B. Current Policy Topics

Ingrid Wijte, RIPE NCC

The presentation is available at:https://ripe67.ripe.net/presentations/234-RIPE67_Current_Policy_Topics-final.pdf

There were no questions.

C. Feedback From RIPE NCC Registration Services

Andrea Cima, RIPE NCC

The presentation is available at:
https://ripe67.ripe.net/presentations/225-RS_Feedback_AP_WG_RIPE_67.pdf

Andrea said he had three topics on the agenda:

1. Changing PI assignments to PA allocations and whether to ignore the minimum allocation size
2. Reclaiming unadvertised ASNs
3. Allowing PI assignments to be transferred

1. Converting PI assignments to PA allocations and whether to ignore the minimum allocation size

Andrea said this had been raised at the last RIPE Meeting but had not yet been resolved. He said there were many cases where organisations had received a PI assignment and had later gone on to become an LIR. He said these organisations often asked to convert this address space into a PA allocation.

Andrea said organisations made these requests for a number of reasons: they could want to restructure their network due to IPv4 scarcity, make customer assignments out of the address space, or wish to transfer the address space to another organisation. None of this was allowed under current policy due to the space being PI.

Andrea said they had previously proposed two solutions:

a) Allow LIRs to change the status of their PI assignments into PA allocations (if equal or larger than the minimum allocation size)

b) Do not allow LIRs to change the status of their PI assignments into PA allocations

Andrea noted that after discussion on the mailing list, there seemed to be a consensus for allowing LIRs to change the status of their address space. He said there also seemed to be support for ignoring the minimum allocation size. He said this final point had not been finalised, and asked the group how they would like to proceed with this.

Gert clarified that the RIPE NCC understood the current policy to not permit allocations smaller than the minimum size. He said he would have thought that the minimum allocation size applied to allocations and that changing the status of PI space was not the same as making an allocation. He added that it might be worth having a policy proposal so the RIPE NCC knew what the community wanted. He finished by saying that the RIPE NCC was saying it couldn't change allocations smaller than the minimum size with the current policy text.

Fredy Kuenzler, Init7, said he thought the minimum allocation size should be ignored. He pointed out that /19 had once been the minimum allocation size and a lot of fragmentation had occurred since then. He said the minimum allocation size should be abandoned as what they were discussing was not real life.

Gert replied that this was what they had heard on the mailing list. He added that the RIPE NCC thought it could not just abandon the minimum allocation size and so a change to the policy text was required. He said he would like someone to volunteer for this.

Tore Anderson, Redpill Linpro, said he supported allowing conversions of PI assignments that had already been made, but was against allowing them to be further de-aggregated. He said this was consistent with the aggregation goal, which was the reason for a minimum allocation size.

Sander agreed with Tore.

Wilfried Wöber, UniVie/ACOnet, agreed with Tore. He said they had assigned PI blocks from a separate pool and so even in the past it was understood that they would see longer prefixes being announced from that pool of addresses. He said he wouldn't see any noticeable impact on the operation of his network if they agreed to convert PI assignments and wouldn't see any need to modify filters and so on. He said it was just a relabeling and so he supported the idea.

Elvis Velea, V4Escrow, said (via remote participation) they should allow changes no matter what the size and he didn't think they needed a policy proposal for that.

Gert said the RIPE NCC should tell the mailing list what its interpretation of the policy was and whether changing PI assignments smaller than the minimum allocation size could be done with the current policy text. If a proposal was required, the Working Group could find a volunteer to change the policy.

Andrea thanked the room and moved on to the next topic.

2. Reclaiming unadvertised AS Numbers

Andrea said that the global supply of 16-bit AS Numbers was slowly running out and while the RIPE NCC still had a good supply, it would eventually be exhausted. He noted that there were around 5,000 16-bit AS Numbers that had been issued in the RIPE NCC service region that were not being advertised. He said the policy stated that an organisation must return an AS Number to the public pool if it was not being used and added that the RIPE NCC had never gone after these resources in the past, as they had been told by the community that they were not the routing police. He said that with the supply of 16-bit AS Numbers being exhausted, he was now asking the Working Group what it would like the RIPE NCC to do.

Andrea proposed two options:

a) The RIPE NCC asks holders of unadvertised ASNs if they are unused. If so, the holder is requested to start using the ASN within a reasonable period of time or return it to the available pool.

b) The RIPE NCC does not contact the holders of unadvertised ASNs.

Gert highlighted that Andrea had picked up on one very important part – that it would depend on the holders telling the RIPE NCC that the ASNs were in use. He noted there were certain cases where ASNs could not be seen in the global routing.

Wilfried asked if the RIPE NCC saw a large number of requests for 16-bit ASNs.

Andrea explained that in the RIPE NCC service region, operators were doing very well and that more than 40% of the ASNs they issued were 32-bit. He added that around 60% of the ASNs being issued were 16-bit, though this number was slowly decreasing.

Wilfried asked whether they have any 16-bit ASNs left.

Andrea replied that they had a few thousand remaining and that this was why they were asking the question now. He said if the community gave them the mandate, they would still have time to look into this.

Wilfried said that going after the holders of the maybe-unused ASNs would put a strain on the RIPE NCC's IP Resource Analysts. He said that if there was no shortage at the moment, he didn't see why they should spend the effort to go after these resources. He added that as soon as they saw a real need that would be the time to ask this question again.

Andrea said that they had enough 16-bit ASN to last about one-and-a-half years and this was why they were asking now.

Rüdiger Volk, Deutsche Telekom, said it would have been nice if the slide included a reference to the policy text Andrea was quoting from. He asked if the policy meant “use” or “announce” and added that “use” was the appropriate term.

Andrea replied that the text he was quoting was from the “Autonomous System Number Assignment Policies”, which was ripe-525. He said that it read: “If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers.”

Rüdiger said that use of ASNs was not only in BGP announcements. He said it was important to keep this in mind.

Bill Manning, ISI, said option A was appropriate, but added that the RIPE NCC should approach organisations saying they wanted to ensure they were in compliance with ripe-525 as regarded these resources. Bill noted that when they hit a time of scarcity, desperately trying to go back for addresses had proven to be less successful. He said that a prudent steward of resources would check regularly. He said the RIPE NCC should have an ongoing process where it reminded organisations of the policies regarding their resources and if they were out of compliance it could help them become compliant again. He added that this would let people know that the RIPE NCC was a careful steward, as opposed to a panic situation where a company had been out of business for four years and the RIPE NCC was now trying to contact the appropriate person to reclaim those resources.

Andrea replied that this was a very good point. He noted that they had seen a lot of ASNs returned as a result of 2007-01 policy implementation, according to which an organisation had to enter into a contractual agreement with a sponsoring LIR or the RIPE NCC. He said that as part of this project, those organisations that did not exist any more – that could not be contacted and were not using their ASN – had their resources deregistered. He said there had been an ongoing clean-up project over the past few years because of this.

Geoff Huston, APNIC, said he had some numbers to share. He said there were 4,029 32-bit ASNs in the BGP routing table – 2,400 of which were originally allocated by the RIPE NCC. He noted that it seemed this area of the world was capable of doing 4-byte ASNs. He added that the only really anomalous region was ARIN, where 22 4-byte ASNs were advertised into the routing table, which seemed weird, and added that the problem seemed more there than in the RIPE NCC service region. Geoff noted that they had 5,324 unadvertised 16-bit numbers in the RIPE NCC service region. He said it would take an awfully long time for the RIPE NCC to contact these people and do the negotiation.

Geoff continued by saying that when looking at IPv4 addresses, allowing other people to broker and trade actually flushed out more unused addresses than the RIRs could. He added that he noticed ARIN had a policy around transfers of ASNs that might have a similar effect for identifying and recycling old numbers in the AS block efficiently. He finished by saying that the Working Group might want to consider a similar policy as an alternative to having the registry doing this long and expensive process – as others might do this for them more cheaply. He stated that he wasn't suggesting the Working Group should or should not pursue this approach, but was merely observing that this was a side effect of ARIN's policy in this space.

Rüdiger said he wanted to point out that in light of Geoff's observation of 4-byte ASN uptake in the RIR regions, barring equipment issues, there was no acceptable excuse for clinging to 16-bit ASNs. He noted that there were a few corner cases where certain functions could not be done for 4-byte ASNs, because the protocols didn't provide the appropriate data structures. He said he knew of certain functions on his own network that were only available for targeting 16-bit AS Numbers and said he couldn't expand the community field by another 32-bits. He said requirements for actual use may come up from that side, and it was not predictable that would be a real requirement because when people started, they probably didn't understand what holes they were running into. He said the RIPE NCC should keep those numbers available for parties with a need but added that it didn't mean this had to go through the policy process. He finished by saying that he had no opinion on whether this needed to be regulated or should go through a free-market approach.

Fredy said he supported Bill's earlier statement. He said he wanted to focus on the term “use”, and asked what that meant. He said people typically used ASNs for routing purposes, and so 99% of ASNs would show up on the table when in use. He suggested the RIPE NCC should contact those who had an ASN but were not using it in the global table after 12 months and send emails stating that they were not compliant with ripe-525. He said that the 1% who were using an ASN in a way that was not visible on the global routing table could then provide a reasonable explanation. He said this seemed to be a pragmatic way for reclaiming numbers that were not in use.

Wilfried said that while most ASNs would be visible in the global table, there were a number of use cases where you wouldn't see them.

Gert said the RIPE NCC understood this and this was why they would ask if people were using them. Gert said that what he was hearing from the room was that there was not an overwhelming rush to make the RIPE NCC do this, but there was also no strong opposition. He suggested that the RIPE NCC take this to the mailing list and outline what it proposed, highlight that there was no strong opposition, and ask what others thought.

Andrea thanked the Working Group for its feedback and said this was what they would do. He then moved to his final topic.

3. Allowing PI assignments to be transferred

Andrea said the last point he wanted to bring up was mostly for discussion and awareness. He said they had seen an increase in requests for transfers of PI address space, which they had to deny as they were not allowed under current policy. He said that the policy text also said that assignments were valid so long as the original criteria under which they were assigned remained. He pointed out that this meant if an organisation wanted to transfer these addresses to another organisation for a different purpose, this original criteria was no longer valid, in which case the space should be returned to the RIPE NCC.

Andrea clarified that PI space could be transferred through mergers or acquisition, as it was still being used for the same purpose. He said that when these transfer requests were denied, they would often see the contact details change – which likely meant that the transfer had gone through anyway but the data had not been properly reflected in the registry. He added that they had a feeling that the current policy was seen as a barrier by many organisations and could impact the accuracy of the registry.

Wilfried said they should see PI and legacy space as the same problem and handle both issues at the same time. He said if they came up with a special handling for PI it would make the policy landscape more complicated depending on the history of particular address blocks, and said this was the wrong way to go.

Andrea replied that legacy space and PI space were different in the sense in that PI space (as space assigned by the RIPE NCC) followed policies developed by the RIPE community. He said he understood what Wilfried was saying and noted they were seeing this when they spoke with LIRs and End Users and told them that they could do different things depending on the type of address space, which could be quite confusing.

Wilfried said they were also in the process of bringing legacy holders into the system and getting the contractual relationships into place with the sponsoring LIR. He said whether it was PI space from the RIR or legacy space from IANA, he didn't see any major difference in the handling of the address space.

Sander said he could respond as he was involved in 2012-07, which was about bringing legacy space into the fold. He said legacy space was different in terms of which policies applied to it. He said if Wilfried wanted to discuss this, he should bring this up in the RIPE NCC Services Working Group. He added that this policy didn't apply to legacy space anyway.

Gert said that maybe Wilfried was right and it might be worth looking at the addresses as bits and ignoring the colour. He added that they would try this for IPv6 in the next slot and that this was surprisingly complicated.

Erik Bais, A2B Internet, asked how Andrea thought they should proceed – whether he thought the community wanted to have a transfer policy in place or a more clear structure on how to deal with PI. He noted that in his own company, they often had customers with a certain type of address space asking whether they could buy, sell or transfer this space. He added that while he understood all of the corner cases, it did not make sense to End Users why they could do something with IP X and not with IP Y. He asked what in Andrea's view would be best for this. He said that updating the registry should be the priority, regardless of the colour of IP addresses, because as Andrea had pointed out, people would transfer this space anyway.

Gert said he was hearing from the room that this was a real problem and was affecting people that weren't there, as PI holders usually didn't attend RIPE Meetings. He noted that Erik had direct contact with people who ran into this and suggested that as a policy proposal would be required, perhaps Erik would like to volunteer.

Erik said he was happy to volunteer.

Fredy asked Andrea if he had seen any impact from the RIPE NCC's work on re-allocating referenced ASNs.

Andrea replied that they had only sent out a test batch of 100 emails and would send out more once they had seen what the response was. He said it was too early to have any results to report. He noted that they had published an article on RIPE Labs about this detailing the process and would publish a follow-up article later for full transparency.

Larisa Yurkina, ANO RosNIIROS, said they should allow PI assignments to be transferred if there was a transfer agreement signed by both sides.

Rüdiger noted that Andrea had mentioned there was a RIPE Labs article that described the process of reassigning referenced ASNs and asked if there was also official documentation about this on the ripe.net website. He asked if they had a systematic inventory where he could look for these things, and said it was inappropriate for things of this nature to only be on RIPE Labs.

Gert agreed and said procedures should not be on RIPE Labs.

Andrea said that the official announcement had been on the mailing list, but added that he would ensure that the official documentation went on the ripe.net website as well.

There were no further questions.

D. Discussion of Open Policy Proposals

2012-03 No Need – Post Depletion Reality Adjustment and Cleanup

Tore Anderson, Redpill Linpro

The presentation is available at:https://ripe67.ripe.net/presentations/241-20131016-RIPE67-2013-03_Status_Update.pdf

Gert said he wanted to make a comment on the process as Co-chair of the Address Policy Working Group. He noted there had been a lot of support for the current text on the mailing list, and this was why they had asked that it not be changed. He added that there were still some people who disagreed with the proposal and, as they felt that there was no way to take their objections into account while preserving the gist of the proposal, they were applying rough consensus and moving ahead. He said they had so much support that they had to ignore those few voices who were unhappy with it, as there was no way to get unanimous support. Gert added that he hoped the changes to the external relations part would alleviate some people's fears.

Wilfried Wöber, UniVie/ACOnet, referred to the use of the plural for “End Users” and said this meant an organisation requesting an allocation would not be able to use address space for its own network operations. He suggested they drop the “s” or at least put it into parenthesis.

Tore replied that this was already in the current policy. He said the specific text in the new amendment was something along the lines of: “The LIR must confirm that it will make assignment(s) from the allocation.”

Wilfried asked if this precluded the “own-infrastructure” use that they had in the general policy.

Tore replied that this was in the existing policy text, so if the RIPE NCC interpreted this to mean that organisations could not make assignments to their own infrastructure, this would already be the case. He said he believed the RIPE NCC interpreted it to mean that if you made assignments to your own infrastructure, you were your own End User.

Randy Bush, Internet Initiative Japan, addressed his question to the RIPE NCC staff webcasting the session. He asked if it was being recorded, as it was an example of petty bureaucracy gone insane. He asked how many times they had to go through and recycle minor changes endlessly and said they should get the policy approved and out the door.

Gert said he understood Randy's point. He said they had learned that working with the RIPE NCC early in the process helped to avoid text that caused it to go into a panic when preparing the impact analysis, which they had managed to avoid this time. He said he heard Randy's complaint, but on the other hand they didn't feel they could just ship it right now, though they would try to finish it as quickly as possible. He added that more verbose explanation would come on the mailing list.

Malcolm Hutty, LINX, said he wanted to thank the proposer and the Chair for taking the time to fix elements in the proposal that would have caused problems. He said he fully appreciated that a majority of the community wanted the proposal to go through, and felt that it had stated its support enough times already. He added that he thought they would all nevertheless agree that this was a significant policy and outside eyes were on it. He said it was appropriate that they take care to ensure they did not cause unforeseen reactions by a misunderstanding about what they were doing. He said the role of address stewardship by the RIRs was under scrutiny by outside entities who wanted to be sure that they could trust them with management of such an important worldwide resource. He said if they were to give out a message that said they didn't care about outcomes, speculation, or whether address space was used, which he thought the nickname “No Needs” contributed to, these outside parties could lose confidence in the community's ability to make these decisions. He said it was therefore in their interest that the communication of this was clear and in language that could be understood by these parties. He said that the extra arguments that Tore had added, and the changes, were worthwhile and while some might be frustrated by the delay, this was worthwhile.

Tore thanked Malcolm for not only pointing out the bugs, but also sending patches to fix the bugs.

Gert said the Chairs intended to amend the supporting notes and start another short review phase. He said that as the only feedback he had heard was to make the process go faster, they would have a shortened two-week review phase, which was as short as they could make it without being accused of rushing things, which could backfire in the Last Call phase and delay everything.

Gert thanked Tore for his work and for working with Malcolm, and thanked the Working Group for providing feedback.

2013-05 No Restrictions on End User Assignments in Intra-RIR Transfers

Sascha Pollok, IPHH

The presentation is available at:https://ripe67.ripe.net/presentations/238-ripe67-spollok-apwg-2013-05.pdf

Gert thanked Sascha for volunteering to take on the proposal. He said that feedback from the mailing list was positive, and that he had seen five or six supporting comments with a single opposing comment.

Elvis Velea, V4Escrow, said he thought the proposal was a very good idea. He said not being able to shift customers with the IP numbers was not a good option. He said there was a workaround for this, and people could just lie and remove people off the address space, transfer it, and then re-add them. He said this was not a fix, it was a bug.

Sascha said this might also require removing route objects which could cause operational trouble.

Gert added that lying to the RIPE NCC was not encouraged.

There were no further comments.

Gert closed the first session early and said he hoped to see people back for the second session where they would be discussing IPv6 changes.

Session II - Wednesday, 16 October 2013, 11:00 - 12:30

A2. Administrative Matters

Gert welcomed people back and said that while the previous session had been the “No More Addresses Working Group”, this would no longer be appropriate, as they were now dealing with IPv6, where there were plenty of addresses.

Gert reminded people that there would be an NRO NC/ASO AC election in the Friday morning plenary.

Kurtis Lindqvist, Netnod, asked if he could vote as he would not be in the plenary.

Gert told him to check with Rob Blokzijl.

There were no further comments.

Gert introduced Jan Zorz, who he said would be giving a presentation with no affiliation.

E. RFC2119 and Policy Documents

Jan Zorz (no affiliation)

The presentation is available at:https://ripe67.ripe.net/presentations/243-Jan-Zorz-APWG.pdf

Daniel Stolpe, Resilians AB, said there was already a good RFC about it and they shouldn't go into arguments about whether to use it or not.

Hans Petter Holen, Visma, said he thought they must use the RFC.

Lee Howard, Time Warner Cable, said they may use the RFC. He said that before incorporating a redefinition of language used in policies, they should do a review of the language already used, to make sure they don't change their meaning by redefining the language used in them.

Jen Linkova, Google, said she thought it made sense to use that language for new policies, and to explicitly state in the beginning of the policy that the language used was as defined in RFC 2119. She said they could then review existing policies, but because they didn't say anything like that, it could be open to interpretation.

Jan said this might be the shortest policy ever.

Gert replied that he didn't think that they couldn't just retrofit this onto existing policy.

Gert said they should task the RIPE NCC to go through the existing text and isolate occurrences of “should” that they were interpreting as “must” that made a significant difference, and report these back to the Working Group as something it might consider cleaning up.

Wilfried Wöber, UniVie/ACOnet, asked if this was a task for the cosmetic surgery project.

Gert replied that the cosmetic surgery programme was formally over, as all of the documents that had been considered had been processed and added that maybe it was time to restart the project.

Wilfried said these documents could be subjected to a little additional facelift.

Gert clarified that this was against the purpose of the cosmetic surgery project – which was about fixing up policy documents that had been patched so many times that they were no longer readable. He said this was about keeping the spirit of the policy while making the text easier to read.

Jan asked what they should do for future policies and their changes. He said in the room he heard must, must not and may.

Gert replied that it was a good thing for future documents to include a reference to RFC 2119 unless there were specific reasons not to do so, in which case they should inform him. He said it was worth checking with the PDO to see if this could be brought in for new documents. He said it was fine to make new policies RFC 2119 compliant, but including this as part of minor changes to existing policies was too big of a change. He added that the RIPE NCC and the PDO were listening and would take this into account.

Raymond Jetten, Elisa Oyj, said he thought they absolutely should stick to RFC 2119. He said they shouldn't make things more complicated by saying something in a different way.

Jan asked Raymond if, when he said “absolutely should”, he meant “must”.

Raymond said maybe.

Kurtis Lindqvist, Netnod, said he wasn't sure they should link RIPE Documents to RFC 2119. He said the RFC was for having sliding levels of compliance and that he wasn't sure they wanted this when it came to address policy. He said you either had compliance or you did not. He said a policy document that outlined who gained access to resources and how they were used should be very clear and shouldn't have any “shoulds”.

Sander said that in that case, the term “should” should be rarely used in policy text, if at all.

Kurtis replied that they should only have “musts” and said the policy text should be clear. He said there shouldn't be any ambiguity about whether someone would get addresses from the RIPE NCC.

Gert said he understood that Kurtis was saying the policy must be clear.

Hans Petter said he understood what Kurtis was saying, but said that if they were to have a different interpretation of language from the RFCs, then they needed to clearly define this to avoid confusion. He said they couldn't keep using “should” and think that the rest of the world understood what this meant unless it was explicitly defined. He finished by saying that while he didn't really care which way they went, he could see some merit in keeping the same language as that used in the RFC, as it was the same group of people reading both texts.

Jan said that this was because one part of the community already understood language as it was defined there.

Kurtis said his point was that they were now spending time on use of the English language. He said the text in RFC 2119 was deliberately there to lead an interpretation. He said that in address policy, he supported using language that was not open to interpretation. He said it was fine to use RFC 2119, but it should be limited to the use of the word “must” or “must not”.

Gert said they needed a review of the existing policy to see where it was ambiguous.

Kurtis agreed and said they should clean this up and make it less ambiguous, but said that using “should” was not going to make it any less ambiguous, whether it was in capital letters or not.

Sander Steffann, Address Policy Working Group Co-chair, said he thought they were clear that the language must be defined, and added that Kurtis should speak up when a new policy was being discussed that used “should” if he disagreed.

Malcolm Hutty, LINX, said he thought they should use language that was consistent with RFC 2119 and if this meant they generally used the word “must” and that “should” rarely appeared in policy text then so be it.

Sander said that this discussion reminded him that he had recently been talking with someone about the definition of End User and End Site and asked if they should focus this only on the RFC 2119 part, or if they should include other terms and definitions in that document.

Randy Bush, Internet Initiative Japan, said he wished people would speak their names and affiliations into the microphones. He said he loved how much time they could spend discussing definitions of his mother tongue. He said he that while he had sympathy for people who were not native English speakers, defining End User would probably take ten years given how long they were spending on this.

Gert said he thought they should start by focussing on RFC 2119. He said he was happy if someone stepped forward and proposed to write a document on End Users and End Sites, but said they must consider this as two different projects, because otherwise the RFC 2119 project would not go anywhere.

Jan said then they should create the shortest policy in the world.

Gert said they should first wait for the review from the RIPE NCC

There were no further comments.

F. Discussion of Open Policy Proposals

2013-06 PA/PI Unification of IPv6 Address Space

Elvis Velea, V4Escrow and Daniel Stolpe, Resilians AB

The presentation is available at:https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf

Elvis said if anyone had any questions during his presentation, they could go up to the microphone and interrupt him.

Tore Anderson, Redpill Linpro, referred to an earlier slide that had said you could get several allocations if you had different routing requirements and said he was not sure this was a good idea. He asked if this was up to a /29 per allocation.

Elvis said yes, it was up to a /29.

Tore said he knew that there were, for instance, CDN operators with thousands of sites around the world that had no backbone and were independently routed. He said they handled this by getting one /32 or /29 and inserting different route objects for deaggregates of that single allocation. Tore said that under this proposal, they could potentially request space up to something like a /18 in total, as they could get a /29 for each of their sites. He said that while operators would not necessarily do this, it was actually a sizeable chunk of the address space. He asked if they wanted to open the door for organisations to potentially do this.

Elvis said that was a good question. He said that currently these operators could do nothing but splice their allocation into multiple chunks.

Tore asked why that was a problem.

Elvis replied that deaggregating a /32 might lead to filtering or un-usability of the block.

Tore replied that it wouldn't, as the route object was separate to the inet6num object and said that if people were filtering deaggregates out of allocations right now, then Facebook and a lot of IPv6 content wouldn't work, as this basically was what the largest CDN provider in the world was doing right now.

Elvis replied that in that case, the Routing Working Group would have to update its recommendation to filter on the inetnum and not on the route object, in other words – filter on the size of the allocation. He added that this was something they would have to bring to the mailing list.

Daniel said this came back to “should” aggregate or “must” aggregate and if you were allowed to deaggregate or not.

Tore said he was not convinced it was a good idea to tell people that they were not allowed to deaggregate and instead give them large blocks of IPv6 addresses, because it didn't save anything in terms of routing table slots.

Elvis said they could say that if you had a separate network somewhere else, you could request a /48 for it, up to a /32, but not up to a /29. He added that he did not like this idea, as he was against the idea of adding limitations into the policy and they had worked hard to remove these. He said he wasn't sure about adding more limits just because a CGN may get a lot of space. He said he they would take this back to the mailing list for further discussion.

Hans Petter Holen, Visma, said he wasn't aware that the HD-ratio calculation problem was a problem. He said Elvis's interpretation was what he would have expected it to be, and said if it was a problem it would be interesting to track down where that came up and why. He continued by saying that the policy mentioned needing approval from the RIPE NCC for something, but didn't say what the criteria was and so this would be difficult for the RIPE NCC to evaluate. He noted that this also created bureaucracy and said it wasn't a good plan to introduce such mechanisms. He said the most difficult thing was that this proposal reversed the policies from 2006-05, which was when PI was introduced. He said this had been added so that organisations could become multihomed. He added that he personally recommended to companies that wanted to become multihomed that the only real solution was to become an LIR.

Randy Bush, Internet Initiative Japan, asked him to repeat that.

Hans Petter said companies could become their own registries to control their own addresses and have a relationship with the RIPE NCC and participate in the policy process. He said if you just got PI space, there were changes over time, and it was complicated if you needed a direct relation or had to go through an LIR. He said becoming an LIR was more expensive, but it also meant that companies got a direct relationship with the RIPE NCC. He continued by saying that the Provider Independent label should be removed, but the problem here was not on the policy side but with the fact that these companies would then need a direct relationship with the RIPE NCC. He said the problem with the proposal was that it tried to do too much at once. He said the most difficult consequence was the impact it had on the financial and contractual side.

Gert replied that he wanted to answer the last part of Hans Petter's comment. He said they were not trying to take PI away from people, but rather to solve the needs of those currently using PI and PA, by having one class of addresses. He said they were not reversing 2006-05, but were doing away with the distinction, while leaving the option for non-members to receive addresses. He added that this also removed the current hurdle which meant that if someone had a PI assignment and wanted to give their neighbour an SSL host on their machine, they couldn't, as this was an assignment and they were not permitted to do so. He said they were trying to make the whole thing simpler and easy for people to understand, but the consequences of this were actually quite complicated and it was difficult to get there.

Gert asked if Elvis wanted to answer any of Hans Petter's other points.

Elvis said he felt that Gert had answered them.

Randy said the point Tore raised was existing practice, it worked, and there was no serious suggestion for a better practice. He said that separately announcing deaggregations of allocations for separate routing areas was a fact of life today, it was not a bad fact of life, and said please don't shoot it.

Elvis said the idea was not to block people from deaggregating, as no one could stop them, but rather that if someone wanted a second allocation for their second network, or third, or hundredth, they would be able to get an additional allocation based on the idea that it would be in a different part of the world and would have a different routing requirement.

Sander said that it should be clear that the main goal of the policy was to make it more practical and give real world options and not make the policy restrict things. He said that anything people could do today, they would still be able to do with the new policy. He said it just tried to fit the real world better.

Elvis added that it also tried to remove restrictions.

Rob Evans, Co-chair of the Routing Working Group, said he wanted to correct a possible misinterpretation Elvis may have had based on his earlier statement, and to agree with Randy. He said the Routing Working Group's recommendations on route aggregation did not suggest that people filter on inetnums. He said they suggested that within IPv6, people should said be able to de-aggregate their /32 block, but that people should have route objects for everything they wanted to route.

Elvis thanked Rob and said he stood corrected.

Wilfried Wöber, UniVie/ACOnet, said that while the Address Policy Working Group was rarely concerned with financial considerations, he had a few questions about the proposal in this context.

Elvis said he would get to that in later slides, and continued with his presentation. Elvis turned to questions that had been raised on the mailing list, the first being: “Why limit anycast, ENUM and IXP allocations to a /48 if anyone else can get a /32?”

Elvis said their idea was to avoid complicating the proposal so that if someone disagreed with the idea of an IXP getting a /32, it didn't get through. He said these were the limits in the current policy and they were working. He added that if the Working Group thought these limits should be removed as well, he agreed, and thought that they should remove all the limits if possible, to make the policy as clear and simple as it could be. He asked what the Working Group thought.

Erik Bais, A2B Internet, said he had a question about changing the allocation size. He asked why stretch it up to a /40 or even beyond that, to make what non-members got similar to what they would get as a member. He said that for end customers for PI, anything larger than a /48 needed to be documented on a justification. He said that if people needed to do sub-allocations, as Elvis called them, to a customer or an entity larger than a /48, they also needed to go back to the RIPE NCC because there needed to be a sanity check so that people didn't give a /36 or a /40 to a customer. Erik said he did agree that there needed to be an arbitrary level at some point, whether this was a /40 or a /48 or whatever. He said he would like this to be the same number for regular End User assignments that they currently used for PI in IPv6, and for LIR assignments to an entity, because this would make things easier. He said that personally, a /48 worked perfectly, but said that if people thought they would need to go back 20 times a week because they assigned so much address space to customers or there were more than /48s that they needed to provide, then he would like to hear it.

Gert said that if the distinction between PI and PA was removed, then it didn't make sense to retain the option for non-members to get space through a sponsoring LIR, as it was inevitable that a non-member could also get a /32. He clarified that the question in bullet-point two (“Limit the non-LIRs to a maximum /30? Or maximum /32”) was really: was the community fine with it, or did it want an arbitrary limit in place? He said his gut feeling was that if they really wanted to do away with the distinction between PI and PA, then there should not be a special limit for non-members because then it was just a block of addresses and the distinction about the size of the address block was about whether people wanted to do sub-allocations to customers or not. He said that if not, a /48 was good, but if people wanted to, then it should be a /32 up to a /29, because people would need the space to work with and a /32 wasn't that big in terms of the whole IPv6 address space.

Elvis said their intention was not to limit how much address space a non-member would get, but rather to limit how much a non-member could sub-allocate, and also members. He said that currently the limit said that up to a /48 per End Site could be done without approval. He said if people needed more than a /48 per End Site, they required approval from the RIPE NCC, because it would like to know why they needed more than 65,000 networks for one site. He said there was no limit for how much you could sub-allocate to an organisation or to a customer, but anything beyond a /48 per site must be approved. He said they were advocating to keep the /48 for the site, but that sub-allocations beyond a /40 would require approval by the RIPE NCC. He said they were trying to add this artificial limit on how much people could sub-allocate without having to request an approval, whether they were an LIR or not, similar to the assignment window in IPv4.

Erik said he had always read the /48 as what you would assign to an entity.

Elvis said no, this was to an End Site.

Erik replied that this is why there had been the confusion.

Elvis moved onto the second point, saying that this was where people on the mailing list had said there should be limits on how much address space a current PI user could get. He said the suggestion was that an LIR could get /32s or up to a /29, but non-LIRs should be limited to a maximum of a /40 and if they needed more they could become an LIR. He asked if the Working Group thought this was a good idea and if so, the correct limit would be. He also asked if the whole thing wasn't meant to be about removing any kind of limits.

Hans Petter said he was confused about the earlier slide on sub-allocation. He said that if he went back to the original IPv6 policy they had prior to 2006, or 2009, if people wanted addresses they became an LIR or went to the RIPE NCC, or they became a customer of an LIR and received addresses through them.

Elvis said this was correct.

Hans Petter noted that there was often a link between becoming a customer of an LIR and receiving IP transit services from the same LIR. He said this wasn't stated in the policy, but was common business practice. He said that they had introduced PI so that instead of getting addresses from an LIR, people could get their own block through a sponsoring LIR.

Elvis agreed.

Hans Petter said what they were now proposing was that, if they were an LIR, they could still chop up their address block and give it to their customers as they had in IPv4 with sub-allocation many years ago and this was a similar construct. He said so they were actually creating LIRs with a direct relation to the RIPE NCC and they were connecting sub-LIRs with an indirect relationship to the RIPE NCC.

Elvis said that they were getting there as well.

Hans Petter said if they wanted to take this further they could do this recursively and could create an arbitrary depth of this tree.

Gert said there was a slide coming up that showed this tree.

Hans Petter asked if they were making this too complicated and said he didn't understand the benefit. He said he understood that they could make this construct work, but thought it was just adding new stuff that could be solved with the existing construct.

Gert said they were operating under the assumption that people wanted independently routed IPv6 address space and were unable to become RIPE NCC members or didn't want to for whatever reason. He said these people had the problem that there was stuff with PI that they couldn't do, like run a hosting business, as the policy didn't allow sub-assignments. He said there were two ways they could solve this – either by loosening up PI, or by removing the distinction between PI and PA altogether. He said this was an attempt at removing the distinction and figuring out what the consequences were. He added that the consequences would have to be that there were entities operating as LIRs that were members of the RIPE NCC, and entities that did the same things but were not members of the RIPE NCC. These latter entities would not be entitled to vote, but could still receive large blocks of addresses and give them to a hierarchy of customers. He said the underlying question was which way did they want to go and if they did want to go the way that the proposal suggested, how did they want to solve the problems they had identified.

Erik said the original idea for PI was to provide specific End Users with an option for their own space and that this came with some limitations. He said otherwise people could just become PI End Users and start sub-allocating to everyone. He said he thought allowing further sub-allocations on PI space would remove the distinction between members' and non-members' space and that this went against the reason PI space was created in the first place. He said PI actually had a purpose as it was, and if people had the requirement to do hosting services or sub-allocations to others, then they were basically a commercial entity within the role they had set for LIR-members.

Gert asked if Erik was saying they should abandon the proposal and keep PI with its current restrictions.

Erik noted that he had been one of the authors for ripe-583, “Removal of multihomed requirement for IPv6 PI”. He said he hadn't found any problems explaining to his customers that if they wanted their own IPv6 block, then it was for their own infrastructure and not to sub-allocate to others. He added that if his customers wanted to make sub-allocations, then it wasn't hard for them to set up a new LIR and get all the space they wanted. He said it was a non-issue and that they were opening a can of worms. He said allowing people to request more space and saying that if they go beyond that they had to go back to the RIPE NCC for documentation purposes was fine. He added that, however, the ability to sub-allocate was basically what made the difference between an LIR and an End User. He said there were contractual reasons that allowed some entities to request space without being an LIR and he said there were good reasons for that. He finished by saying that they were going a step to far and trying to solve too much in the policy proposal.

Elvis said they were basically trying to remove all the differences between members and non-members and to allow both members and non-members to get small blocks or big blocks.

Erik said that even PI End Users could request a /32 if they provided documented requirements.

Elvis said that they could only use this for their internal network and could not offer any kind of services to their customers.

Erik replied that it was for End Users.

Gert said they should stop this thread of discussion as there were more important things to cover.

Wilfried said he thought this needed another comment. He said that people could offer any type of services on the address space that they liked and that the only thing they couldn't do was transfer sub-sections of the address space for management by the customer.

Gert replied that this was not the interpretation of the RIPE NCC. He said that if someone ran an SSL virtual website with ten different customers on a box that used ten different IPv6 addresses, these addresses were sub-assigned to that customer and they were therefore not allowed to do that. He said the interpretation was very strict and they were not allowed to tag individual IPv6 addresses to individual customers.

Wilfried replied that this solved the problem. He said he wanted to come back to what Erik had said – that they were making it so anyone could get as many addresses as they liked and could decide whether to become a member of the RIPE NCC or get a free ride.

Elvis said it wasn't a free ride.

Wilfried said he was exaggerating for effect, but that this was where it was moving to. He said the longer the presentation continued, the weirder it was getting for him. He said if there were any provisions about size limits that required checking by the RIPE NCC, they at some point had to do away with the consequence that people could sub-allocate down to a /127, which didn't make sense and didn't work in his view. He said there had to be some point in the food chain where they switched from sub-allocation to assignment, and if people did an assignment, there had to be a block that could not be split up into smaller pieces. He said that from this minimum size you could then walk up the tree and say the RIPE NCC allows you to sub-allocate a certain amount of times this monolithic minimal sized block and then it started to make sense to talk about a /40 or /44 or whatever. He noted that he could not see the logistical consistency with requesting the right to chop a block down to a /127 or /128 even, and at the same time asking for funny limits where they wanted to have a second opinion. He said he didn't see how this would ever work and noted that in particular, with this structure that Eric had pointed out, that they would need multiple level contractual relationships for these sub-allocations. He said they then had to think about the mess with RPKI. He said it was completely broken.

Sander said that anyone who received resources either directly from the RIPE NCC or indirectly from a sponsoring LIR needed a contractual relationship. He said if people were sub-allocating address space to their customer, they were still routing the address space and it was like how normal LIRs operated currently so a contractual relationship didn't need to be forced at those levels.

Gert said they were hearing the Working Group's concerns. He said Elvis had a couple more slides to get through, and that the point of the exercise was to bring up things that might need more thought if they decided to go that way. He added that if the Working Group decided that it did not want to go in this direction because it was against the principles that they had been operating on, or it was too complicated, then this was good feedback. He said that after Hans Petter made his comment, they should go through the remaining items, so they had at least been presented to get the Working Group thinking and they would take it to the mailing list anyway.

Hans Petter referenced an earlier reply from Gert and said he was mixing allocation, assignments and routing and said they shouldn't be mixed. He said he didn't understand the earlier argument that if you had 100 data centres you should get 100 address blocks from the RIPE NCC. He said this made no sense and he was in agreement with Tore and Randy on that point. He said you needed one big block to assign to your 100 data centres that would grow to 200 data centres, and that this was much simpler to manage and it would still be 100 or 200 routes in the global table whether they were small or large blocks, so that argument was not working. He said they needed to take the routing considerations out of this and look at address management.

Gert said Elvis should continue to present the remaining issues and then decide how to wrap it up.

Elvis continued with his presentation.

Gert said he wasn't sure what to do now. He said the idea had been presented to the room five or six times and he had written a concept document that had received positive feedback on the mailing list. He said that now the current proposers had invested a lot of work into coming up with something and all he was now hearing from the room was “no, lets not go there.” He added that while this was valid feedback, he asked if it was time to step back and ask if this was the direction they wanted to go. He added that if they did not want this, then it could be abandoned for good. He said he would ask the room this question now and said he would ask the mailing list as well. He asked if they wanted the principle of abandoning PI and PA with the consequence of having members and non-members basically doing the same thing except for voting rights, or did the Working Group want to keep the policy they currently had and fine tune it.

Jan Zorz said he was a happy PI holder. He referred back to the earlier slide about fees and said he currently paid 50 euros per year for his PI space. He asked that they not make him unhappy.

Elvis replied that he was paying 50 euros because he had only one PI assignment.

Jan said this didn't matter. He said he paid 50 euros per year for one PI assignment and he was happy with this.

Elvis replied that he didn't want to use PI IPv6, because then he would pay 100 at least.

Jan said he had PI IPv4 and IPv6 and he was currently happy with this. He said suggestion number four on the slide (50 EUR pre /48, 100-200 EUR per /32, around 1500 EUR per membership) made sense to him.

Gert said this was a question to ask when they were sure they wanted to go in that direction. He said that right now he wasn't sure they had enough support to even ask that question. He said they needed to take a step back.

Hans Petter said they had a proposal that was so complicated that he couldn't understand it, introduced new constructs that they would have to name and build definitions for, and required changes to the contractual model of the RIPE NCC. He said this sounded like a large task and added that it was the RIPE NCC membership that would have to decide the payment structure. He said there had been discussion about the payment structure and it had been decided the previous year to have a one fee per member regardless of size, with the exception of PI resources. He said that this was what the membership had decided two years earlier and that while it could be changed back, if it was on the basis of a complex proposal he was concerned that it would not bring them anywhere.

Gert said they would not go to the AGM before they were sure they wanted to go there. He said this was just a consequence that needed to be cleared.

Erik said he had similar remarks to Wilfried. He asked that they not go back to where they had been in terms of billing structure. He said it should be kept as simple as possible, and the current process of having a 50 EUR charge per independent resource was adequate. He said if the payments were not covering the cost of dealing with independent resources, then the RIPE NCC would have to take this back to the GM. He said they shouldn't have a model where they paid according to size.

Elvis said Erik's comment was duly noted. He referred to Gert's earlier comment and asked if it was a good idea generally to do away with the distinction between PI and PA. He said over the past five years people had been saying they wanted the distinction to be removed and he wanted to some direction from the room about whether to go a certain way or to abandon the proposal and stick with PI and PA.

Hans Petter said he thought they should keep the distinction due to both the billing and contractual parts. He said PI space was for the End User and said they should not go into the trap of allowing them to sub-allocate.

Elvis said that PI users were already doing this, but it was just that the RIPE NCC could not track this.

Gert said they should just stick to what was possible according to the policy.

Elvis replied that right now, real world IPv4 PI users were offering services of hosting and even ISP services. He pointed out that with IPv6 PI, this was not allowed with the current policy they had. He finished by saying the proposal aimed to fix this.

Wilfried said doing away with the distinction between PI and PA was a very bad idea. He said all of the loose ends and potential impacts on the whole system were too dangerous and gave too little in return. He added that the most basic reason for PI historically was that they wanted to have RIPE NCC members to keep these organisations involved in internet policy discussions, so they created an option for an End User that just wanted address space without being involved in the discussions that gave them a cheap, dedicated and well defined resource to work with. He said that his understanding of End User and End Site was someone who didn't do any address management outside of their shop, in which case they were not supposed to sub-allocate, sub-assign, or transfer the address space. He said that for everything higher up the food chain towards the root, these people should become members and should become involved and responsible and should talk to the RIPE NCC if what they were trying to do with addresses exceeded the well established boundaries – whether this was the assignment window in IPv4 or the /48 limit in IPv6. He said he thought it was very useful to keep this system which had issues around the edges with things like not being able to register service end points for SSL and DSL for example. He added that if this was a problem, then they should go back to these particular problems and find the proper way to tell the RIPE NCC to do the right thing. He finished by saying that the solution was not to topple over the whole infrastructure and the whole registry system.

Sander said the reason they started this process was because of these issues with PI and hosting servers on there and mentioned that in the past they had discussed that the world was no longer as black and white as it used to be with service providers and users. He said there were companies running hosting centres, VPN services and others. He said the reason for loosening it up was because it was difficult to make policy in a fixed structure for a flexible world.

Gert said he heard what was said and he would bring it to the mailing list to ask whether it wanted to proceed or not. He said if the mailing list decided not to proceed, then there was no need to discuss the details in the fine print.

Tore said he was broadly supportive of the ambition of the proposal. He said there were clearly some devils in the details but added that he would support working on exercising those devils so they could find something that everyone could agree upon.

Tore said he also wanted to clarify his suggestion to the mailing list that everyone should become an LIR. He said he didn't mean that everyone should become a full paying member of the RIPE NCC but rather that they should receive addresses directly from the RIPE NCC just as a member did. He noted that the role of the sponsoring LIR was related to contractual and billing issues and said the address does not through the LIR route to the End User. He said what he was therefore thinking was that the policy could be simplified by basically not mentioning the sponsoring LIR concept and instead having this in a procedural document stating that people could either become members and pay the full fee or find some sponsored membership. He noted that if they didn't state this in the policy it became much easier to understand. He said that idea would therefore be for there to be something like an associate member.

Gert thanked the Working Group and said they could conclude the process for the time being. He said the action was on him to take it to the mailing list and ask if it thought they should proceed or not. He thanked the proposers for their time preparing and presenting the proposal and noted that even if they decided not to go ahead with it, it was worth making up their minds about what they really wanted. He said if that was the case, it wasn't a lost exercise.

There were no further comments.

X. Working Group Chair Selection Procedure

Sander said he had a few closing words as co-Chair. He said the collective of Working Group Chairs from all of the RIPE Working Groups had been discussing how they get appointed and replaced and at some point in the discussion they had asked if they needed an appointment procedure. He said he wanted to ask the Working Group for its thoughts.

Sander noted that there had been suggestions that a Working Group Chair get a three year term with an election at the end. He added that if no one stood for election, the Chair could just be re-appointed and continue as usual. He said there had been a lot of discussion around ensuring there wasn't too much bureaucracy, and so he was asking the Working Group if it thought they needed to improve this and if they wanted a procedure for appointments.

Wilfried Wöber, UniVie/ACOnet, said he was happy with the way they were currently doing business without any bureaucracy.

Erik Bais, A2B Internet, said he thought it would make sense to assign Chairs with a specific term and have a silent renewal, unless there were objections from the Working Group. He added that, on the other hand, there had already been a case where a Chair was asked to be removed. He said this was done through the GM, if he remembered correctly. He said if a Chair was working then there should be no reason not to re-elect them for their next term, but said he thought it did make sense to have a term on Chair elections.

Jan Zorz said he was currently happy with the Chairs of the Working Group, but said he still thought they needed some process of re-election because this was how Chairs could have credibility when they had to make a difficult decision.

Lu Heng, OutsideHeaven, said he was happy with the Chairs but added that he thought having elections was a good idea. He said he also thought it might give newcomers to the community a chance to become more involved and participate in the policy development process.

Hans Petter Holen, Visma, said he was thinking of how they had done this in the past and agreed it wasn't written down anywhere. He said in the past what they had done was to recruit more co-Chairs so that if there was one that wasn't pulling their weight there was at least two others who were, and added that this seemed to work. He said to give the Chairs more credibility they could select them for a term of two years and do this every year so it overlapped and they weren't replacing both Chairs in the same year. He said it could be as simple as asking in the Working Group if there were any volunteers who wanted to challenge the sitting Chairs, and if not, then was the Working Group happy with having the Working Group in question for another two years.

Sander said this was exactly the level of bureaucracy that he had in mind, as he wasn't happy spending time with a election using voting slips every meeting.

Elvis Velea, V4Escrow, said he agreed with Hans Petter that it was a good idea to have elections every few years. He said there was currently a document saying what the Working Group Chairs should do and what their responsibilities were, and said maybe they should look into updating that document.

Sander said the Working Group Chairs collective would work on the details and he was just looking for feedback from the room.

Gert closed the session and thanked the Working Group for its feedback. He added that he would be bringing these questions to the mailing list and said he hoped to see them all in Warsaw at the next RIPE Meeting.