June 2008 - address-policy-wg

Revised 2007-01 moved back to Review Period (Direct Internet Resource Assignments to End Users from the RIPE NCC)
by Ana Matic 07 Aug '08

07 Aug '08

PDP Number: 2007-01 Direct Internet Resource Assignments to End Users from the RIPE NCC Dear Colleagues, The new version of the proposal described in 2007-01 has now been published and is moved back to Review Period. Also, the new draft document "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" has been published. This document describes the contractual requirements necessary for End Users of provider independent resources and also speaks to the status of pre-existing assignments. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2007-01.html and the draft documents at: http://ripe.net/ripe/draft-documents/ripe-424-draft-2007-01-v3.html http://ripe.net/ripe/draft-documents/ripe-421-draft.html http://ripe.net/ripe/draft-documents/ripe-389-draft.html http://ripe.net/ripe/draft-documents/ripe-new-draft-2007-01-v3.html We encourage you to review this revised policy proposal and the draft documents and send your comments to address-policy-wg(a)ripe.net before 24 July 2008. Regards, Ana Matic RIPE NCC

23 69

2007-08 Review Period extended until 9 July 2008 (Enabling Methods for Reallocation of IPv4 Resources)
by Filiz Yilmaz 15 Jun '08

15 Jun '08

PDP Number: 2007-08 Enabling Methods for Reallocation of IPv4 Resources Dear Colleagues, The Review Period for the proposal 2007-08 has been extended until 9 July 2008. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-08.html We encourage you to review this policy proposal and send your comments to address-policy-wg(a)ripe.net. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

24 60

2007-08 Review Period extended until 9 July 2008 (Enabling Methods for Reallocation of IPv4 Resources)
by Erics 13 Jun '08

13 Jun '08

We do not support the 2007-8 proposal! We have a clear policy that obligates LIRs to give back unused address blocks to RIPE-NCC. This is a clear procedure. If we open a kind of address-market we establish some more abuse possibilities. All in all we endore Per´s statement given below on June 11th. Eric Schmidt Deutsche Telekom Technischer Service Central Services | LIR de.telekom

2 1

Re: 2007-08 Review Period extended until 9 July 2008 (Enabling Methods for Reallocation of IPv4 Resources)
by Sander Steffann 13 Jun '08

13 Jun '08

Hello everyone, In the last two days there have been a lot of messages about proposal 2007-08. We have seen support, but also some concerns. To be able to reach consensus, these concerns have to be discussed. Here is a summary: Randy Bush: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00355… - Transfering address space still assigned to end users - Inter-region transfers Per Heldal: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00354… - Keep demonstrated need criteria for address space by receiving LIR - Legal implications for RIPE NCC - Viable plans for reclaiming space to continue with current policies for a significant time? http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00365… - Possiblity of setting up LIRs for hoarding Jay Daley: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00366… - Seller can choose who to sell to, not transparent - Discrimination of LIRs in developing countries in the RIPE region - Reclaim/reuse could be more efficient than transfering - Faster depletion because of hoarding - Legal implications for RIPE NCC - Degradation of RIPE DB because of rival trading exchange databases Eric Schmidt: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00381… - Breaks the current policy that unused address blocks return to RIPE NCC - Transfers open up more possibilities for abuse ETNO: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00293… - A transfer system can not ensure a process that is open, transparent and equitable - Negative impact on routing tables - Keep demonstrated need criteria for address space by receiving LIR I want to thank everyone for voicing their support and concerns. At this point in the process, please focus the discussion on the open issues. Sander Steffann APWG co-chair

1 0

2008-03 Review Period extended until 26 June 2008 (Global Policy for the Allocation of the Remaining IPv4 Address Space)
by Filiz Yilmaz 12 Jun '08

12 Jun '08

PDP Number: 2008-03 Global Policy for the Allocation of the Remaining IPv4 Address Space Dear Colleagues, The Review Period for the proposal 2008-03 has been extended until 26 June 2008. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-03.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

3 2

Re: [address-policy-wg] 2007-08 Review Period extended until 9 July 2008 (Enabling Methods for Reallocation of IPv4 Resources)
by Marco Hogewoning 11 Jun '08

11 Jun '08

