Address Policy Working Group Minutes from RIPE 58

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

Wednesday 6 May 09:45-10:30 & 11:00 - 12:30
Thursday 7 May 09:00-10:30
Friday 8 May 14:00-14:30

Chair: Gert Doering
Co-chair: Sander Steffann
Scribe: Ingrid Wijte (RIPE NCC)

Wednesday 6 May 09:45-10:30

AGENDA

A. Administrative Matters

• Welcome
• Select a scribe
• Jabber Monitor
• Microphone Etiquette
• Finalise agenda
• An Update on the implementation of 2007-01 will be covered in the NCC Services Working Group

Nigel Titley asked why Policy Proposal 2008-08 is on the agenda for Thursday while it will be discussed today in the NCC Services Working Group.

Gert Doering (Chair) explained that although the proposal is on the agenda for completeness, it would not be discussed in the Address Policy Working Group. In RIPE 57, Dubai, unexpected possible consequences and the absence of a clear revocation policy were discussed. The conclusion was that it would be better if this proposal would be first discussed in the NCC Services Working Group. The proposal will be discussed in the Address Policy Working Group only after consensus is reached in the NCC Services Working Group.

There were no changes to the agenda.

B. Current Policy Topics

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/current-policy-topics.pdf
Filiz Yilmaz

Filiz announced that the RIPE NCC is ready to accept IPv6 PI requests as of today.

There were no questions.

C. ASN32 Take-up Report

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf
Daniel Karrenberg

Raymond Jetten (Elisa Oyj) wanted to know whether there would be a fourth alternative as there is usually another way that works. He also wanted to know if the RIPE NCC recovers ASN as well.

Gert Doering (Chair) responded by saying that this might not solve the issue, as IANA might not want to give out new 16-bit ASN if there are 32-bit ASN waiting to be assigned.

Rob Blokzijl (RIPE Chair) complimented Daniel on the presentation. He commented that there is a policy in place with dates in it. However, the situation and the knowledge have changed since then. According to him, option 2 (extend the global policy by 12 months) seemed to be the most logical as the dates on the policy or the reclaiming of 16-bit ASNs has no effect on the end result of running out.

Wilfried Woeber (University of Vienna) commented that something needed to be done on short notice and agreed with Rob that extending the policy by 12 months would be the most sensible thing to do. He also added an observation about Daniel's report on why some organisations/ISPs are not able to use 32-bit ASN. Those issues will not really change over time; technical problems for existing equipment will continue to exist. Although initially it looks attractive to reclaim 16-bit ASN, it would require (human) resources to accomplish that. The effort would be much better spent on making networks 32-bit enabled.

Leslie Nobile (ARIN) was asked by Daniel to add some information regarding the situation in the ARIN region. She stated that in 1.5 years, ARIN has issued 215 32-bit ASNs. 204 changed their mind later on and exchanged it for a 16-bit ASN. In effect ARIN has only issued 12 32-bit ASNs. In the ARIN region they hear the same problems with 32-bit ASNs as Daniel just outlined for RIPE region.

Gert asked if there is a policy change underway in ARIN?

Leslie replied that there is no formal policy proposal at the moment but the issue was mentioned in the policy BoF last week during the ARIN meeting and she thinks there will be something coming forward.

Gert summarised that option two seemed to be the one with most agreement.

Daniel responded by reminding the attendees that there was another question that had not been answered yet. Unless there is any objection raised, the RIPE NCC will continue the current way of assigning.

Gert answered that if the burden of exchanging is not too high, it should be ok to continue in that way.

Ruediger Volk (Deutsche Telecom) agreed that there should be no problems with the RIPE NCC continuing current practices, especially while following up on option 2 (changing the dates in the policy).

Gert concluded the discussion by saying that it would be best to formalise the solution to this. It should therefore be taken to the list, as this is also a global matter.

D. New Proposals Since RIPE 57 - An overview of what's coming

There were no questions.

E. Discussion of Open Policy Proposals

These are grouped by topic:

F. 2008-05

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/2008-05.pdf
Brett Carr

• A five-minute presentation about version 3.0 and the issues addressed, followed by Q&A and discussion.

Mohsen Souissi (AFNIC) stated that he felt that there was no need for yet another version of the proposal. He felt the current version is quite stable. Now that the part about critical infrastructure was removed, he was in support of moving the proposal to the next phase.

F. 2009-02

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/2008-08-update.pdf
Nigel Titley

• Nigel will present on behalf of the CA-TF.
• Followed by discussion.
• This will also be discussed in the NCC Services Working Group and is included in this list of 'open proposals' for completeness.

There were no questions.

Gert concluded by saying that this proposal would not go further just now. The certification process needs to proceed first.

