RIPE 61

Address Policy Working Group Minutes from RIPE 61
Status: Final
Revision Number: 1.0

Co-Chairs: Gert Doering, Sander Steffann
Scribe: Xavier Le Bris

• Session I – 17 November, 9:00 – 10:30
• Session II – 17 November, 11:00 – 12:30
• Session III – 18 November, 9:00 – 10:30

Session I – 17 November, 09:00 – 10:30

A. Administrative Matters

Gert Doering (WG chair) opened the session and presented the agenda. There were no changes in the agenda.

The minutes from RIPE 60 were approved and are now final.

Gert Doering (WG chair) thanked Filiz Yilmaz (former PDO) for her past work and wished her best luck in her new function

B. Current Policy Topics – Emilio Madaio, RIPE NCC

The presentation is available for download at:
http://ripe61.ripe.net/presentations/186-CurrentPolicyTopics-RIPE61.pdf

There were no questions.

C. Document Cosmetic Surgery Project - Emilio Madaio, RIPE NCC

The presentation is available for download at:
http://ripe61.ripe.net/presentations/187-DocCosSurgProjectRIPE61.pdf

Rob Blokzijl (RIPE Chair) explained to the attendees how the current Cosmetic Surgery Project started and that its purpose is to clarify ambiguity in existing policies.

Emilio agreed.

Rob added that it would be better to have the cosmetic surgery process performed first on new proposals, then on existing policies that survive more than half a year.

Gert Doering (WG Chair) commented that in the current impact analysis taking place during the Policy Development Process, there is a section related to the policy implementation understanding and what is unclear would be evident also at that stage.

Sergi Polishchuck (UA-IX) asked if the Cosmetic Surgery Project would be used to unify the three existing IPv6 policies.

Emilio Madaio (RIPE NCC) responded that the document already exists and will be updated after RIPE 61 with the latest feedback received during the meeting. He reaffirmed the need for the community to send their feedback.

Gert Doering (WG Chair) mentioned that the certification policy proposal discussion would take place in Thursday's session and that some background information was included in the meeting pack. He added that discussions on the closure of LIRs and de-registration of address space would take place during the RIPE NCC Services Working Group.

D. Rough Edges of the Current Policies - Alex Le Heux, RIPE NCC

The presentation is available for download at:
http://ripe61.ripe.net/presentations/313-ripe61_apwg.pdf

Gert Doering (WG Chair) stated that there was not a clashing of policies as one rule applies for solely resources transfer and the other document applies for business transfer.

Alex Le Heux (RIPE NCC) responded that you can buy a business unit of the LIR or you can buy a service from an LIR.

Gert Doering (WG Chair) added that it was a sort of business transaction.

Alex Le Heux (RIPE NCC) further said that it is a different transaction.

Gert Doering (WG Chair) clarified further that it is about IP addresses being transferred under some different sort of contracts.

Alex Le Heux (RIPE NCC) agreed.

Rob Blokzijl (RIPE Chair) remarked that the standard reaction to problems is to make a policy. However, you can create policies that will still generate chaos because people will try to find ways to go around them. He also said that the transfer policy should be in place not to restrict, but more to facilitate the registration of address space.

Rob also mentioned that the future challenge is to maintain a correct and complete registry of Internet resources. All operational decisions are based on the accuracy of the registry.

Gert Doering (WG Chair) said that originally the transfer policy was restrictive to avoid abuse of the IPv4 policy. He said that a small group of volunteers would help to solve the discrepancies.

Rob Blokzijl added that in the future the RIPE NCC would certify resources to be part of the Registry. Unfortunately, there is no definition of “the Internet Protocol resources registry”.

He added that a technical document that defines the registry was drafted with the RIPE NCC and that it would be presented to the community for comments.
He also added that the goal of the document would be to update registry information.

Gert Doering (WG Chair) agreed on the necessity to have the definition in order to avoid policies being ignored.

Sander Steffann (WG Co-Chair) asked what was the timeline for the definition document.

Rob Blokzijl (RIPE Chair) replied that the document would be presented for comments before the end of the year.

Sascha Luck, over Jabber, commented that he fully agreed with the drafting of the definition.

Geoff Huston (APNIC) commented that the APNIC community began drafting documents that reflect the registry once IPv4 distribution is over back in 2006. . In relation to the transfer of allocations after the last /8s are distributed, there will be no transfer restrictions. And the fewer policies to handle the situations, the more useful the registry will be. He agreed with Rob in the defining the registry with a proper document.

John Curran (ARIN) reminded the working group of the importance to reflect on the purpose and the function of the Internet Registry system. In the ARIN region, the framework is different than APNIC's. In merger and acquisitions, only the resources used can be transferred. The unused address space should be returned to the RIR. There is a specified transfer policy when a party qualifies for address space and the RIR does not have it available. It is still on a needs-only basis (RFC 2050) and allows another party to transfer resources to the one in need. He commented that we all should consider how all these RIR frameworks interact with one another.

Rudiger Volk (DTAG) asked John Curran if the transfer of allocation procedure was already used.

John Curran (ARIN) replied that, in theory, it could be used. However, since ARIN's pool of resources is not depleted yet, the procedure is not currently in use.

Hans Petter Holen (Visma IT) commented that there have been several references to RFC2050, and that we needed to better understand what the status of that RFC is. He said that updating it was discussed in the past, but the idea was abandoned because the IETF no longer had a role in address space. He said that it would be an interesting discussion to have when we move into the new world, because some of the wording maybe not be directly applicable any more.

Wilfried Woeber (Vienna University) commented on the potential interaction between RFC from the IETF and the policy from the RIR. He also mentioned that the IETF might be taking a new role in the IPv4 address architecture without interacting with the Internet registry.

Gert Doering (WG Chair) replied that it was out of scope in regard to the transfer of allocation policy issue.

Owen Delong, (Hurricane Electric) stated that the RFC2050 is one of the IETF documents that delegates the number policies and processes to the to RIR system.

Gert Doering (WG Chair) said that the way forward is to wait for the registry definition document from Rob and then a small group of volunteers would begin working on the transfer policy documents and get this into the formal process. He added that they would look at ARIN and APNIC policies, and the mailing lists for input.

E. “More Rough Edges of the Current Policies” - Gert Doering

