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:

Gert started with a few words on the procedural aspects of policy making. Decisions are not made during the discussions in the RIPE Meeting. Discussing the proposals at the RIPE meeting is merely a way to get quick initial feedback. The "Last Call" and the real policy-making is always done on the mailing list. PI and Special Case Address Space Related 2006-05, "PI Assignment Size" - will only be mentioned in the "overview" and will not be discussed again. Gert gave a short summary on proposal 2006-05. He summarised that this proposal was not received well on the mailing list. He asked RIPE NCC Registration Services to send some statistics to the mailing list and then have a more educated discussion on the list. The proposal was stalled by the chairs but not forgotten.

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.

Jim Reid (RTFM Ltd) agreed that there seems to be good consensus. He only would like to add one more word to the text. It currently says: "4 /24 per ENUM". He would like to see that changed to "4 /24 per ENUM delegation". However, when asked, he stated that this was not worth a fifth revision and thus further delay. Peter Koch (Denic) also stated that all his issues with the previous version have been addressed. He agrees the proposal is ready for implementation. Gert thanked the proposers for all the work. Since the feedback on the mailing list was also positive, this proposal would go to "Last Call" soon.

F. 2009-02

Remco van Mook

• A three-minute presentation about version 2.0, followed by Q&A and discussion.

Martin List-Petersen (Airwire) commented that, in theory, other regions should have this same problem so why not let the NRO make the assignments?

Remco responded by saying that previously it was also suggested that IANA make this type of assignment, which would be much simpler. Gert mentioned that in the other regions the current policies have clauses about critical infrastructure that facilitate this type of assignment. He invited the representatives of the other regions to say a few words on this. Guangliang Pan (APNIC) confirmed this and added some information regarding the situation in APNIC. He said that if an organisation or department is in need of such an assignment, they make a formal request to Registration Services, who evaluates the request. The Registration Services Manager then evaluates that same request in case of any concerns. Leslie Nobile (ARIN) explained the situation in ARIN region. It has the micro-allocation policy that refers to critical infrastructure. This policy says that an RIR can get address space based on that paragraph. This type of request is evaluated by Registration Services. In the ARIN region they evaluate their own need based on the policy. Ricardo Patara (LACNIC) said that LACNIC also has a clause regarding critical infrastructure in their policy. This clause applies to cc-TLDs and is also open for other cases like an RIR that needs an assignment. Remco asked whether address space for a meeting would be considered as critical infrastructure. Gert confirmed this and also stated that the same problem with contracts would exist if such a clause would be present in the RIPE policies. Hans Petter Holen (VISMA IT) stated that he felt that this proposal was a good idea but he urged that it should not be made too bureaucratic. Openness is the most important factor. The third party arbiters might add too much bureaucracy. Remco responded by saying that during the RIPE 57 Meeting in Dubai there was a strong preference for a third party, the arbiters, to be involved, Gert confirmed this and added that the community is the last resort in case of doubt. Wilfried Woeber (University of Vienna) followed up on the comment made regarding openness. Any other request for address space must be confidential.
Therefore, to allow for openness, the arbiters should be allowed to make this type of request public. Remco confirmed that this was mentioned specifically in the proposal. Peter Koch (Denic) mentioned that the working group just discussed the ENUM proposal; the RIPE NCC would be eligible in both policies. He asked if there would be a clear way to decide which policy would take preference. Remco responded by saying that the RIPE NCC should not be treated in a different manner. Only the evaluation is different. This means that anycast or ENUM requests should be evaluated as such. Peter added that the focus should be very clear that the policy applies to all possible cases. Remco said that he used both the terms allocate and assign to ensure that all possible cases are covered in this policy proposal. Gert decided that the discussion should be taken further on the mailing list after which a consensus can be reached and eventually move the proposal to last call.

2009-05 Multiple IPv6 Allocations for LIRs

Gert summarised the proposal. Daniel Ruegg made this proposal a few weeks ago. He received a lot of emails regarding the proposal and decided not to go ahead with it. He already found a solution for himself and the proposal was intended to solve the issue for others as well.