2009-01

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/2009-01.pdf
Axel Pawlik

Gert wanted some clarification on phase 1.

Axel Pawlik (RIPE NCC) confirmed that if a recently opened LIR would close, that address space from a recent /8 will indeed be returned to IANA if not re-allocated after a given period of time.

Wilfried Woeber stated that he felt that the adjustments made by ARIN make good sense. He commented on phase 2. He asked if it is correct that this would slow down address space distribution, as there are only two periods in the year that an LIR can request address space. Therefore if the pool happens to be empty at that time, the LIR has to wait six months maximum.

Axel confirmed this.

Marla Azinger (ARIN Advisory Council) clarified that the main reason that this proposal came about was legacy space. For this reason ARIN AC adjusted the proposal to say that it should only be mandatory to return legacy space. For other space it should be optional. The AC is a bit worried about the fact that not all RIRS have justification required in all of the policies.

Axel supported the statement that this is mostly about legacy space. He added that this proposal might also demonstrate to the world that the RIRs are doing their job of responsible stewardship.

Olof Nordling (ICANN) made the observation that the title of the proposed policy is exactly the same as the policy it should replace. He felt that the title should be changed slightly to avoid confusion.

Leo Vegoda stated that IANA could implement this policy when asked.

Gert (not speaking as WG Chair) commented that the change that ARIN is discussing would avoid having operational overhead. Returning parts of a fresh /8 would create quite some work.

Alex le Heux (RIPE NCC) stated that with the current back-end systems at the RIPE NCC this would be an issue. However, as these systems are being replaced, there should not be an operational issue in the future.

Gert said that if ARIN goes for optional return of all space other than legacy space, RIPE should go for optional as well.

Wilfried commented that we should avoid making holes in the PA blocks for many reasons, for example the fact that routing filters need to be updated accordingly.

Hans Peter Holen (Visma IT AS) would like to know what the advantage would be for the RIPE NCC to free up a /16 in the middle of a /8; that /16 would be returned to IANA after which IANA will possibly re-issue that /16 to the RIPE NCC.

Axel agreed that making this mandatory for legacy and optional for other space is very reasonable.

Filiz Yilmaz (RIPE NCC) asked if it is correct that this proposed policy would only come into effect after depletion, therefore deprecating the current policy.

Axel confirmed that if this policy would be accepted by all RIRs, phase 1 would go into effect immediately: IANA will set up the pool to receive returned address space and the RIRs will start to return to IANA. After depletion of IANA pool, phase 2 will go into effect and IANA would start giving out address space that was returned in phase 1.

Wilfried asked how the existing policy would go to rest.

Axel answered that the simplistic way of doing that would be to let IANA run out of fresh address space after which the current policy would no longer be of value.

Alain Bidron (France Telecom) asked if there were sufficient legal grounds to reclaim legacy space.

Axel responded that that is dependent on each situation and on the different regions.

Sander Steffann (acting as WG chair) concluded that the general opinion is that we should go forward with ARIN's version of the proposal and try to get consensus on that one.

2008-06

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Smith-2008-06.pdf
Philip Smith

There were no questions.

IPv4 Allocation and Assignments to facilitate IPv6 Deployment

This is a joint discussion about both proposals, because both affect the usage of the last /8. The working group needs to decide how to proceed with these two colliding proposals.

George Michaelson (APNIC) commented that the IPRAs essentially apply objective processes, currently, to assess what people get based on an application process. But that is predicated based on there being enough resources to meet their justification. What is now being proposed means that people can actually justify more addresses than are available. What objective aspects will be available to guide the decision making process. This could put the IPRAs in a difficult position.

Randy Bush (IIJ) responded that the proposal clearly states how much the LIRs will receive: there is only one size and they can only receive one.

Alain Bidron commented that in order to avoid subjectivity, his proposal specifically refers to the RFC5211 because it is a good example of the criteria for IPv6 deployment that can be used by the IPRA to determine if the request is justified.

Andy Davidson (Netsumo) asked why we should wait for deployment of the policy until the last /8. Why not start immediately after the community reached consensus? He also asked if the policy would also apply to allocations received after the last /8 is used, for example for the blocks that will be returned to IANA.

Philip Smith responded that this is actually a valid question. The proposal is based on the fact that it was decided that the RIRs receive one last /8. The global policy for returning address space to IANA did not exist at the time of writing the proposal.

Wilfried Woeber stated that it is reasonable to think about cutting up the remaining space into smaller pieces and try to give it out to as many entities as possible. However, he has a basic problem with the proposal as it ties access to the remaining address space to a particular application (IPv6 deployment). Resource distribution policies should not favour one particular application or environment to be used over others. Unique IP resources are just a piece of technology. The product you build on top of this should still be your own decision, and not the decision of the big global ISPs.