“Things that have come up in various forums”

Gert Doering (WG Chair) said there had been some discussions on policy interpretation on the <IPv6OPS@cluenet.de mailing list. Specifically, it was about the "utilisation threshold" and the assignment size wording in the IPv6 policy being misleading. Gert said that in the list, Arno Meulekamp (ISOC) suggested a text clarification that takes out the wording “sites” and adds wording about “address utilisation in terms of assigned address space in units of /56”.

Gert asked for input from the audience – whether or not this required a change of policy, he said he didn't think so, o r just a matter of clarification. If the latter, it can be added to the Cosmetic Surgery Project. Gert said he'd also ask this on the mailing list.

Owen Delong (Hurricane Electric) replied that it was not a policy change but a clarification. He felt that Arno's suggestion didn't provide enough clarification and that the wording had to be very clear that you are counting /56 blocks in such a way that assigning a /48 is okay and counts as 256 of them. Even then, he said, there's still the possibility for people to perceive it incorrectly. He said it was a risk as people start considering how to design CPE. He added that he'd rather see /48 as the standard and there are more than enough to do that.

Gert Doering (WG Chair) asked the RIPE NCC Policy Development Officer to take what was being said and turn it into more understandable text.

Rob Evans (Janet) supported Owen's comments.

Sander Steffann (WG Co-Chair) asked if replacing the misleading part with "larger assignment will be counted as multiple /56s" would solve the problem.

Gert Doering (WG Chair) commented that this will make it more explicit and mentioned that the wording clarification will be discussed further on the mailing list.

“End Site” Definition in ripe-481, section 2.9. – Sander Steffann (WG Co-Chair)

Sander said he'd spoken to some people who had problems with the text that defines an “End Site.” He quoted the text: “An End Site is defined as an End User (subscriber) who has a business or legal relationship with the service provider.”
Sander said they questioned what happens when there's one customer that has two separate hosts with two DSL connections: are they counted as one End Site or two? Sander said that the current implementation at the RIPE NCC is that if you have two connections to two different locations, that those are two different sites. He thought that the RIPE NCC Registration Services Department was implementing it correctly, but that he'd like input from the audience on whether the policy was clear enough.

Wilfried Woeber (University of Vienna) commented that he didn't think there would ever be a proper definition of an End Site because there is no such thing. He said that his LIR has one governing contract for nine regional school networks in Austria, which are on the separate operational control by different layer 2 and layer 3 service providers. If he applied the current definition of “End Site”, that would mean he'd only have one, and that would never work. Wilfried said that he interpreted “End Site” as an entity that makes its own address plan within the block of addresses that they get.

Sander asked if Wilfried was essentially agreeing that the RIPE NCC was doing it correctly.

Wilfred nodded in agreement

Rob Seastroom (ARIN AC) said that if they are trying to conserve IPv6, which is why they wouldn't simply hand out one End Site for every DSL connection, then they are trying to optimize for the wrong thing. He added that they should try to optimize (the definition) for operational simplicity, and that therefore, there is nothing wrong with the current way of handling it.

Sander Steffann (WG Co-Chair) asked the audience if the text needed to be changed, if it should be clarified as part of the Cosmetic Surgery Project or if it should just be left as is. No hands were raised and Sander said it would be taken to the mailing list.

Gert Doering (WG Chair) ended the discussion by saying that it will be posted on the mailing list. However there were no strong feelings about the current interpretation.

Session II – 17 November, 11:00 – 12:30

Gert Doering (WG Chair) welcomed everyone back to the second session. He said that in this session, they'd go into specific proposals already in the PDP (especially 2010-01, 2006-05, and 2010-07) and then broaden the scope in a more generic way. He added that the focus should be on the general framework, not specific wording.

Gert reminded the audience that the Address Policy Working Group doesn't make decisions in the meeting; they get feedback and bring the discussion back to the mailing list so it's open, documented and transparent – one of the pillars of the APWG in the RIPE community. He added that people coming up to the microphone should state their name for those participating remotely, as well as for the scribe.

G. Discussion of Open Policy Proposals, Not “PI-Related”

2010-01 Temporary Internet Number Assignment Policies [ONGOING] – Nick Hilliard

The presentation is available for download at:
http://ripe61.ripe.net/presentations/317-inex-ripe-rome-apwg-tempassignments-2010-11-17.pdf

Nick asked the audience if anyone was of the opinion that temporary Internet assignments should not happen, that it's a bad idea or policy proposal. Hence all this should not happen.

Raymond Jeutten (Elisa Oy) asked what was the size of the block reserved for temporary assignments.

Nick replied that a /13 was reserved. He also asked a confirmation from the RIPE NCC Registration Services.

Alex Le Heux (RIPE NCC) confirmed that a /13 was reserved for it.

Marco Hogewoning (XS4ALL) commented that he was one of the people supporting removing the time period from the policy proposal for temporary assignment because it was too strict.

Gert Doering (WG chair) replied that the policy proposal wording changes would mean a new review phase. He asked if the policy proposal changes could be done after reaching consensus.

Marco clarified that he agreed with pushing forward the proposal and fixing the wording later.

Nick Hilliard (INEX) apologised for pushing the discussion on the policy proposal, adding that it was necessary given the current rate of IPv4 depletion (estimated run-out date of June or July 2011 not realistic). He added that they would bring it to the mailing list for more input.

Gert said that they'd summarise the discussion and announce last call on the mailing list. If people disagreed with what was going forward, they could disagree there.

H. Discussion of Open Policy Proposals, “PI-Related”

2006-05 PI Assignment Size [ONGOING/REVIVED] – Nick Hilliard

The presentation is available for download at:
http://ripe61.ripe.net/presentations/318-inex-ripe-rome-apwg-minassignments-2010-11-17.pdf

Gert Doering (WG Chair) thanked Nick Hilliard for taking over the abandoned policy proposal, as it is not an easy one. He also asked Alex Le Heux from the RIPE NCC to talk about the impact analysis on the implementation of such a policy proposal.

Alex Le Heux (RIPE NCC) showed PI statistics for 2010: Registration Services issued 930 /24s and 15 /25s. He said that there was a huge gap, something is wrong, and that this proposal might help with inflated requests and they'd like people to be honest with them. He added that the proposal would help the last few that think this proposal is already in place.