Gert explained that there is no active proposer at the moment and the so the Working Group needs to decide how to proceed with this. There is no consensus at the moment. To help the discussion, Gert referred to an ongoing policy proposal in ARIN region: "IPv6 Multiple Discrete Networks" Marco Hoogewonig (XS4ALL) said that he understood that there were some organisations that have this problem and it should be solved one way or another. However, currently the proposal states that it is possible to get an additional /32 if you have an additional ASN. He does not like this aspect of the proposal. The main problem is that the policy states that you should announce your IPv6 allocation as one prefix. A /32 allocation might be large enough for many separate entities but de-aggregation might cause problems with filtering. A possible solution would be to remove the requirement that the /32 allocation must be announced as one prefix and in instead allowing to announce sub-allocations separately, might solve the problem. Both solutions imply extra entries in the routing table. Marco asked for feedback on this before turning it into a proposal. Gert thanked Marco and added that the community needs to decide which routes it wants to see and which not. Bernard Tuy (Renater) stated that a /32 allocation is large enough for them. However, they need address space for the academic network but currently cannot announce anything more specific than a /32. Marco responded by saying that this is the main trigger. With IPv4 you normally hold multiple blocks and with IPv6 you receive one block that should last a lifetime. Gert added that this helps fragmentation. Marco agreed and added that he has also heard people say that PI assignments might be a solution for this. With PI you have the limitation that it cannot be sub-assigned and in the end every solution implies an additional route. Gert commented that the issue is not a lack of address space but that the operational community needs to decide on which routes to accept. Bernard asked for confirmation that /35s are already accepted. Gert confirmed but also stated that these come from a very distinct block. Remco van Mook stated that he felt very strongly about this issue. He wanted to point two things out. The first thing was that he definitely would not like having any relation with the number of ASNs; having a second ASN should not automatically allow for a second /32. Secondly, he said that he did not like the reference to a "single entity" as defined in the ARIN proposal. He said there was no such thing. In a larger organisations there are many entities under one name. Therefore this would not work as a criteria in the proposal. And, finally with regards to filtering on /32, he stated that the community should focus on fixing the filtering instead of handing out more /32 that would go unused. Wilfried Woeber stated that he did not like this proposal at all. He did not like the /24 minimum assignment size for PI either for the same reason. Both proposals try to solve routing issues with resource distribution and this is fundamentally wrong in his opinion. The only difference between the two proposals is that there is no address scarcity with IPv6. If there is an operational issue on the routing plane, we should fix the operational problem on the routing plane. Marco Hoogewonig responded that people build filters on documentation so there is a need for properly documenting routing recommendations. Ruediger Volk agreed with the two previous speakers. He added that he did not mind very much about extra load on the routing table. If there will be an extra load, this will mostly come from PI space. He also commented upon another part of the proposal regarding potential renumbering. If you insist on having everybody on one structured network, there will always be problems with renumbering in case of mergers/acquisitions. Piotr Strzyzewski (Silesian University of Technology) stated that he did not necessarily like the proposal but does support it. It is easier said than done to fix the problem on the routing plane. Peering partners will do their best effort and filters will be changed but it will take time. Leo Vegoda (ICANN) stated that he was mostly concerned about revoking the allocations when separate routing policies are no longer needed. There must be a strong mechanism in order to ensure that allocations are returned. Gert concluded the discussion by saying that there was clearly no consensus on this. He suggested that some of the speakers of today would get together and find an approach that could work. After that, it should go back to the list and find a way forward. Wilfried added that this should also be brought up formally with the Routing Working Group as well. Gert agreed and explained that it was on the agenda for the IPv6 Working Group as well but there was not enough time to discuss it.

Run Out Fairly

Daniel Karrenberg

Daniel Karrenberg (RIPE NCC) finished his presentation by asking the audience what should happen next. He asked if this proposal be moved to the review phase?

Nick Hilliard (INEX) asked how this proposal would work for very small LIRs that do not need more than the minimum allocation size for a number of years. He asked whether they should lie to get the minimum allocation size.

Daniel responded that there is no need to lie. As far as he knows, not that many questions are asked to receive a minimum allocation size as long as there is a demonstrated need for part of that allocation.

Wilfried Woeber (University of Vienna) wondered why nobody was worried about the potential consequences to the growth of the routing table. He did not say it was a bad proposal but there will be effects to the routing table.

Daniel answered that this is a valid question and that he would do some work on finding out what the consequences might be for the routing table.

Ruediger stated that he thought that this will only be a small percentage in the overall scheme of things and added that this would be a nice training exercise for the things that will come afterwards.

Wilfried asked about the impact on the workload on the RIPE NCC's IP Resource Analysts (IPRAs) when big organisations come back for new address space much more often.

Daniel responded that the effect on the workload of the IPRAs will be part of the impact analysis done by the RIPE NCC when the proposal is moved to "Review Phase."

Niall O'Reilly made a final comment that the authors will look into the potential effect on the very small LIRs as described by Nick Hilliard.

Thursday 7 May 09:00-10:30

Cross-Working Group Material

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

http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Bidron-IPv4_Allocation_and_Assignments_to_facilitate_IPv6_Deployment.pdf
Alain Bidron

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