Randy started by stating a conflict of interest between being co-author of the proposal in the APNIC region and chair of the APNIC Policy Working Group. Randy explained that this proposal addressed the question of why we are making a proposal regarding a last /8 for each RIR if we do not know what we are going to do with it. The fact is that new entrants will need a little bit of IPv4 address space to get started. Regarding the question of why not start now rather than wait, Randy stated that there was no need. By cutting up this last /8 into small pieces there is enough to last 15 or 20 years. There is also no need to use space returned to IANA for this purpose. There is enough of a pool to meet the goal. Randy also agreed with Wilfried that limiting this for a specific purpose only is not a good thing.

Alex le Heux (RIPE NCC) stated that from an IPRA point of view it would be a good idea if the policy specified what type of proof LIRs need to present to show that they will use it for IPv6 deployment.

Andrei Robachevsky (speaking as private person) stated that an important factor of the second proposal is that it will stimulate IPv6 deployment. Also, he states that the second proposal is based on the same principle as current address space allocation: it just says that if you have a need for /21 and you can demonstrate this need, it is assumed that multiple technologies will be used in the future when we run out of IPv4 address space and sharing of IPv4 addresses will be very common and therefore if you have a need for a/21 a /27 should satisfy this need. So evolution from this point of view should be pretty straightforward.

Regarding Philip's proposal, Andrei commented that this would most likely not be the last version. It implies that there would be an emerging proposal that will minimize the minimum allocation size. With the current allocation size this will not even cover half of the LIR base of the RIPE NCC. According to Andrei, none of the proposals are perfect but none ever will be. More importantly, what wuldhappen if there is no proposal whatsoever?

Max Tulyev (NetAssist) remarked that the community should switch to the other side. Instead of making provisions for the last /8, the community should develop rules for an IPv4 market. He commented that IPv4 will become very valuable after IANA and the RIRs run out. He stated that the effort should be focussing on making the market white instead of black.

Gert responded by saying that making provisioning for the last /8 does not imply that the community cannot make rules for an IPv4 market at the same time. He asked Max which proposal he liked best and Max answered that he did not like either one of them because he felt that we should not do anything about this.

Martin Peterson (Airwire) commented that the proposal, like Philip's proposal, should be kept as simple as possible; everybody should be able to get a piece of the last /8.

Willi Herzig (BSI) stated that the last /8 should facilitate IPv6 as it is already hard enough to make the transition and it should be encouraged.

In order to get some clarity on the direction that this should go, Gert asked for a show of hands on three questions:

There were 5 or 6 hands when asked if we should do nothing special with the last /8.

There were 15 to 20 hands when asked if the WG should go with Philip's proposal or something similar.

Most hands were raised when asked if we should go with a proposal that will take IPv6 promotion into account and work it out further.

Jakub Jermak, participating over Jabber, stated that he was in favour of the first proposal as it sufficiently spreads the availability of an allocation without a very large effect on the routing table.

Gert ended the discussion by saying that although there seems to be a preference for a proposal that will facilitate IPv6; the decision on how to go forward will be made on the mailing list.

2008-07

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Smith-2008-07.pdf
Philip Smith

Gert thanked Philip for summarising the contents of the proposal and added that one counter-argument that he had heard was that people might prefer not to register this address space in the database if it means that the address space will be held against them in the future. This would possibly imply that the proposal would have a negative effect on registration of address space.

Philip responded by saying that he remembers that this was indeed mentioned but seen as a big argument against the proposal. People can choose to disappear anyway, even today.

Wilfried Woeber (University of Vienna) asked for some clarification on which organisations this would apply to; only to the LIRs or also to their customers? He feels that for every organisation, applying for address space all address space should be taken into account.

Philip responded that this should only include the LIR's address space. Since this is about legacy space the addresses would not go back to the LIR if that other organisation disappears.

Wilfried replied that, in that case, this proposal should be extended to every organisation that is requesting for more address space, not only to LIRs.

Philip answered that he was taking this one step at a time.

Filiz Yilmaz (RIPE NCC) commented that in the RIPE NCC, the 80% utilisation rule only applies when requesting a new PA allocation. The 80% rules do not apply to PI space. This means that Wilfried's suggestion would imply a new policy with the same 80% rules for PI space.

Randy Bush said that when considering the utilisation you should consider ALL address space that YOU hold.

Per Heldal, participating over Jabber, stated that it is a mistake to adopt the legacy term from ARIN policies. Network operators are either members or they are not. This is a general comment valid for all policies.

Gert understood that the comment implied that we have to look at the wording of the policy.

Randy said that there is some confusion: a member is not legacy or not. Address space is.