Wilfried Woeber (Vienna University) said that if this proposal goes ahead, he strongly suggests getting rid of having to prove to the IPRAs the need for eight addresses, the need for standby routing, plans and so on. He added that people always find ways to get a /24, and we should accept that and make the whole process simple and cheap for everyone involved. If you apply for PI, you get a /24, full stop.

Gert said that the question is what happens when people come back for a second or third /24.

Nick Hilliard (INEX) asked Wilfried Woeber if his suggestion is to move it not /29 but to /32.

Sergi Polishchuk (UA-IX) commented that he got a /27 PI as a customer and has a lot of problems with routing such a small prefix, and that he pays the same fee as a /24. He said it doesn't make sense to give smaller prefixes – it will create problems for the End User, and he will continue to lie to get a /24.

Nick Hilliard (INEX) acknowledges the point and stated that the proposal is meant to help users like Sergi.

Rob Senstroom (Afilias) emphasized that with the current policy proposal there would be a very good effect of increasing the level of honesty between LIR and RIR. Which would lead in a better stewardship of the resources.

Wilfried Woeber (Vienna University) replied to Nick Hilliard that his suggestion is to set simple criteria for applying PI /24 assignment. He also added that for additional address space the requester would have to provide an addressing plan.

Nick Hilliard (INEX) agreed that the wording in the policy proposal and the subsequent PI assignments would need to be a clear set of criteria.

Gert Doering (WG Chair) asked Alex Le Heux (RIPE NCC) what he thought made sense: a suggestion like Wilfried's (you ask for it, you get a /24), granularity of /24, no smaller bits and pieces of assigned PI? He asked what is less work and what is more problematic.

Alex answered that, in practice, the request where there is a real need for less than eight IPs is very rare, so functionally, both versions will work the same way and then, perhaps, just setting the granularity at a /24 is maybe a bit cleaner in policy text but functionally they'll be nearly identical in practice.

Gert said that they are at the end of the review period and then the decision has to be made whether there is consensus to go to last call. He added that he didn't think this was the case yet because of too many concerns about specific wording. He suggested taking the comments received during the session into account and make a version 2.1 with adjusted wording that takes into account Wilfried's suggestion with /24 granularity, do a short review phase of two weeks and if everyone agrees, go to last call and implement it before the end of the year.

Nick Hilliard said it thought it was a sensible approach and a new version would be posted to the mailing list.

2010-07 Ambiguity Cleanup on IPv6 Address Space Policy for IXPs [NEW] – Sergi Polischuk

The presentation is available for download at:
http://ripe61.ripe.net/presentations/316-apg-ripe61-polishchuk-20101117.pdf

Gert Doering referred to the wording of the policy: an Internet Exchange Point is defined as “a physical network infrastructure layer 2, operated by a single entity whose purpose is to facilitate the exchange of Internet traffic. And there must be a minimum of three ISPs and there must be a clear and open policy for others to join". He said that prior to the session, he talked to the original authors of the policy to figure out the meaning of the wording and whether it was a misinterpretation or misguided. He said that there was a disagreement on what is meant by “open”. He said that one of the authors (Leo Vegoda, ICANN) says that “open” meant “openly documented”, so you can find out about the policy, but there are limitations because every IXP has restrictions. The other author, Timothy Lowe (RIPE NCC) says that “open” means “open to anybody”. So, there's a problem. The RIPE NCC interprets open as “open to anybody”, so they couldn't get a prefix. Gert said that all that can be done now is either agree on what “open” means or change the text.

Rob Blokzijl (RIPE Chair) said that Sergi gave a good presentation of his problem.

Sergi answered that he wasn't the only one with this problem.

Rob Blokzijl (RIPE chair) congratulated Sergi for the clear presentation and analysis. He added that the issue was related to the word "open" and that no exchange point in the world it as totally open as the authors might think.

He also expressed his disappointment that RIPE NCC is allocating address space with such an interpretation. He added that the RIPE NCC has to solve the issue internally. Regarding the change of text he added that helping the community and clarifying misinterpretation of policies is needed in the current situation.

Gert Doering (WG Chair) agreed.

Rob Blokzijl (RIPE chair) said he was worried for UA-IX if this had to go through the whole 19-week PDP process. He urged the community to solve the editorial problem ASAP and that the RIPE NCC to find an immediate solution. .

Alex Le Heux (RIPE NCC) mentioned that the community guidance on the policy interpretation was very helpful for the Registration Services Department. He took the example of the 80% rule ambiguity that was clarified in previous discussion. He mentioned that any text clean up in the normal Policy Development Process is a separate purpose from this.

Rob Blokzijl (RIPE Chair) said there were two action points. The first one was for the Address Policy Working Group to find a better definition of “open” to make it possible to give to all exchange points, including those already received. The second action was on the RIPE NCC to realise that the situation in Ukraine is not different from many other exchange points that have received an allocation, and they should find a quick solution to this problem.

Alex Le Heux (RIPE NCC) said that the RIPE NCC doesn't deny many requests under this policy. In the cases where requests are denied, it's usually because existing members had to vote on whether a new member could join or not. He asked the Working Group to clarify the correct definition of “open” in this case.

Rob Blokzijl (RIPE Chair) replied that in the RIPE NCC service area, there are 60-70 countries, each with their own cultural and legal differences, and these should not be stumbling blocks. He said that the RIPE NCC was a membership organisation. He said the issue was an administrative one and it should be fixed ASAP. He added that there were two aspects: get the exchange point going again and fix our definition of the rules. He also brought up a previous slide on existing IPv4 practices and said there was a lot of dirt there. He asked the RIPE NCC to consider doing internal analysis on how that happened, how it could be cleaned up, and whether it's important enough. He said he personally didn't care, but that it should be picked up since it was presented.

Alex Le Heux (RIPE NCC) replied that they are direct assignments for ISPs that don't exist anymore and they will be covered in Phase Three of 2007-03.

Nurani Nimpuno (Netnod) agreed that the term “open” was unclear. She said it was quite common for exchange points to have requirements such as an AS number, and that several exchange points today get addresses where members have to prove new memberships. Nurani added that she thinks there should be separation between the openness of becoming a member and actually getting peering at that exchange point – they are two separate things.