On 11 jun 2008, at 13:03, Gert Doering wrote: > Hi, > > On Wed, Jun 11, 2008 at 12:46:14PM +0200, Marco Hogewoning wrote: >> I agree > > Please be specific: do you agree to the proposal, or to the request > that > people voice their support? > > (Off-List, but this is important when the question "who was in > favour of > it, and who opposed it" is going to be asked) > ed) Sorry for the confusion. I support this proposal. Groet, MarcoH

1 0

Re: [address-policy-wg] 2007-08 Review Period extended until 9 July 2008 (Enabling Methods for Reallocation of IPv4 Resources)
by Niall Murphy 11 Jun '08

11 Jun '08

I support this proposal. Niall > Dear all, > > Following up on Filiz' announcement, I would like to ask people > supporting 2007-08 to let their voices be heard on this mailing list; we > can only move it forward if the wg chairs see enough support for it (and > so far there has been a lot of informal support). > > Thank you, > > Remco van Mook > > > -----Original Message----- > From: address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Filiz Yilmaz > Sent: woensdag 11 juni 2008 10:32 > To: policy-announce(a)ripe.net > Cc: address-policy-wg(a)ripe.net > Subject: [address-policy-wg] 2007-08 Review Period extended until 9 July > 2008 (Enabling Methods for Reallocation of IPv4 Resources) > > PDP Number: 2007-08 > Enabling Methods for Reallocation of IPv4 Resources > > Dear Colleagues, > > The Review Period for the proposal 2007-08 has been extended until 9 > July 2008. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2007-08.html > > We encourage you to review this policy proposal and send your > comments to address-policy-wg(a)ripe.net. > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > > > > > Any opinions expressed in the email are those of the individual and not > necessarily of the company. This email and any files transmitted with it > are confidential and solely for the use of the intended recipient and do > not constitute an offer or acceptance by Equinix, Inc., Equinix Europe > Ltd or any of their group entities to buy or sell any products or > services in any jurisdiction. If you have received this email in error > please delete this email immediately and notify the IT manager. > > This communication is sent on behalf of one of the European entities in > the Equinix, Inc. Group. The ultimate holding company in Europe is > Equinix Europe Ltd whose registered address is Quadrant House, Floor 6, > 17 Thomas More Street, Thomas More Square, London E1W 1YW and the > Company's registered number is 6293383. The registration details of > other Group entities are available at www.eu.equinix.com >

1 0

2007-08: response to ETNO position
by Remco van Mook (Virtu) 04 Jun '08

04 Jun '08