Gert responded that it would be a good idea to have a close look at the wording to ensure that the terminology used is not the terminology from other regions that slipped in. He then summarised that there have mostly been comments asking for clarification. It is not clear whether people here feel that we should go forward with this or not.

Philip commented that there has been some new text for the proposal that will be published soon. This new text can be reviewed on the mailing list.

Y. Open Policy Hour

Gert explained that the Open Policy Hour (OPH) is a showcase for policy ideas. If you have a policy proposal you'd like to debut prior to formally submitting it, here is your opportunity.

Y.1. Andy Davidson

The community has recently passed the IPv6 PI policy, which is great news. However, in the policy that was just accepted, there is a clause which states that an LIR can never have IPv6 PI space. It was possibly a mistake to leave it there, as it is not a very future-proof policy. It also means that your need for addresses is determined/measured on whether you have a contract with the RIPE NCC or not. Andy felt that this is quite a dangerous precedent to accidentally leave in the policy. He didn't believe that people should use PI space when they should use PA instead. PI space is purely for infrastructure and not for End User assignments. In his opinion, having a contract with the RIPE NCC or not should not determine your eligibility for addresses.

Gert reminded the audience that there had been some discussion regarding this clause on the mailing list. At that time it was decided to go forward with policy proposal 2006-01 and at a later time discuss this specific clause again. Andy volunteered to pick it up from there.

Martin Peterson commented that he did not really understand why it was a problem that LIRs would not be eligible for PI space. He asked why you would want/need PI space when you already have PA.

Andy responded that it might be necessary to make an announcement using a completely different routing policy for special parts of your infrastructure.

Martin answered that, in theory, you should be able to get PA for that it would make more sense to allow for a smaller PA assignment than you specifically register as such.

Gert interrupted by saying that the current (PA) policy specifically does not allow for that. It basically says "one LIR, one block". No provisioning for another block.

Martin also responded to the argument of the contractual clause. That clause had to be there. And as the LIR already has a contract with the RIPE NCC, it would not be a problem.

Andy reiterated that whether or not you are eligible for IP space should be based on need rather than on contracts.

Jakub Jerman, participating over Jabber, asked what would happen if an organisation has IPv6 PI space and then becomes an LIR. What would happen then?

Andy responded that in his draft proposal text some words/ideas are drafted regarding that point. He also wanted to gather feedback on those ideas.

Jordi Palet (Consulintel), as author of the 2006-01 proposal, stated that the thinks it would probably be much easier to allow ISPs to have different blocks with different announcements, or introducing de-aggregation, than to touch the PI space policy again.

Andy agreed that something needs to be changed to allow an LIR to have a smaller or separate block. He still believes that it is a dangerous precedent to write in the policy that LIRs are treated differently. The need should determine whether you are eligible for addresses. He added that Jordi's point of view was not so different from his but that they had different solutions for the problem.

Gert summarised that there is no clear agreement. There was valuable input and we should go back to the mailing list for further feedback and, after that, make a new proposal.

Gert also announced that on Friday there would be an additional Address Policy session at the start of the closing plenary. The discussion would be regarding routing considerations for IPv6.

Friday 8 May 14:00-14:30

Joint session Address Policy WG/ Routing WG/IPv6 WG

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-routing-considerations.pdf
Rob Evans

Joao Damas (Chair Routing WG) and Sander Steffann (co-Chair Address Policy WG) started the session with a few slides explaining what the discussion would be focusing on. Currently the IPv6 Address Allocation and Assignment Policy document contains some clauses about routing.

The question at hand was whether this should be in a policy document or whether it should be taken out. The second question was whether a /32 should remain the most specific prefix in the global IPv6 table, accepting the wastage of address space that this causes or should there be guidelines on filtering in IPv6.

Ruediger Volk (Deutsche Telekom) stated that filtering should be very specific and content based and should be producing on routing security. This is completely out of range of the Addressing Policy and it should therefore be removed from the policy document.

Marco Hoogewonig (xs4all) agreed with Ruediger but also stated that it will be a long road to get there. Marco stated he is also in favour of removing the routing clauses from the policy document, but making sure that the routing recommendations, whichever they will be, will be properly documented.

Remco van Mook stated that he also supports removing the clauses from the Policy document.

Philip Smith agreed and added that wherever routing recommendations are documented and whichever these will be, these should remain recommendations.

Gert Doering added that he would be willing to help with make the recommendations and documenting them.

There were some more comments made in agreement with removing the routing clauses from the policy document and documenting routing recommendations properly elsewhere.

Sander Steffann (co-Chair) concluded that there is agreement to proceed. A proposal will be prepared and sent to the appropriate mailing lists.

Z. A.O.B./General Discussion