Gert Doering (WG Co-Chair) asked if what it meant was the permission to connect even if nobody wants to peer with you,

Nurani affirmed that that was her point.

Hans Peter Holen (Visma IT) suggested that the wording could be "openly published" for others to join and this is advice that should be given to the RIPE NCC to clarify the text. He also added that the Norwegian IXP had the clause that you needed to have the intent to peer with everybody on the exchange in order to be allowed to join. He asked how that was “openness”.

Gert Doering (WG Chair) replied that it was openly documented but certainly not open to everybody.

Keith Mitchell (ISC) commented that his interpretation of “openness” is “openly documented”. He said that Internet Exchanges in Europe are much more open now than they were in 2001. He didn't think that enforcing the policy the way it's been enforced in the past makes any sense. He said the main issue is that there are many Internet Exchange operators in Europe who don't have open membership policies or connection policies that have received prefixes in the past. He said he didn't think it was RIPE's role to dictate what the policy of exchange operators should be in terms of participation. He added that incentives for openness were good, but also wondered what does it have to do with IP address stewardship, particularly for IPv6 where we are trying to encourage deployment rather than restrict scarcity. He supported the alternative option of ‘openly documented'.

Martin Hannigan (Akamai and member of Links Endorsement Panel) said that “open” here meant demonstration of being an IXP. He added that once a need was established, that should be good enough. He said there was no need to get involved in IXP policies or requirements. He added that the changes should be part of the Cosmetic Surgey Project and the RIPE NCC should treat it as such.

Lorenzo Colitti (Google) said that from a linguistic point of view, he has difficulty imagining how an exchange point that decides whether people can join or not can be called “open”, so if that's the interpretation, let's change it to public policy as in “clear” or “accessible”, because that's not what “open” means. He said that if a group can say “we are going to exclude you”, then that is not open. He proposed changing it to “public”.

Emilio Madaio (RIPE NCC) mentioned that the RIPE NCC thought about replacing "open" with “there must be a clear and transparent policy for others to join."
He asked the community to state in the meeting and in the mailing list if it was a substantial change or if it should be considered as part of the Cosmetic Surgery Project.

Gert Doering (WG Chair) said that "transparent" worked as a replacement of "openly published".

James Blessing (Limelight) asked if there could be two cosmetic changes. The first one was to replace "open" with "published", and "ISPs" with "networks".

Gert Doering (WG Chair) commented that things have changed since the policy was written. He said clauses were included (what defines an IXP), there was no PI, and that people were afraid the policy might be abused as a way to get PI in IPv6 and that's why we're in this mess today. Stopgaps were in the original policy to stop abuse of the policy. He added that from what he heard today, not a single person said that an IXP should be open to everybody. He asked for agreement in the room that open mean “published and well-documented” and not “open for everybody to join”. He asked Alex Le Heux if this was enough guidance.

Alex Le Heux (RIPE NCC) agreed.

Gert Doering (WG Chair) closed the discussion by adding that the text cleanup will happen at a later stage.

I. Even More Rough Edges of Current Policies – Presentations & Discussions

PI Background Information – Alex le Heux, RIPE NCC

- Background information about PI size distribution and its history (growing assignments)

The presentation is available for download at (part II):
http://ripe61.ripe.net/presentations/313-ripe61_apwg.pdf

Gert Doering (WG Chair) said that an on-and-off issue is the difference between IPv4 PI and IPv6 PI. The basic idea behind them is the same: if you want to be independent of any provider, you get PI space. In reality, it's more complex. The IPv4 policy has a very explicit cause that says if you want to number the interconnect network to somebody else's network with PI space, that is fine, which means “numbering the other party's router with your PI space is fine”. This got interpreted as “you can run a whole DSL network with ten millions of different customers on PI space because in the age of NAT, the only thing you do is number the other person's router”. He said this interpretation hadn't been challenged and it's common practice in IPv4 now. There are providers that run on PA space and others on IP space. This was before IPv4 was running out. Gert said that they aren't going to change the IPv4 PI policy. Now, networks want a block of IPv6 PI addresses to run their business and the RIPE NCC turns them down saying there's no such clause – if you want to number an ISP network and give your customers addresses, do it properly and get a PA allocation, become an LIR, give them /54 or /56. Gert said this was a good thing and you shouldn't give single IPv6 addresses to End Users.

Gert said that the other aspect is that v4 PI is “ask and get it”, and v6 PI requires intent to multihome. This has brought up discussions on how strict the RIPE NCC should be, how they can verify multihoming. It's part of a stopgap measure to prevent the floodgates from opening.

Gert said that another issue is hosting providers, are you permitted to use PI space for that or not? He mentioned scenarios about virtual machines and what happens when the customer buys the machine and you aren't permitted to sub-assign PI. He said that it's a tricky issue and it's been under discussion for three or four RIPE meetings and on the mailing list. He said people seem unhappy about it, but not unhappy enough to put in a formal request to change it.

Gert said that there are differences and if we didn't like it, it could be changed. He invited Alex Le Heux to show statistics from the RIPE NCC about how these differences played out in the past.

Alex Le Heux shared statistics on v4 and v6 PI. He said that the average size of a PI assignment has doubled over the last five years from a /23 to /22. Meanwhile, the average size of a PA allocation is much larger. He said that a little over 30% of LIRs have an IPv6 allocation. He said it's not always clear how many PI assignments one organisation holds, but that the 2007-01 project is helping to make that clearer. In response to the differences in policy, Alex said IPv4 PI requests were evenly spread: one third are access providers, one third are hosting providers, and one third are End Users/End Site type of organizations. We had requests from small hosting providers who had IPv4 PI came to RIPE NCC eager to use the new IPv6 PI policy to deploy IPv6 and we had to deny these requests.

Gert opened the discussion by mentioning that in his opinion it does not mean there is a problem. There is a difference in policies because we put it there. If everybody agrees that this should be the way, then we're fine.

Owen Delong (Hurricane Electric) said it's important that providers assign more than a single IPv6 address to their End Users and that using the PI policy to do DSL networks in IPv4 was a perversion of the policy and that there's no reason to bring that forward to IPv6.

Gert Doering (WG Chair) agreed with Owen and said the benefit of IPv6 is there is enough addresses to assign network blocks to End Users, rather than single addresses.