Dear all, and in particular the representatives of ETNO, Let me first thank ETNO for taking the effort, twice, to make a valuable contribution to the discussion surrounding the 'Afterlife' of IPv4 in the form of position papers. It is good to see that we all seem to agree on the following fundamentals: - The available free pool of "allocatable" IPv4 addresses will run out - quite likely by 2012. - The existing IPv4 network will continue to operate for many decades to come. - There will still be demand for IPv4 addresses. - After the available pool of IPv4 addresses is exhausted, needs (even limited) will continue to appear that are provided with other options - The only long-term solution to the "unavailability" of IPv4 addresses is the widespread adoption and deployment of IPv6 infrastructure, transport and client services. (This is pretty much a literal copy from the ETNO position; I could have used my presentations on the subject as a source as well) The other point that most of us will readily agree with, is that we don't like markets. Markets for IPv4, of course. I'm not particularly fond of the idea, either. I would encourage anyone who is completely in favor of an IPv4 market to establish to visit the next ICANN meeting and see first hand what a thriving market has arisen in the domain name space. But there the agreement stops. Let me first rephrase what 2007-08 is about, before responding to ETNO's position. 2007-08 is about setting up a framework for (IPv4) resource transfers between LIRs. Nothing more, nothing less. No IPv6, no ASNs. No PI, no ERX. It is a framework in the sense that, in my opinion, it encompasses the absolute minimum set of policy changes required for this to happen without immediately shooting ourselves in the foot. It is a starting point, not an end point for transfer policies. It does not create a market. We don't stop making policies right after passing this one; the proposed framework can be adapted, altered, even abandoned if we see as a community see fit. The point about moving on urgently with 2007-08 is that it does make a significant impact on how the RIRs run their shop. Implementing and testing 2007-08 takes time, probably a lot of time. Having it in place before the RIRs run out means that we at least have policy we can execute when we run out. Current policy would even allow a single request for a large block of addresses to completely clean out the reserves a RIR might still have in smaller available blocks. But I digress. ETNO, in its position paper, provides a number of principles that a 'post-IPv4' (ETNO's term, not mine) world should obey. I'll mention them shortly and then reply. 1) Identification of legitimate use ETNO would like, in short, to be able to identify parties that have genuine rights of use over IPv4 address prefixes. It is also argued that this can only be done globally, not regionally because that 'will be unworkable'. This global approach must also be in place long before the period in which IPv4 is harder to get. While I agree that we need to keep track on who has rights on what - it is one of the key points of 2007-08 - doing it globally would mean abandoning all RIR databases for a global registry. And this global registry is required as of today. As you all know, IPv4 is already harder to get; policy has changed last year so LIRs can only get enough for a 1 year period rather than a 2 year period. In my opinion, this is a 'pie in the sky' idea. It is unlikely for a global policy to establish itself within any reasonable time if that policy would abandon the single most significant asset of any RIR; their database. 2) Transparency Any decision regarding allocation or assignment must be done in a transparent and public way and consistent with the bottom-up policy process. Any deficiencies should be removed from policy before then. And globally, of course. I fully agree on transparency. What I fail to see is what is meant with 'public way' and why 2007-08 would fall short of that mark. The RIRs don't currently make the arguments based on which an LIR receives an allocation public, either. When IPv4 space moves hands because of a merger or acquisition this doesn't happen either. That's all current bottom-up policy. 3) Fair and neutral reuse All recovered address space should be recycled in a globally synchronized fashion. RIRs should work harder recovering IPv4 space. I think that this is a good idea, but let's not overestimate what IANA and the RIRs are able to recover. Current global demand is among the lines of 13 /8s a year. Taking low-hanging fruit that has already been recovered into account we can perhaps recycle another dozen /8s. Recovering those will take years. The same goes for re-tasking any experimental or reserved space to 'global unicast'. It would take years to accomplish and only have a very limited impact. As I've said in one of my presentations, even if we were to find a brand new and completely empty IPv4 space somewhere (which will not happen) we'd probably use that up in a decade as well. The fundamental issue is consumption, not lack of production. 4) Self-regulation Allocation of IPv4 addresses should always be guided and regulated by the bottom-up process of the RIRs. Fully agreed. What we probably do not agree upon is what comes out of this process. In addition, one of my main reasons for pushing 2007-08 is that I would very much like that the RIRs stay relevant and the process stays in place. Removing IPv4 from the grasp of the RIRs (and therefore also from the bottom-up policy process) is the single most significant risk of not facing the 'afterlife' in a timely fashion. The moment the RIRs say 'no you can't have more space and you're not allowed to get it anywhere else' is the moment the world turns to another place for that resource. I find it curious that ETNO puts significant effort into writing position papers such as this one and not join us in that bottom-up process, but that's a different matter. 5) No connection between IPv4 and IPv6 Policies we make for the 'afterlife' of IPv4 should not affect any policy with regard to IPv6. Yes. 2007-08 is in compliance with that. In another chapter, ETNO also addresses a few aspects they think should be taken under consideration. In their point of view, we can either get a reclaim/reuse model or a transfer model. I think we can get both, provided we change allocation policy so that a single request can not wipe out carefully built-up reserves. This falls outside of 2007-08 or any other current policy proposal but I'd expect a proposal sooner rather than later. In describing transfers, ETNO argues that transfers are the first step towards a market. That is false. It is the first step towards a market under the control of the RIRs and the current bottom-up policy process we all know and love. A market will evolve whether we accommodate it or not. The report also reiterates that by adopting transfers we abandon that bottom-up policy process. I don't remember putting that in my proposal - perhaps I should read it again. To finish up, the ETNO paper worries about the options RIRs might have to enforce policies in a transfer situation. I'll let you in on a secret: how many times has a conflict been brought to the RIPE NCC arbitration council? Once. Just one. That either means that we all gladly and completely abide set policy or that the real world options RIRs have to enforce policy are limited in the first place. I'll let you choose. In summary: Thanks for bearing with me - this is quite a bit longer than I anticipated it to be. The ETNO position paper gives us a fascinating view of the 'afterlife' and tells us that none of the options we currently have will be an acceptable substitute for the IANA free pool from the ETNO perspective. It also tells us that we should abandon regional policy while at the same time keeping the current bottom-up policy process. This puzzles me. The one reason I could find in the entire paper why ETNO does not like 2007-08 is that it does not like the idea of a market. Neither do I. But 2007-08 is not about a market. It is a fallacy to think that any of us can either create a market or prevent one from being created. That is particularly so in an environment that will have global demand and (potentially) supply. 2007-08 is about staying relevant in an environment where a market evolves. I am fully aware that an evolving market will bring all sorts of interest, not in the last place from regulators. But it's not the regulators we should fear; letting it all slip through our hands is what we should worry about. Creating a transfer policy shows that we as a community can be part of a solution and show good stewardship, not just part (and cause) of the problem. People who are part of the solution will have a seat at the table - the people who merely caused the problem will not. Inaction is not a sign of good stewardship. So we need to be seen doing something, preferably something that will make a difference. So let's consider the alternatives: either we enable transfers or we prevent running out of IPv4 space. I can come up with a policy proposal for that as well - I'm positive you're going to like it even less than this one. If we would only allow justification for new v4 allocations to be based on servers and network infrastructure and not on 'eyeballs' we'd see our consumption rate evaporate overnight and the IANA free pool will last us at least a decade longer, while at the same time forcing the 'eyeballs' to move to IPv6. Think that's a better idea? Personally, I think not. I would urge ETNO to become part of this discussion and work with the community in our prized bottom-up policy process, rather than setting limits to what can and can not be discussed an not coming up with solutions themselves. I thank you for your time and look forward to your responses. Best, Remco van Mook (no hats)