Wilfried Woeber (Vienna University) commented that there are entities in the real world that don't easily fit into the definition of an ISP, but they have a valid right to deploy PCP IP-based technology and a right to be part of the global management of the unique resources. One such example is organisations working in the health services industry. Wilfried said there are discussions on how to mutually understand what the other side of the game is doing and expecting. He said there are more rough edges in the policy wording that eventually triggers IPRAs to do things that they didn't' expect to happen when they wrote the policy. He said there were many things to keep in mind when doing the Cosmetic Surgery Project. He recommended that when new policies are developed, that it not be set in stone to allow for adapting to industry developments.

Alex Le Heux (RIPE NCC) said that the Internet is constantly evolving and that they see that by the changes in requests received (like virtualisation). They are now dealing with things that didn't exist ten years ago.

Gert Doering (WG Chair) commented that that's why Alex constantly volunteers to bring insights from the RIPE NCC's day-to-day business. He added that you don' t have to be an independent provider to get LIR address space. He suggested that maybe the wording “provider aggregatable space” is misleading. Gert clarified that you don't have to be an Internet provider, you have to sign the papers; there are lots of organisations who are not classic providers but get PI to fit their needs.


PI Differences between IPv4 and IPv6 – Discussion chaired by Gert Doering

Alex Le Heux (RIPE NCC) presented slides on the differences between IPv4 and IPv6 PI assignments. The IPv6 PI assignment policy requires an organisation to demonstrate that its multihomed; this is also a requirement for AS numbers. They check the request form and look if there's something funny going on with regards to peering. If it's suspicious, they ask questions. In practice, if everything looks normal, contacting peers would add huge delays to processing requests.

Alex said that they check the request three months after the assignment to make sure it's multihomed. For both AS numbers and IPv6 PI, a little over 50% are not multihomed after three months. They then contact people to remind them that multihoming is a requirement, it's in the policy. Six months after the assignment was made, more than 20% still aren't multihomed.

He commented that as that time period grows longer, it puts the RIPE NCC in a strange position, especially with IPv6 PI because they need to deploy it. They see what appears to be a violation in policy, and that pushes them towards thinking that if people can't comply with the policy, then they need to hand back their resources. On the other hand, it seems a strange thing to tell people they seem to be deploying it, but haven't finished it, so pull it all back. Alex asked for input from the audience.

Rudiger Volk (DTAG) asked what the criteria was for figuring out if an organisation was multihomed and if it was sufficient to be with two AS numbers not connected globally?

Alex Le Heux (RIPE NCC) replied that the RIPE NCC checked with RIS system for two separated AS numbers. The RIPE NCC was flexible and if only one peer appeared then the registration services accepted the reason like "I am currently single homed because we have no exports yet".

Wilfried Woeber (Vienna University) commented that in the long run, the RIPE NCC would be in a difficult position, but potentially, so will the holder of the PI space. He said that if there is a situation where the address block was once multihomed and then you lose one of your peers, the RIPE NCC could do a check and see there's no longer multihoming and you' d have to give your resources back. He said some organisations do their planning for longer timescales and that this completely invalidates the concept of PI. Wilfried gave the example of a university or hospital moving on to a different type of connectivity and being asked in the future to give back their IPv6 space and move to a different PA. He said this was from the perspective of the customer.

Alex Le Heux (RIPE NCC) acknowledged Wilfried's point and stated that this was the reason why he was looking for feedback.

Geoff Houston (APNIC) said that he was confused and that there was no such thing as RFC 1918 space in IPv6.

Gert Doering (WG Chair) replied that there is ULAs.

Geoff said there was no reserve blocks he could use and that he could normally come to the RIPE NCC and request some space.

Gert replied that there are ULAs.

Geoff replied that if he chooses not to use them because he wants a unique numbered block, he then comes to the RIPE NCC to get PI space for private use and he would then have to demonstrate multihoming.

Alex Le Heux confirmed this was one of the policy sets.

Geoff asked Alex how he could demonstrate this.

Alex replied he didn't think he could.

Gert Doering (WG Chair) said that under the current policies you get PI space if you demonstrate you need it and actually do something about it (multihoming). So, if you want to use globally guaranteed unique space for non-Internet purposes, this policy doesn't cover that.

Geoff asked Gert if he was saying that if he wanted to have assured uniqueness for private use of IPv6, there is no clear way of doing this within the RIPE NCC's policy framework.

Gert Doering (WG Chair) replied that there was no way.

Geoff thanked Gert for resolving his confusion.

Gert said IPv6 policy people say BGP multihoming is needed.

Geoff said he wasn't making a value judgment, that he was just trying to see if there was a gap or not.

Raymond Jeutten (Elisa Oy) added that in the IPv4 policy to get a PI space it is not allowed to have multihoming as the only reason .In IPv6 you have to be multihoming. He asked Alex Le Heux what happens for organisations with dual stacking if you had to be multihomed to get IPv6 PI space.

Alex Le Heux (RIPE NCC) replied that in IPv4 multihoming is not allowed as the only reason to request additional IPv4 space. So it was not possible to inflate the request for routing reasons. He added that IPv4 PI policy was flexible, broader and different from IPv6 PI Policy. Routing and sub-assigning reasons were not allowed in the IPv4 policy. IPv6 policy is more centered around the reason of BGP-based multihoming as most of the people requested.

Gert Doering (WG Chair) said that if anyone feels that the gap in the current IPv6 policies are big enough to cause problems for people and it's worth changing the policy, to come and speak to the Working Group Co-Chairs, to Emilio Madaio, and bring up a proposal. He said to expect some resistance, as the PI policy has been a difficult one and it's restrictive because that was the only way to get it done. He closed the session.

Session III - Thursday, 18 November 2010

T. Discussion of Open Policy Proposals, Part 3 (Older ongoing Proposals)

The session was opened at 09:00 local time.

2010-05 – Global Policy for IPv4 Allocation by the IANA post exhaustion [NEW] – Jason Schiller et al.

The session is available for download at:
http://ripe61.ripe.net/presentations/320-RIPE61-2010-5.schiller.pdf
Owen Delong (ARIN AC) explained that the current ARIN policy wording concern was related to requests that would be above the minimum allocation size because they would not be satisfying a request larger than the minimum allocation size. If that minimum allocation size was larger than the minimum of other RIRs, they would not be considered eligible according to the text.

Jason Schiller (ARIN ASO AC) replied that the intention of the original text is that if there was a request that couldn't be fulfilled, then they would be considered exhausted. If ARIN was holding /25s, and someone came in and asked for a /24 and ARIN had to turn them away, that would be an inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum. Because they are turning them away, they are unable (to fulfill the request) per local regional policy.

Owen Delong (ARIN AC) said that wasn't how they interpreted it, and that the wording was very ambiguous. He said they interpreted it to mean we would not be able to satisfy any request equal to or shorter than the minimum allocation size in order to qualify as exhausted, not “we would not be able to satisfy an existing request.”

Jason Schiller (ARIN ASO AC) said that was certainly not the intention of the policy.

Owen Delong (ARIN AC) stated that this was what the text said.

Martin Hannigan (ARIN ASO AC) commented that an RIR in that situation theoretically could also lower their allocation unit to address that problem.

Jason Schiller (ARIN ASO AC) said it was important to know how the community feels about both texts because there are procedural issues to consider. If the community reaches consensus on different text, then the ARIN community, then the NRO EC, and then the RIR's staff members will have to do a rewrite and decide if the text is substantially changed or just clarified. He urged a discussion of the matter and to make sure that the NRO NC members are aware of how the community feels about the rewrite. He then asked for discussion.

Hans Petter Holen (Visma IT) said he didn't find any of the text clear as a non-native English reader. He said that could be an issue with these global policies, and that we need to make sure that the language is very clear.

Volkmar Jurgens (over Jabber) wanted to know how to return address space from address blocks that no longer exist,

Jason Schiller asked if it was legacy space.

Gert Doering said he thought it was URX space, pre-RIR. He said the question should be “Do we have procedures if somebody says there is a /16 laying around?”

Alex Le Heux (RIPE NCC) replied that the best was to contact RIPE NCC or their local RIR to find out what the procedure is.

Gert Doering (WG Chair) said that the resource holder is in the RIPE NCC service region, but that the address block was not assigned by the RIPE NCC because it's legacy space. He added that this issue was out of scope of this policy because it's about RIRs giving back to IANA. Gert asked what the chances were of LACNIC going forward with this because if LACNIC says they don't want to have this, we don't need to spend time on this in the RIPE NCC service region.

Jason Schiller (ARIN ASO AC) replied that LACNIC didn't discuss this policy proposal because they had reached consensus on the previous one and this one wasn't just an update. He added that they should restart the discussion because the NRO NC has officially abandoned the former policy proposal.

Wilfried Woeber (Vienna University) commented that he was puzzled by arguments in this region that the community feels it is unable to modify text once consensus has been reached. He added that this was a local problem and that each region is free to come up with its own procedures and update them accordingly. He acknowledged that this might mean slower progress within the PDP timeframe, but that he still considers this a LACNIC regional problem. He said if it's not going to be solved regionally, then the whole global PDP falls apart.
He also commented that Jason used the term “globally coordinated policy” as a synonym for “global policy” and that they should be very careful here because a “globally coordinated policy” is not better than any regional one because it's not channeled through the global PDP and ICANN Board of Directors. Wilfried gave the example of IPv6 policies, and that although it was a globally coordinated policy, RIRs still had the freedom to modify individual components.

Jason Schiller (ARIN ASO AC) urged Wilfried Woeber to bring this topic up again when the globally coordinated transfer policy is discussed.

Hans Petter Holen (Visma IT) asked if the policy of returning address space to IANA and the policy for distributing address space from IANA needed to be in the same document.

He added that the return of address space could be a regional policy and the distribution of address space could be a global policy.

He supported the global policy as it excluded the mandatory return from the text. He also added that it was in the scope of the regional policy and needed to be implemented quickly. He also mentioned that so far there were no real ideas about how to return and re-assign address space. He said that the process depended on the request coming in. He asked if the returned address space goes back to the IANA pool or to the RIR pool. He said that it would be unfair to have one RIR with a lot of returned address space while other RIRs would move to IPv6, it had big chances to break the Internet. He urged the community to reach consensus quickly with the current global policy rather than focus on minor regional differences.

John Curran (ARIN CEO) replied to Hans that the policy of returning space to IANA and the policy for issuing space that's returned from the IANA back to the RIR did not need to be tied. He added that in the ARIN region, the policy 2009-03 tied them together as it was considered as a whole matter. He also said that it was up to the RIR to tie them together or not. He added that the global policy was needed in order to allow IANA to redistribute return address space otherwise any space returned to the IANA is effectively lost.

Gert Doering (WG Chair) said he heard good arguments on why the community wants to go forward with the policy, though were was some concern on the mailing list (and support), so wording changes are necessary to make the RIPE community happy. He pointed out that the version of the policy up on the screen is not the latest version. The new version will be published and discussed on the mailing list. Gert Jason Schiller and Martin Hannigan for going to the five RIRs and trying to get everyone to agree on something global.

2008-08 Initial Certification Policy for PA Space Holders [ONGOING] – Nigel Titley, CA TF – Version 2 Update

The presentation is available for download at:
http://ripe61.ripe.net/presentations/319-2008-08.pdf

Rudiger Volk (DTAG) commented that there were no responses to this proposal on this on the mailing list and that he wanted to see it pushed forward. He said that he wanted the details to be correct and even with this short version, there are a few clauses that need to be looked at more closely. He gave an example of text that refers to LIRs in the RIPE NCC service region said it didn't matter where it was located as long as it was a member.

Nigel Titley (RIPE NCC Executive Board) agreed.

Rudiger Volk (DTAG) said that a lot of related documents were in still in drafting stage. It included the pending certificate policy in IETF. He added that the Certification Practice Statement (CPS) was related to the Certification Policy.
The drafted CPS looked nice but needed some wording clarification. Also, there is overlap between them. He also stated that he was happy to see the Closure of LIRs policy document to clarify the unified rule of revocation. The Certification policy document revocation could mention the closure of LIR document.

Nigel Titley (RIPE NCC Executive Board) summed up Rudiger's comments by saying that the LIR reference needs to be fixed and the CPS and LIR Closure policy needs to be referred to in the text.