4 4

A comment on 2008-03 & 2007-09
by Brian Nisbet 03 Jun '08

03 Jun '08

Afternoon, First off let me say that I am broadly in agreement with 2008-03, but I wished to make clear my thoughts on the incompatibility of the two proposals in the subject. I see 2008-03 as an exercise in fairness, a way to evenly distribute the last few /8s, rather than reaching a point where, particularly, AfriNIC and LACNIC need more addresses and find there to be none. However it strikes me that this policy is completely incompatible with 2007-09. If both policies were introduced then I can easily envisage a scenario where a bigger RIR uses up its /8, then starts to nibble away at the remaining addresses of those who will be slower to allocate their space, ie AfriNIC and LACNIC, thus defeating the purpose of fairness that I see inherent in 2008-03. The worse case scenario here, for the less developed RIRs at least, is that they may see very little of that last /8. I realise that many people have different views of the impetus behind 2008-03, but I can only view it through my eyes, so apologies if anyone feels I'm attributing motive where there is none. Regards, Brian.

7 15

RE: [address-policy-wg] A comment on 2008-03 & 2007-09
by Raul Echeberria 02 Jun '08

02 Jun '08

Michael: I disagree with you. RIR YES would need a policy for doing what you are suggesting. In fact, the policy proposed is a particular case of what you are suggestign. When there are only 5 /8s IANA ask all the RIRs what would be your future (short term) needs. And obviously the answer would be "At least one /8". Raúl At 06:59 a.m. 01/06/2008, michael.dillon(a)bt.com wrote: > > I am curious about other situation. > > Suppose that IANA allocates the last 2 /8s to the RIR A and > > one day later IANA receives a request from the RIR B that is > > running out of > > IPv4 addresses while the RIR A has (at least) 2 /8s. > >I don't think that IANA would ever do this because it would be >an incredibly stupid thing to do. Since I have never heard IANA >being accused of gross incompetence before, I have to believe >that when they receive that request from RIR A, they will ask all >the other RIRs about how many addresses they need before allocating >anything. In fact, I expect IANA to do this well before the last >2 /8 blocks. Then, after consulting all RIRs, I expect IANA to >publish their intentions and ask for comments before allocating >any blocks. > >This is just good business practice and I don't think that the RIRs >need to write policies which tell IANA to do this. > >--Michael Dillon > > >-- >No virus found in this incoming message. >Checked by AVG. >Version: 7.5.524 / Virus Database: 269.24.4/1474 >- Release Date: 30/05/2008 07:44 a.m.

2 1