Rob Blokzijl (RIPE Chair) says the policy basically says that certification follows registration and so there's no need to refer to other documents.

Nigel replied that he hoped to bundle the registration policy.

Rudiger agreed if there was exactly this wording in relation to the registry document and the registration policy.

Nigel replied that it was in the document.

Rudiger suggested removing the previous references and apply some cleanup.

Gert Doering (WG Chair) mentioned that the policy mentions the database and so maybe Rudiger's argument was valid.

Gert Doering (WG Chair) added that the wording in the document could be simplified to reflect the registration status. Otherwise they could wait until all documents were published. Some concerns were related to referral documents that might need more time to reach consensus.

Nigel said if the Working Group is happy with it, he would change the wording.

Gert Doering (WG Chair) added that there weren't many comments on the Working Group mailing list. In any case some rewording is necessary.

Alex Band (RIPE NCC) commented that they've been talking about Certification since 2008 and now they're arguing over commas and wording. He said he understands the policy needs to be solid, but that it's already restrictive and limited in scope. The current policy text means that they're certifying a lot less than they could be, because what they intended to do was to have something incremental and evolve it over time. He said that the only thing they can certify now is PA space for RIPE NCC members/LIRs and they could certify AS numbers or PI space where the End User documents approved status. He said that they just wanted to get the system going so they can get experience with it and get feedback from users. He warned that if it didn't go forward quickly, they're going to end up with an infrastructure with no capability to issue certificates. He added that he was afraid that they'd be having this same discussion on phrasing in six months and still won't be able to issue certificates.

Gert Doering (WG Chair) replied that Alex had valid points. However, if there was no discussion on the mailing list, then the PDP review phase had to be extended. He added that feedback was necessary on the mailing list to go forward with it.

Alex replied that the RIPE NCC received a lot of positive feedback on the system from people involved in the project or during presentations to LIRs. However, these people did not get involved with the policy text. He wanted to have something simple with the potential for expansion.

Gert Doering (WG Chair) urged Alex to get these people to speak up on the mailing list.

Tim Bruinzeels (RIPE NCC) commented that referring to the CPS in the policy could lead to delays due to the extremely technical nature of the document; many people might not understand it. He said that the CPS should reflect whatever policies are applied. He said the referrals should be the other way around and he was afraid if the CPS was circulated for review that it could take a long time to move forward.

Geoff Houston (APNIC) commented that the CPS is an important document for operators and those that will be using Certification. He advised against referring to the CPS in the policy because it didn't belong there, and to leave the operational documentation to the RIPE NCC to take care of. He urged that the community provide the RIPE NCC with very simple guidance: certify what's in the registry.

Rudiger Volk (DTAG) replied to Tim by saying that people need to know that the policy and the CPS overlap, for example the validity period, and that it largely defines the service of the certification authority – so it warrants scrutiny, just not a huge discussion, by some members.

In response to Alex Band, Rudiger said he really wanted it to go forward and it needed to be right. Only minor details need to be fixed. He said he is aware that it would have been good to start it two years ago and it is the bare minimum of what can be done. He added that there weren't many changes needed now and he hopes to see it passed through the PDP quickly now.

Nigel Titley (RIPE NCC Executive Board) urged people to watch the mailing list and make comments when new versions are proposed. He said nobody made any comments, including Rudiger. He again requested people comment on the list and said he'd like this policy to get through.

Gert Doering (WG Chair) suggested that Nigel and Rudiger meet during the coffee break to agree on new text, than send version 2.1 to Emilio Madaio (RIPE NCC), than have a quick two-week review phase. He urged the community to comment on the new version so they could go forward with it.

Hans Petter Holen (Visma IT) supported Nigel's last comment about not receiving any input on the mailing list.

2010-02 Allocations From the Last /8 [NEW] – Philip Smith and Alain Bidron

Sander Steffann (WG Co-Chair) summarised the evolution of the policy proposal and opened the discussion by asking Martin Hannigan to bring up his concerns to the Working Group.

Martin Hannigan (ARIN ASO AC) explained that he opposed the proposal on the mailing list for multiple reasons. He said it was mostly a marketing proposal and does more damage than good. Eventually, small networks are going to pay because the addresses are going to be turned around and sold to the bigger networks at a higher cost. He said if the community really wants to go forward with it, he wouldn't oppose it further.

Sander Steffann (WG Co-Chair) said that the other comments on the mailing list were in favour of the proposal. He suggested moving the policy proposal to last call.

Gert Doering (WG Chair) agreed in moving to Last Call.

Y. Open Policy Hour

Martin Hannigan / Jason Schiller: Proposal About Inter-RIR Transfers

The presentation is available for download at:
http://ripe61.ripe.net/presentations/254-RIPE61-ARIN-prop-119.ppt

Wilfried Woeber (Vienna University) asked if the text was meant to exclude an RIR from the inter-RIR transfer policy in the event that such RIR changes the version locally.

Martin said it depends

Wilfried Woeber (Vienna University) added that would prefer not to create confusion if one region is excluded and the others keep working in compliance to the policy.

Martin Hannigan (ARIN ASO AC) replied that minor changes relating to language or cultural performance of the text was not a reason to de-implement. However if the text changed to reflect different agreements, then the policy would be de-implemented.

Jason Schiller (ARIN ASO AC) added that the idea behind this was that the friendly way to change it would be with another globally coordinated policy, so changes can be the same across the board. If one RIR doesn't play by the rules of RFC2050, then the text gets yanked from the other RIRs too. He added that if this becomes linked to that global policy, the intention would be that when one RIR vetoes the policy, it stops everywhere.

Martin Hannigan (ARIN ASO AC) clarified that the proposers expect the community to make it work if they think they need it.

Wilfried Woeber suggested broadening the references to RFC2050 in the text, since it could be replaced by an updated version.

Martin Hannigan (ARIN ASO AC) explained that the slides being shown were not the correct version, and that in the latest version, there is text that says even if RFC2050 deprecates, the principle doesn't. He said the interpretation of 2050 could be updated depending on how the proposal is implemented; it's one of the advantages of having a globally coordinated policy.

Hans Petter Holen (speaking on behalf of the AC) stated that the first task of the Address Council was to write a replacement for 2050, and that a Working Group worked on it for years. At one point, there'd been a decision to stop working on it. Hans Petter said one of the reason's why it was stopped is because the IETF didn't think it was the proper place to have address policy documents proposed.

Martin Hannigan (ARIN ASO AC) replied that IETF for sure thinks that it 's the proper place today.

Hans Petter Holen (Visma IT) confirmed that there is documentation about that decision in the past and said there are significant parts of RFC2050 that have been replaced by global policy and by regional policy. He recommended keeping the values of RFC2050 in the document. He said there's been a lot of discussion on this subject and that there are key points that the regions disagree on and that pushing this too hard could identify the disagreements on the basic principles of stewardship of Internet address space. He asked the community if it was the time to discuss these disagreements now or later on.

Martin Hannigan (ARIN ASO AC) said he appreciated the comments and wanted to be sure that they don't get hung up on RFC2050 specifically. Any reference to 2050 in the proposal is more about the principle of working together, and that the system has been open and transparent for many years.

John Curran (ARIN) said its RFC2050 and it's also ICANN Global Policy ICP-2, which was the policy for recognition of a Regional Internet Registry – both policies call for address conservation. He added that while it's possible that RFC2050 could be revised, they'd also have to revise what they tell ICANN is the nature of an RIR.

Martin Hannigan (ARIN ASO AC) clarified that there was no intention to change RFC2050 but if the five communities ask for it, they will.

Gert Doering (WG Chair) mentioned that the policy proposal would be further discussed on the mailing list.

Z. A.O.B.

Gert Doering (WG Chair) mentioned that two items were added to the agenda. The first issue is the confusion about the way the RIPE NCC does PI requests when there's a potential for aggregation. He said it's logical that, for example, you have a /24 PI and you go to the RIPE NCC with a request for another /24 and since aggregation is useful, you return the old /24 and get a /23. But the RIPE NCC doesn't do it this way. Gert asked Alex Le Heux (RIPE NCC) to explain why.

Alex Le Heux (RIPE NCC) said the RIPE NCC used to accept returned PI assignments for aggregation reasons. The procedure of returning the address space involved putting the range of address space in quarantine for 3 months. Afterwards, the range could be distributed to another new requester. Unfortunately, the RIPE NCC got a lot of new requesters that came back to the RIPE NCC with some complaints on the range being blacklisted. RIPE NCC started to look into it and found out that practically all of the returned ranges were used by spammers and phishers, and that they usually had money to buy more equipment to justify larger assignments. Alex added that investigating all of these cases required a lot of work and that the legitimate users were affected by the polluted PI assignment. So, the RIPE NCC decided to not accept returned PI assignments across the board.

Owen Delong (Hurricane Electric) commented that it might be relatively easy to check to see if an address block is on a blacklist when someone tries to return it before giving them a larger block to just pollute again.

Alex Le Heux (RIPE NCC) said he's thought of this and looked through many policy documents and there's no basis to deny someone address space if they fill the requirements.

Robert Kisteleki (RIPE NCC) mentioned that at RIPE 60 Meeting there was a presentation related to the topic.

Rudiger Volk (DTAG) said that even without a policy defined, that he'd think the RIPE NCC could actually just ask people that wanted a new block to provide you with a statement that says they've not been causing trouble, and if they have, the address space will be revoked and the LIR will be closed due to breach of contract.

Alex Le Heux (RIPE NCC) replied that it's PI space, so it doesn't involve LIRs, but that the RIPE NCC would look into it.

Joao Damas (ISC/Bondis) said he was all for going after the bad guys, but to exercise caution because sometimes the good guys get on those lists too, and some lists are more reliable than others.

Alex Le Heux (RIPE NCC) clarified that the RIPE NCC doesn't deny additional address space because the requestor because of a blacklist. The RIPE NCC just doesn't take back a PI block and give an aggregated one anymore.

Alex also announced that the evaluation procedure for IXP IPv6 assignments was updated following discussions from yesterday's session.

Joao Damas (ISC/Bondis) presented a few slides with a hypothetical situation of a customer's network where there is no splitting of the address space and the PI space.

The presentation is available for download at:
http://ripe61.ripe.net/presentations/322-does_the_cable_length_or_colur_matter.pdf

Basically, his customers are small companies that don't want to have the burden of running their IT equipment, so he does it for them. He retains ownership of everything, and he uses long-distance equipment to provide access to them. He said he doesn't think this is a sub-assignment, but other people say it is. He asked for input from the room.

Gert Doering (WG Chair) said that Joao's issue is in the middle between a policy and a procedure and that the RIPE NCC disagrees with him. He added that in the RIPE NCC Services Working Group, Andrea Cima (RIPE NCC) said they were going to publish detailed checklists on how they evaluate such requests.

Joao said he was bringing this up now because it tied in with the discussion about PI space and aggregation. He said the RIPE NCC was telling him that they wouldn't give him a /23 or two /24s, which would have been enough space to provide service at the time. But if he pays more money and becomes an LIR, he can get a /20 – more than he needs. So, he's trying to conserve space and he's being denied. Joao said he understands Alex's explanation about aggregation, he didn't know that was happening. But when he puts the two things together, he doesn't understand what's going on here.

Wilfried Woeber (Vienna University) replied that it was a typical mistake of having technical details in policies that were then translated into procedures. He described an example with a DSL wording in his request that he sent to the RIPE NCC host master. The word “DSL” triggered the verification needed for broadband service when it was not that type of service. Wilfried urged caution in making sure that these sorts of details don't get perpetuated further through the Cosmetic Surgery Project.

Gert Doering (WG Chair) said this was why the RIPE NCC was going to publish evaluation guidelines transparently going forward to show how they do things and if people don't like it, speak up. It will help clear up confusion and give people a chance to point out if something is wrong. He said he looks forward to seeing the guidelines published and whether it helps.

Alex Le Heux (RIPE NCC) added that it was difficult to differentiate the customer end site from the provider network because of changing technologies, as well as organisation and economical structures involved. He added that with the publication of RIPE NCC evaluation procedures, he was looking forward to the community feedback.

Joao Damas (ISC/Bondis) apologised to the Working Group for not having his slide added to the session agenda.

Gert Doering (WG Chair) thanked everybody and closed the session.