From sander at steffann.nl Sat Sep 5 16:09:22 2009 From: sander at steffann.nl (Sander Steffann) Date: Sat, 5 Sep 2009 16:09:22 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 Message-ID: Hello again, After my last questions I have only received concrete answers from Michael. He suggested the following: - Use a minimum allocation size of /24 - Determine the maximum allocation size for every LIR based on their run rate - Make no exceptions for cases where it is hard or impossible to downscale Jim asked why we should change the policy at all for the final /8. I hope I have given at least one good reason: new entrants. Michael proposed to leave (further) decisions about the final /8 until IANA runs out of IPv4 addresses. Does this represent the view of the community? I am not sure if people keep quiet because they agree with what has already been said, or because they are still on vacation... Please let us know :) Thank you, Sander Steffann APWG co-chair From mark at streamservice.nl Sun Sep 6 13:33:53 2009 From: mark at streamservice.nl (Mark Scholten) Date: Sun, 6 Sep 2009 13:33:53 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: Message-ID: <001a01ca2ee5$ea0253d0$be06fb70$@nl> Hello Sander, I don't agree with Jim to wait with the policy for the final /8 (if it ever comes) until IANA runs out of IPv4 addresses. Use a minimum allocation size of /24 is a good thing. A maximum allocation size for a LIR could be a /22 per time they ask for IP addresses, a case-by-case limit is something I won't support. Make exceptions if it is impossible to downscale, if it is hard to downscale (but possible) it should be no exception. To see if it is possible to downscale is something the LIR and the RIPE NCC should (not) agree on, if they don't agree the decision the RIPE NCC did make should be followed. The LIR on the other hand could ask the RIPE NCC why they think/know it is possible to downscale. Services/access that is possible via IPv4 addresses in the last /8 should also be useable via IPv6. If that is not possible internal IPv4 addresses should be used if you ask me. Regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: zaterdag 5 september 2009 16:09 To: address-policy-wg at ripe.net Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 Hello again, After my last questions I have only received concrete answers from Michael. He suggested the following: - Use a minimum allocation size of /24 - Determine the maximum allocation size for every LIR based on their run rate - Make no exceptions for cases where it is hard or impossible to downscale Jim asked why we should change the policy at all for the final /8. I hope I have given at least one good reason: new entrants. Michael proposed to leave (further) decisions about the final /8 until IANA runs out of IPv4 addresses. Does this represent the view of the community? I am not sure if people keep quiet because they agree with what has already been said, or because they are still on vacation... Please let us know :) Thank you, Sander Steffann APWG co-chair From nick at inex.ie Sun Sep 6 22:42:32 2009 From: nick at inex.ie (Nick Hilliard) Date: Sun, 06 Sep 2009 21:42:32 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: Message-ID: <4AA41EB8.3050304@inex.ie> On 05/09/2009 15:09, Sander Steffann wrote: > Hello again, > > After my last questions I have only received concrete answers from > Michael. He suggested the following: > - Use a minimum allocation size of /24 > - Determine the maximum allocation size for every LIR based on their run > rate > - Make no exceptions for cases where it is hard or impossible to downscale Sander, The issue of the last /8 is simply a question of determining the shape of the depletion curve. We know our where we are on this curve right now, and we know how fast we're slipping down it. We also know that after the curve hits zero, life will muddle on. The issue that we're tying ourselves up in knots about is how to find some way of allocating the last iana-assigned address blocks in a way which is more "fair" than it's currently allocated. As a recap, the RIPE NCC currently allocates / assigns space on the basis of stated requirement over a specific time period. I think it's reasonable to say that most LIRs and most members of the RIPE community find this to be a "fair" mechanism. It's not perfect - no resource allocation mechanism of any form is - but with 20 years hindsight, we still haven't come up with a "fairer" system. There have been some suggestions about increasing "fairness" by giving preferential treatment for certain types of applicants. E.g. new LIRs might get certain preferential entitlements, while existing LIRs might get less than they request. This sort of policy strikes right to the heart of "fairness", as what's very fair and right for the organisations receiving preferential treatment is going to be very unfair and quite wrong for the organisations which are discriminated against. If RIPE and the RIPE NCC are looking for a quick and easy way of attracting nasty and sustained criticism (and lawsuits), this is a damn good way to do it. Balanced against this is a necessity to ensure that address-block hogging is minimised in the last days of easily available ipv4 address space (let's not kid ourselves into believing that it can be eliminated). To this end, Policy Proposal 2009-03 provides a remarkably succinct tweak to the current allocation mechanism which looks like it will hinder address block hogging in a manner which is completely open, completely non-discriminatory and entirely reasonable under the circumstances. It doesn't attempt to redefine the current assignment mechanism - which is a good thing of itself. It doesn't create a rampantly unfair new mechanism which is untried and untested. It doesn't start some new assignment policy based on a rather arbitrary basis (why /8? why not /7 or /9?) It changes very little, except for smoothing out some bumps on the tail end of the allocation curve. And although I dislike the title of the policy very much (I can volunteer to act as neutral third party to count votes for the colour of this particular bikeshed, if people are interested?), I would like to propose that we simply drop all current policy proposals about changing allocation mechanisms for the last /8 and work on 2009-03 instead. By "work on" I mean that the proposal as it stands may need very minor tweaking (e.g. considering whether to change the time-scales which are currently hard-coded in the proposal into time-scales which are based on historical run rates). But the policy proposal as it stands is good and I like it very much indeed. I would also like to propose that we consider at this stage whether it would be useful to reserve small quantities of virgin address space for specific _temporary_ assignment / allocation purposes. Things like the current experimental assignment system, and maybe conferences and that sort of thing. But the critical criterion here is that the assignments / allocations are strictly temporary, and that there is a well-defined upper bound on the maximum time limit for the assignment / allocation. Other than temporary assignments, I don't realistically see a means of non-contentiously reserving other address blocks for permanent assignment / allocation. In summary, I propose we drop 2008-06 and 2009-04, that we adopt 2009-03 and that we come to realise that these endless discussions on the assignment of the last iana /8 are not going anywhere. Nick From sander at steffann.nl Mon Sep 7 00:10:36 2009 From: sander at steffann.nl (Sander Steffann) Date: Mon, 7 Sep 2009 00:10:36 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AA41EB8.3050304@inex.ie> References: <4AA41EB8.3050304@inex.ie> Message-ID: <8597F7BC-3E4B-4F7E-AA34-A83A67AD8C59@steffann.nl> Hello Nick, > There have been some suggestions about increasing "fairness" by > giving preferential treatment for certain types of applicants. E.g. > new LIRs might get certain preferential entitlements, while existing > LIRs might get less than they request. This sort of policy strikes > right to the heart of "fairness", as what's very fair and right for > the organisations receiving preferential treatment is going to be > very unfair and quite wrong for the organisations which are > discriminated against. If RIPE and the RIPE NCC are looking for a > quick and easy way of attracting nasty and sustained criticism (and > lawsuits), this is a damn good way to do it. Preferential treatment will indeed cause problems. The existing LIRs using up all remaining IPv4 addresses in a short time will also cause problems. I agree that we need a policy that is the same for everybody. > Balanced against this is a necessity to ensure that address-block > hogging is minimised in the last days of easily available ipv4 > address space (let's not kid ourselves into believing that it can be > eliminated). To this end, Policy Proposal 2009-03 provides a > remarkably succinct tweak to the current allocation mechanism which > looks like it will hinder address block hogging in a manner which is > completely open, completely non-discriminatory and entirely > reasonable under the circumstances. The problem with dropping all final /8 proposals except 2009-03 is that with 2009-03 the addresses will be used up as quickly as with the current policy. The addresses are requested in smaller blocks but there is no downscaling of the request size. Instead of requesting enough addresses for one year once per year organizations will request enough addresses for 6 months twice per year. The cumulative run rate will remain the same. That means that the existing LIRs will use up all remaining IPv4 addresses in a few months, which is a very bad situation (IMHO/IANAL/etc). 2009-03 is meant to prevent that a few very big requests use up all remaining addresses, which is important. It doesn't solve the problems that 2008-06 and 2009-04 try to solve. 2009-03 explicitly mentions this: "The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants." > It doesn't attempt to redefine the current assignment mechanism - > which is a good thing of itself. It doesn't create a rampantly > unfair new mechanism which is untried and untested. It doesn't > start some new assignment policy based on a rather arbitrary basis > (why /8? why not /7 or /9?) It changes very little, except for > smoothing out some bumps on the tail end of the allocation curve. Exactly. > And although I dislike the title of the policy very much (I can > volunteer to act as neutral third party to count votes for the > colour of this particular bikeshed, if people are interested?), I > would like to propose that we simply drop all current policy > proposals about changing allocation mechanisms for the last /8 and > work on 2009-03 instead. I fully agree with working on 2009-03, but I'm not yet convinced that we should abandon the other final /8 proposals. > By "work on" I mean that the proposal as it stands may need very > minor tweaking (e.g. considering whether to change the time-scales > which are currently hard-coded in the proposal into time-scales > which are based on historical run rates). But the policy proposal > as it stands is good and I like it very much indeed. I agree. I like it too, but not for the purpose you want to use it for :) > I would also like to propose that we consider at this stage whether > it would be useful to reserve small quantities of virgin address > space for specific _temporary_ assignment / allocation purposes. > Things like the current experimental assignment system, and maybe > conferences and that sort of thing. But the critical criterion here > is that the assignments / allocations are strictly temporary, and > that there is a well-defined upper bound on the maximum time limit > for the assignment / allocation. Other than temporary assignments, > I don't realistically see a means of non-contentiously reserving > other address blocks for permanent assignment / allocation. Reserving address space for temporary assignments sounds like a good plan. Thanks, Sander From nick at inex.ie Mon Sep 7 12:54:24 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 07 Sep 2009 11:54:24 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <8597F7BC-3E4B-4F7E-AA34-A83A67AD8C59@steffann.nl> References: <4AA41EB8.3050304@inex.ie> <8597F7BC-3E4B-4F7E-AA34-A83A67AD8C59@steffann.nl> Message-ID: <4AA4E660.5070700@inex.ie> On 06/09/2009 23:10, Sander Steffann wrote: > The problem with dropping all final /8 proposals except 2009-03 is that > with 2009-03 the addresses will be used up as quickly as with the > current policy. The addresses are requested in smaller blocks but there > is no downscaling of the request size. Instead of requesting enough > addresses for one year once per year organizations will request enough > addresses for 6 months twice per year. The cumulative run rate will > remain the same. Yep, exactly. As I mentioned, the only thing that changes is that the depletion curve becomes slightly smoother. The run rate will still be the same. > That means that the existing LIRs will use up all > remaining IPv4 addresses in a few months, which is a very bad situation > (IMHO/IANAL/etc). Any plan to restrict address availability in order to make things last longer will involve discriminating in favour of some organisations and therefore discriminating against other organisations. Given that the RIPE NCC operates a monopoly on useful ipv4 address allocation in the europe / middle east regions, discrimination is a very dangerous path to go down. I'm not saying it's impossible, just that choosing a system which implements discrimination in a way that the RIPE community and other interested stakeholders (including various regulatory authorities and the Dutch courts) would perceive as being "fair" is going to be very difficult. And it will only be a temporary measure: depletion will happen, and then we will have to muddle on. Nick From jim at rfc1035.com Mon Sep 7 13:10:25 2009 From: jim at rfc1035.com (Jim Reid) Date: Mon, 7 Sep 2009 12:10:25 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AA41EB8.3050304@inex.ie> References: <4AA41EB8.3050304@inex.ie> Message-ID: On 6 Sep 2009, at 21:42, Nick Hilliard wrote: > In summary, I propose we drop 2008-06 and 2009-04, that we adopt > 2009-03 and that we come to realise that these endless discussions > on the assignment of the last iana /8 are not going anywhere. I could live with that. Though I'd be more than happy if discussions about what do with the last /8 continued until they didn't matter any more. :-) From nominations at ripe.net Thu Sep 10 15:45:28 2009 From: nominations at ripe.net (Axel Pawlik) Date: Thu, 10 Sep 2009 15:45:28 +0200 Subject: [address-policy-wg] RIPE NCC NRO Number Council Candidates Confirmed Message-ID: [Apologies for duplicate emails] Dear Colleagues, The nomination period for appointment to the Number Resource Organization (NRO) Number Council (NC) has now closed. This year, in accordance with the Number Resource Organization's Memorandum of Understanding (NRO MoU), the RIPE community will elect one individual to fill the seat that is being vacated by Dave Wilson, who was elected to a three-year term on the NRO NC that began on 1 January 2007. The following candidates have accepted their nomination for the vacant seat on the NRO NC from the RIPE NCC service region: - Dave Wilson The representative elected to the NRO NC seat will serve a three-year term, beginning 1 January 2010. Candidate profiles and information on how to submit an Expression of Support can be found at: http://www.ripe.net/info/resource-admin/nro2009/confirmed-nominations.html The election to fill this seat will be held at the RIPE 59 Meeting that takes place in Lisbon, Portugal from 5-9 October 2009. For more information about the NRO NC and the selection process, see: http://www.ripe.net/info/resource-admin/nro2008/about-nc.html Regards, Axel Pawlik Managing Director, RIPE NCC From kamil at extendbroadband.com Fri Sep 11 12:36:36 2009 From: kamil at extendbroadband.com (Kamil Semavi) Date: Fri, 11 Sep 2009 13:36:36 +0300 Subject: [address-policy-wg] (no subject) Message-ID: <000001ca32cb$bd309cb0$3791d610$@com> How can I transfer a subnet from one AS to another AS number? Thanks Kamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Fri Sep 11 13:31:15 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 11 Sep 2009 20:31:15 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: Message-ID: <4AAA3503.6090203@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: > Jim asked why we should change the policy at all for the final /8. I > hope I have given at least one good reason: new entrants. Michael > proposed to leave (further) decisions about the final /8 until IANA > runs out of IPv4 addresses. Another good reason to change the policy is recent development of NAT technology. Recent NAT even allows for end to end transparency that there is no reason for old entrants not to deploy NAT to reduce address consumption to leave room for new entrants. Masataka Ohta PS If we wisely allocate the final /8s, we will be ready to allocate class E and part of class D for unicast before we run out of classes A, B and C. That is, we don't need IPv6. From heldal at eml.cc Sat Sep 12 01:02:29 2009 From: heldal at eml.cc (Per Heldal) Date: Sat, 12 Sep 2009 01:02:29 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AAA3503.6090203@necom830.hpcl.titech.ac.jp> References: <4AAA3503.6090203@necom830.hpcl.titech.ac.jp> Message-ID: <1252710149.27841.33.camel@obelix> On Fri, 2009-09-11 at 20:31 +0900, Masataka Ohta wrote: > Another good reason to change the policy is recent development > of NAT technology. > > Recent NAT even allows for end to end transparency that there > is no reason for old entrants not to deploy NAT to reduce address > consumption to leave room for new entrants. > > Masataka Ohta > > PS > > If we wisely allocate the final /8s, we will be ready to allocate > class E and part of class D for unicast before we run out of > classes A, B and C. > > That is, we don't need IPv6. > Would you care to share a bit of whatever you're smoking ? :) I'm afraid the transition to v6 will be well on its way by the time the NAT traversal workarounds that are floating around in various drafts make their way through IETF and into the new generation of HW/SW required to support it. Industry-wide standardisation is what counts in this area. The next forklift upgrade of software and/or firmware that providers make to their access-layer and CPE's will most likely have IPv6 already. I'm not saying that v4 NAT won't play a certain role during the transition-phase, but I don't consider it's a viable long-term solution. The only argument in favor of changing policies at this stage is IMHO to, if possible, be able to dodge accusations of anti-competitive practises against new entrants. All that is required for that is to reserve a relatively small block from which everyone who qualify for a /32 or larger PA v6-block gets for example a /22 v4-block if they have no prior v4 allocation. Everything else that has been suggested are policy tweaks which aim to benefit certain types of operators, but they make no significant difference to the bigger picture. //per From mohta at necom830.hpcl.titech.ac.jp Sat Sep 12 04:01:29 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 12 Sep 2009 11:01:29 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <1252710149.27841.33.camel@obelix> References: <4AAA3503.6090203@necom830.hpcl.titech.ac.jp> <1252710149.27841.33.camel@obelix> Message-ID: <4AAB00F9.9090300@necom830.hpcl.titech.ac.jp> Per Heldal wrote: >>If we wisely allocate the final /8s, we will be ready to allocate >>class E and part of class D for unicast before we run out of >>classes A, B and C. >> >>That is, we don't need IPv6. > Would you care to share a bit of whatever you're smoking ? :) Sure. Talk with real world ISPs. > I'm afraid the transition to v6 will be well on its way by the time the > NAT traversal workarounds that are floating around in various drafts > make their way through IETF and into the new generation of HW/SW > required to support it. NAT traversal won't work, because they need modifications on applications. Moreover, IETF has no control over NAT. ISPs, instead, can modify their equipment to support transparent NAT they prefer, regardless of whether it is IETF standard or not. > Industry-wide standardisation is what counts in this area. Not at all. For example, NAT was deployed without IETF standardization. For another example, ISPs are happy to use RADIUS with their own extensions not standardized by IETF. > The next forklift upgrade of software and/or firmware that > providers make to their access-layer and CPE's will most likely have > IPv6 already. The problem for ISPs to support IPv6 is operational cost, which is greater than that of IPv4, which is why most ISPs won't support IPv6 in addition to IPv4. > I'm not saying that v4 NAT won't play a certain role > during the transition-phase, but I don't consider it's a viable > long-term solution. A viable long-term solution is yet another IPng, which is easy to operate, easier than IPv4. Until we have such a protocol, we should depend on NAT to reduce IPv4 address space consumption. You know, NAT is easy to operate. Masataka Ohta From sander at steffann.nl Sat Sep 12 13:43:41 2009 From: sander at steffann.nl (Sander Steffann) Date: Sat, 12 Sep 2009 13:43:41 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <1252710149.27841.33.camel@obelix> References: <4AAA3503.6090203@necom830.hpcl.titech.ac.jp> <1252710149.27841.33.camel@obelix> Message-ID: <4A30497E-0282-48D4-A436-20CBB048FBA2@steffann.nl> Hello Per, > The only argument in favor of changing policies at this stage is IMHO > to, if possible, be able to dodge accusations of anti-competitive > practises against new entrants. That is indeed the concern that I have. > All that is required for that is to > reserve a relatively small block from which everyone who qualify for > a /32 or larger PA v6-block gets for example a /22 v4-block if they > have > no prior v4 allocation. Such a policy would solve my main concern. I would remove the reference to IPv6 because earlier parts of this discussion showed that we don't want to put IPv6 requirements in IPv4 policy. I think just reserving a block like this for initial allocations would be enough. > Everything else that has been suggested are > policy tweaks which aim to benefit certain types of operators, but > they > make no significant difference to the bigger picture. It seems more and more people are happy with the current policies and don't want to change them for the final /8. Would a simple policy like Per suggests be acceptable for everybody? Thanks, Sander From heldal at eml.cc Mon Sep 14 12:29:49 2009 From: heldal at eml.cc (Per Heldal) Date: Mon, 14 Sep 2009 12:29:49 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4A30497E-0282-48D4-A436-20CBB048FBA2@steffann.nl> References: <4AAA3503.6090203@necom830.hpcl.titech.ac.jp> <1252710149.27841.33.camel@obelix> <4A30497E-0282-48D4-A436-20CBB048FBA2@steffann.nl> Message-ID: <1252924189.19811.15.camel@obelix> On Sat, 2009-09-12 at 13:43 +0200, Sander Steffann wrote: > > All that is required for that is to > > reserve a relatively small block from which everyone who qualify for > > a /32 or larger PA v6-block gets for example a /22 v4-block if they > > have > > no prior v4 allocation. > > Such a policy would solve my main concern. I would remove the > reference to IPv6 because earlier parts of this discussion showed that > we don't want to put IPv6 requirements in IPv4 policy. I think just > reserving a block like this for initial allocations would be enough. Some people think the block required for this purpose should be made as small as possible. The intention with these assignments is to provide addresses for transition-services. Yet, we can't expect the NCC to judge an applicants intentions. Thus, my suggestion above restricts the handouts to new PA-holders only. I guess someone from the NCC can dig out the exact annual ratio of PI to PA blocks (1st assignment to new LIRs only), but just judging by the unfiltered PA/PI ratio suggest that the difference is significant. Leaving an opening for allocations to PI-holders requires a bigger v4-block to be reserved. I personally have no strong preference for either alternative. It was just an attempt at a variation of what's been suggested before. //per From michiel at klaver.it Mon Sep 14 12:55:53 2009 From: michiel at klaver.it (Michiel Klaver) Date: Mon, 14 Sep 2009 12:55:53 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: Message-ID: <4AAE2139.7060706@klaver.it> Sander Steffann wrote: > Hello again, > > After my last questions I have only received concrete answers from > Michael. He suggested the following: > - Use a minimum allocation size of /24 > - Determine the maximum allocation size for every LIR based on their run > rate > - Make no exceptions for cases where it is hard or impossible to downscale > > Jim asked why we should change the policy at all for the final /8. I > hope I have given at least one good reason: new entrants. Michael > proposed to leave (further) decisions about the final /8 until IANA runs > out of IPv4 addresses. > > Does this represent the view of the community? I am not sure if people > keep quiet because they agree with what has already been said, or > because they are still on vacation... Please let us know :) > > Thank you, > Sander Steffann > APWG co-chair > I would suggest we wait until we hit the final /12 and assign those addresses as fixed /24 blocks only. Big enough for new entrants to setup their IPv4 network and communicate with the 'legacy' internet of today. Too small for the rest of us and force everyone to dive into the deep with IPv6. With kind regards, Michiel Klaver IT Professional From sander at steffann.nl Mon Sep 14 15:03:23 2009 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Sep 2009 15:03:23 +0200 (CEST) Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AAE2139.7060706@klaver.it> References: <4AAE2139.7060706@klaver.it> Message-ID: <2978.80.101.103.96.1252933403.squirrel@webmail.sintact.nl> Hi Michiel, > I would suggest we wait until we hit the final /12 and assign those > addresses as fixed /24 blocks only. Big enough for new entrants to setup > their IPv4 network and communicate with the 'legacy' internet of today. > Too small for the rest of us and force everyone to dive into the deep > with IPv6. If I understand you correctly this would be something like proposed in http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2009/msg00720.html, with a reserved /12 for initial allocations of a fixed /24 size. Or do you mean something different? Thanks, Sander From michiel at klaver.it Mon Sep 14 15:15:45 2009 From: michiel at klaver.it (Michiel Klaver) Date: Mon, 14 Sep 2009 15:15:45 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <2978.80.101.103.96.1252933403.squirrel@webmail.sintact.nl> References: <4AAE2139.7060706@klaver.it> <2978.80.101.103.96.1252933403.squirrel@webmail.sintact.nl> Message-ID: <4AAE4201.1070707@klaver.it> Sander Steffann wrote: > Hi Michiel, > >> I would suggest we wait until we hit the final /12 and assign those >> addresses as fixed /24 blocks only. Big enough for new entrants to setup >> their IPv4 network and communicate with the 'legacy' internet of today. >> Too small for the rest of us and force everyone to dive into the deep >> with IPv6. > > If I understand you correctly this would be something like proposed in > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2009/msg00720.html, > with a reserved /12 for initial allocations of a fixed /24 size. > > Or do you mean something different? > > Thanks, > Sander > > Hi Sander, that indeed is the same, except for the size of the reserved assignments. With a /12 divided into fixed /24 prefixes you will create a pool of 4096 available /24 blocks. Given the current RIPE LIR member count of 5000+ and still growing, that amount of 4096 /24 blocks should be sufficient for a number of years. With kind regards, Michiel Klaver IT Professional From marc.neuckens at belgacom.be Mon Sep 14 17:00:28 2009 From: marc.neuckens at belgacom.be (marc.neuckens at belgacom.be) Date: Mon, 14 Sep 2009 17:00:28 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AAE4201.1070707@klaver.it> References: <4AAE2139.7060706@klaver.it> <2978.80.101.103.96.1252933403.squirrel@webmail.sintact.nl> <4AAE4201.1070707@klaver.it> Message-ID: Michiel, I support this proposal. * Simple * Deterministic * Very little impact on final date for existing LIR (8 days earlier if we take the 2008 IPv4 address consumption in RIPE) * Reduced impact on routing table size (+ fixed prefix length) * Easy for RIPE NCC to implement. Question : what about PI ? Marc Neuckens Belgacom > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Michiel Klaver > Sent: 14 September 2009 15:16 > To: Sander Steffann; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] The final /8 policy proposals, part 3.2 > > Sander Steffann wrote: > > Hi Michiel, > > > >> I would suggest we wait until we hit the final /12 and assign those > >> addresses as fixed /24 blocks only. Big enough for new entrants to setup > >> their IPv4 network and communicate with the 'legacy' internet of today. > >> Too small for the rest of us and force everyone to dive into the deep > >> with IPv6. > > > > If I understand you correctly this would be something like proposed in > > http://www.ripe.net/ripe/maillists/archives/address-policy- > wg/2009/msg00720.html, > > with a reserved /12 for initial allocations of a fixed /24 size. > > > > Or do you mean something different? > > > > Thanks, > > Sander > > > > > > > Hi Sander, > > that indeed is the same, except for the size of the reserved > assignments. With a /12 divided into fixed /24 prefixes you will create > a pool of 4096 available /24 blocks. Given the current RIPE LIR member > count of 5000+ and still growing, that amount of 4096 /24 blocks should > be sufficient for a number of years. > > > With kind regards, > > Michiel Klaver > IT Professional **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer From filiz at ripe.net Mon Sep 14 17:57:46 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 14 Sep 2009 17:57:46 +0200 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries Message-ID: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> Dear Colleagues, 2009-01, "Global Policy for the allocation of IPv4 blocks to Regional Internet Registries" is a global policy proposal. You may remember discussions on it started in all regions around the beginning of 2009. The full text of the proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-01.html AfriNIC, APNIC and LACNIC have reached consensus on the proposal so far. In ARIN, however, a revised text, different to the one in submitted to the RIPE Policy Development Process (PDP) and in other regions, was introduced by the ARIN Advisory Council (ARIN AC). Following community discussion at the ARIN Public Policy Meeting in April 2009, the ARIN AC was tasked with further editing the text. This situation was reported to the RIPE community at RIPE 58. The RIPE community's feedback at that time was that the ARIN version of the proposal should be considered. Today, the ARIN AC has submitted a revised text for discussion in the ARIN community. You can find the current ARIN version of the proposal at: https://www.arin.net/policy/proposals/2009_3.html For your convenience, the major differences between the original ARIN text, the new ARIN version and the current RIPE version have been summarised below. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC -------------------------------------------- Old ARIN "A. Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. At quarterly intervals, each RIR shall return to the IANA any legacy address space recovered, and may return to the IANA any non-legacy address space recovered, in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. New ARIN "A. Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. RIPE "3.1 Phase I" Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. -------------------------------------------- From leo.vegoda at icann.org Mon Sep 14 18:36:23 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 14 Sep 2009 09:36:23 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AAE4201.1070707@klaver.it> Message-ID: On 14/09/2009 6:15, "Michiel Klaver" wrote: [...] > that indeed is the same, except for the size of the reserved > assignments. With a /12 divided into fixed /24 prefixes you will create > a pool of 4096 available /24 blocks. Given the current RIPE LIR member > count of 5000+ and still growing, that amount of 4096 /24 blocks should > be sufficient for a number of years. Just be aware that the number of years is likely to be quite small. According to the statistics published on the RIPE NCC's FTP site, it assigned more than 1,000 /24 prefixes last year. The same statistics indicate that about 3,700 prefixes of all lengths were assigned or allocated last year. I don't think we can assume that demand for IPv4 address space will reduce and I also think it is reasonable for networks that would previously been happy with some PA space from their ISP to get space direct from the RIPE NCC if it is the only game in town. I don't know how many years people want small blocks of IPv4 address space to be available for under a policy along these lines but I think if it is more than just one or two it probably needs to be designed in a way that takes account of historic demand and how people will react when other avenues are cut off. Regards, Leo Vegoda From sander at steffann.nl Mon Sep 14 21:50:21 2009 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Sep 2009 21:50:21 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: Message-ID: <72E6F93B-D77F-45C5-8E31-8461D3D54C90@steffann.nl> Hi Leo, > Just be aware that the number of years is likely to be quite small. > According to the statistics published on the RIPE NCC's FTP site, it > assigned more than 1,000 /24 prefixes last year. We are talking about PA prefixes here, and this pool is only meant for initial allocations (PA), not PI. > The same statistics indicate that about 3,700 prefixes of all > lengths were > assigned or allocated last year. I don't think we can assume that > demand for > IPv4 address space will reduce and I also think it is reasonable for > networks that would previously been happy with some PA space from > their ISP > to get space direct from the RIPE NCC if it is the only game in town. True. There might be organizations that become an LIR to get that initial /24 allocation. > I don't know how many years people want small blocks of IPv4 address > space > to be available for under a policy along these lines but I think if > it is > more than just one or two it probably needs to be designed in a way > that > takes account of historic demand and how people will react when other > avenues are cut off. Because this is just for initial allocations, I think 2 to 4 years is a reasonable timeframe. IPv4 will run out. This is only meant to make sure that new entrants have a few IPv4 addresses to work with. - Sander From Woeber at CC.UniVie.ac.at Mon Sep 14 22:01:19 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 14 Sep 2009 20:01:19 +0000 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> Message-ID: <4AAEA10F.2070607@CC.UniVie.ac.at> Hi Filiz, community, thanks for the alert and the summary of changes/differences! As a non-native speaker I am looking for a clarification, please see below. Filiz Yilmaz wrote: > > Dear Colleagues, > > 2009-01, "Global Policy for the allocation of IPv4 blocks to Regional > Internet Registries" is a global policy proposal. You may remember > discussions on it started in all regions around the beginning of 2009. > The full text of the proposal can be found at: > http://www.ripe.net/ripe/policies/proposals/2009-01.html > > AfriNIC, APNIC and LACNIC have reached consensus on the proposal so far. [...] > Filiz Yilmaz > Policy Development Manager > RIPE NCC > > -------------------------------------------- > > Old ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. At > quarterly intervals, each RIR shall return to the IANA any legacy > address space recovered, and may return to the IANA any non-legacy > address space recovered, in aggregated blocks of /24 or larger, for > inclusion in the recovered IPv4 pool. > > New ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. I read this as follows: "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and *may* designate any such space for return to the IANA." A different interpretation would be: "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and *will* designate any such space for return to the IANA." > Each RIR shall at > quarterly intervals return any such designated address space to the > IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > RIPE "3.1 Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. Each > RIR shall at quarterly intervals return any such recovered address > space to the IANA in aggregated blocks of /24 or larger, for inclusion > in the recovered IPv4 pool. > > -------------------------------------------- > > Thanks, Wilfried. From scottleibrand at gmail.com Mon Sep 14 22:09:56 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 14 Sep 2009 13:09:56 -0700 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AAEA10F.2070607@CC.UniVie.ac.at> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <4AAEA10F.2070607@CC.UniVie.ac.at> Message-ID: <4AAEA314.7010307@gmail.com> Wilfried Woeber, UniVie/ACOnet wrote: > Hi Filiz, community, > > thanks for the alert and the summary of changes/differences! > > As a non-native speaker I am looking for a clarification, please see below. > > > >> New ARIN "A. Phase I" >> >> Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration and >> designate any such space for return to the IANA. >> > > I read this as follows: > > "Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > *may* designate any such space for return to the IANA." > This is what I intended when writing it: "may" applies to both "recover" and "designate". -Scott > A different interpretation would be: > > "Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > *will* designate any such space for return to the IANA." > > > From Woeber at CC.UniVie.ac.at Mon Sep 14 22:12:24 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 14 Sep 2009 20:12:24 +0000 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AAEA314.7010307@gmail.com> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <4AAEA10F.2070607@CC.UniVie.ac.at> <4AAEA314.7010307@gmail.com> Message-ID: <4AAEA3A8.7020803@CC.UniVie.ac.at> Thanks, Scott, for the clarification! Wilfried. Scott Leibrand wrote: > Wilfried Woeber, UniVie/ACOnet wrote: > >> Hi Filiz, community, >> >> thanks for the alert and the summary of changes/differences! >> >> As a non-native speaker I am looking for a clarification, please see >> below. >> >> >> >> >>> New ARIN "A. Phase I" >>> >>> Each RIR through their respective chosen policies and strategies may >>> recover IPv4 address space which is under their administration and >>> designate any such space for return to the IANA. >>> >> >> >> I read this as follows: >> >> "Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration and >> *may* designate any such space for return to the IANA." >> > > > This is what I intended when writing it: "may" applies to both "recover" > and "designate". > > -Scott > >> A different interpretation would be: >> >> "Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration and >> *will* designate any such space for return to the IANA." >> >> >> > > From leo.vegoda at icann.org Mon Sep 14 22:22:46 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 14 Sep 2009 13:22:46 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <72E6F93B-D77F-45C5-8E31-8461D3D54C90@steffann.nl> Message-ID: On 14/09/2009 12:50, "Sander Steffann" wrote: [...] > We are talking about PA prefixes here, and this pool is only meant for > initial allocations (PA), not PI. I know. >> The same statistics indicate that about 3,700 prefixes of all >> lengths were >> assigned or allocated last year. I don't think we can assume that >> demand for >> IPv4 address space will reduce and I also think it is reasonable for >> networks that would previously been happy with some PA space from >> their ISP >> to get space direct from the RIPE NCC if it is the only game in town. > > True. There might be organizations that become an LIR to get that > initial /24 allocation. Has any work been done to identify what proportion of those organizations that are normally satisfied with PI or PA assignments are likely to go for a /24 PA "allocation" if that's all there is? I think some data identifying likely outcomes would be useful when making deciding on the prefix length to reserve. Regards, Leo From sander at steffann.nl Tue Sep 15 09:48:37 2009 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Sep 2009 09:48:37 +0200 (CEST) Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: Message-ID: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> Hi Leo, >> We are talking about PA prefixes here, and this pool is only meant for >> initial allocations (PA), not PI. > > I know. Ok :) >> True. There might be organizations that become an LIR to get that >> initial /24 allocation. > > Has any work been done to identify what proportion of those organizations > that are normally satisfied with PI or PA assignments are likely to go for > a /24 PA "allocation" if that's all there is? I think some data > identifying likely outcomes would be useful when making deciding on the > prefix length to reserve. Hmmm. This is difficult. I don't think any of us has a crystal ball of that quality. My guess is that the only thing we can do is to reserve more addresses (a /10?) now. We can always decide to 'release' them later if it turns out that we reserved too many. Thanks, Sander From mark at streamservice.nl Tue Sep 15 09:56:17 2009 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 15 Sep 2009 09:56:17 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> References: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> Message-ID: <006c01ca35da$02b528d0$081f7a70$@nl> Hello Sander, Would it be an option to have something written in the policy that means the following? The reserved /10 (or other range) from the last /8 RIPE NCC receives from IANA is to be used for PA allocations. Whenever there are no other addresses available to use for PI allocations the /10 (or part of that)(that effective are the last IPv4 addresses RIPE NCC can provide to the RIPE community at that time) can also be used for other allocations, like PI. Something in the policy mentioning it is a good thing if you ask me, I mention it because making policy takes a while. So I like to mention it directly, if possible, so the RIPE NCC can continue to provide IPv4 addresses as long as they don't run out. Regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: dinsdag 15 september 2009 9:49 To: Leo Vegoda Cc: Michiel Klaver; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] The final /8 policy proposals, part 3.2 Hi Leo, >> We are talking about PA prefixes here, and this pool is only meant for >> initial allocations (PA), not PI. > > I know. Ok :) >> True. There might be organizations that become an LIR to get that >> initial /24 allocation. > > Has any work been done to identify what proportion of those organizations > that are normally satisfied with PI or PA assignments are likely to go for > a /24 PA "allocation" if that's all there is? I think some data > identifying likely outcomes would be useful when making deciding on the > prefix length to reserve. Hmmm. This is difficult. I don't think any of us has a crystal ball of that quality. My guess is that the only thing we can do is to reserve more addresses (a /10?) now. We can always decide to 'release' them later if it turns out that we reserved too many. Thanks, Sander From sander at steffann.nl Tue Sep 15 11:58:54 2009 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Sep 2009 11:58:54 +0200 (CEST) Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <006c01ca35da$02b528d0$081f7a70$@nl> References: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> <006c01ca35da$02b528d0$081f7a70$@nl> Message-ID: <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> Hi Mark, > Would it be an option to have something written in the policy that means > the following? > The reserved /10 (or other range) from the last /8 RIPE NCC receives from > IANA is to be used for PA allocations. Whenever there are no other > addresses available to use for PI allocations the /10 (or part of > that)(that effective are the last IPv4 addresses RIPE NCC can provide to > the RIPE community at that time) can also be used for other allocations, > like PI. The problem with that is that the /10 would be used up in a *very* short time. I think we can get away (legally speaking) with not reserving any address space for separate organisations (PI), but I don't think we can get away with 'blocking the market' for new providers / LIRs (PA). Which is why I proposed to reserve space for PA initial allocations :) I could be wrong here ofcourse... Thanks, Sander From mark at streamservice.nl Tue Sep 15 17:18:26 2009 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 15 Sep 2009 17:18:26 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> References: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> <006c01ca35da$02b528d0$081f7a70$@nl> <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> Message-ID: <007601ca3617$c67c19d0$53744d70$@nl> Hello Sander, I think that in that case PI should be removed. Because else it could have a big legal impact I think. Processing requests from 2 companies different by an organization that has a monopoly isn't a very smart way to work (and the risk for legal issues is very big). With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: dinsdag 15 september 2009 11:59 To: Mark Scholten Cc: 'Leo Vegoda'; 'Michiel Klaver'; address-policy-wg at ripe.net Subject: RE: [address-policy-wg] The final /8 policy proposals, part 3.2 Hi Mark, > Would it be an option to have something written in the policy that means > the following? > The reserved /10 (or other range) from the last /8 RIPE NCC receives from > IANA is to be used for PA allocations. Whenever there are no other > addresses available to use for PI allocations the /10 (or part of > that)(that effective are the last IPv4 addresses RIPE NCC can provide to > the RIPE community at that time) can also be used for other allocations, > like PI. The problem with that is that the /10 would be used up in a *very* short time. I think we can get away (legally speaking) with not reserving any address space for separate organisations (PI), but I don't think we can get away with 'blocking the market' for new providers / LIRs (PA). Which is why I proposed to reserve space for PA initial allocations :) I could be wrong here ofcourse... Thanks, Sander From heldal at eml.cc Tue Sep 15 19:26:17 2009 From: heldal at eml.cc (Per Heldal) Date: Tue, 15 Sep 2009 19:26:17 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> References: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> <006c01ca35da$02b528d0$081f7a70$@nl> <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> Message-ID: <1253035577.27940.25.camel@obelix> On Tue, 2009-09-15 at 11:58 +0200, Sander Steffann wrote: > Which is why I proposed to reserve space for PA initial allocations :) I > could be wrong here ofcourse... Isn't it a bit of a problem that it is rather pointless to talk about initial v4 PA allocations at the point in the end-game when it is no longer possible to meet the requested block-size? In the past we've dismissed suggestions to link v4 allocations to subjective requirements such as "must prove intention to deploy v6". During the runout the situation changes. The only real option for a new PA network operator will be to use v6 (unless there are address-resources available outside the RIR-system). Thus tying micro v4 allocations to v6 PA-allocations makes perfect sense if you want to keep the PI crowd out. //per From leo.vegoda at icann.org Wed Sep 16 17:49:08 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 16 Sep 2009 08:49:08 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <72E6F93B-D77F-45C5-8E31-8461D3D54C90@steffann.nl> Message-ID: Hi, On 14/09/2009 12:50, "Sander Steffann" wrote: [...] >> I don't know how many years people want small blocks of IPv4 address >> space >> to be available for under a policy along these lines but I think if >> it is >> more than just one or two it probably needs to be designed in a way >> that >> takes account of historic demand and how people will react when other >> avenues are cut off. > > Because this is just for initial allocations, I think 2 to 4 years is > a reasonable timeframe. IPv4 will run out. This is only meant to make > sure that new entrants have a few IPv4 addresses to work with. What are the consequences to running out significantly earlier than 2-4 years? How important is the continued availability of small blocks when the bulk of the IPv4 address space ahs already been allocated? Regards, Leo Vegoda From randy at psg.com Wed Sep 16 22:43:42 2009 From: randy at psg.com (Randy Bush) Date: Thu, 17 Sep 2009 05:43:42 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: <72E6F93B-D77F-45C5-8E31-8461D3D54C90@steffann.nl> Message-ID: >> Because this is just for initial allocations, I think 2 to 4 years is >> a reasonable timeframe. IPv4 will run out. This is only meant to make >> sure that new entrants have a few IPv4 addresses to work with. > What are the consequences to running out significantly earlier than > 2-4 years? How important is the continued availability of small blocks > when the bulk of the IPv4 address space ahs already been allocated? trick question assuming v6 transition, how long will it take? until then, everyone will need a teensie bit of v4 to stay connected to the (declining) v4 internet. randy From nick at inex.ie Thu Sep 17 14:22:08 2009 From: nick at inex.ie (Nick Hilliard) Date: Thu, 17 Sep 2009 13:22:08 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <1253035577.27940.25.camel@obelix> References: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> <006c01ca35da$02b528d0$081f7a70$@nl> <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> <1253035577.27940.25.camel@obelix> Message-ID: <4AB229F0.6060208@inex.ie> On 15/09/2009 18:26, Per Heldal wrote: > In the past we've dismissed suggestions to link v4 allocations to > subjective requirements such as "must prove intention to deploy v6". > During the runout the situation changes. yep, you've put your finger on the button. It's not RIPE's position to sit on an ivory tower, wagging its finger at people and saying that they can only have more ipv4 addresses if they agree to swallow some ipv6 medicine. If ipv4 end-users want to move to ipv6, don't get in their way. And if they want to stick with ipv4 in an ipv4 starved world, let them do so. It will hurt them and they will realise themselves that ipv6 offers a better long-term solution. Runout will concentrate peoples' minds wonderfully about what is or isn't the best solution for their businesses. Any attempt to force ipv6 uptake by dangling tiny quantities of ipv4 addresses in front of people will fail horribly and will cause pointless anger and great resentment. Nick From heldal at eml.cc Thu Sep 17 14:49:29 2009 From: heldal at eml.cc (Per Heldal) Date: Thu, 17 Sep 2009 14:49:29 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AB229F0.6060208@inex.ie> References: <1129.80.101.103.96.1253000917.squirrel@webmail.sintact.nl> <006c01ca35da$02b528d0$081f7a70$@nl> <2962.80.101.103.96.1253008734.squirrel@webmail.sintact.nl> <1253035577.27940.25.camel@obelix> <4AB229F0.6060208@inex.ie> Message-ID: <1253191769.4949.15.camel@obelix> On Thu, 2009-09-17 at 13:22 +0100, Nick Hilliard wrote: > It's not RIPE's position to sit > on an ivory tower, wagging its finger at people and saying that they can > only have more ipv4 addresses if they agree to swallow some ipv6 medicine. > Agree for as long as there are addresses enough to meet the applicants needs. Yet it is IMHO pointless to hand out micro-blocks as a sorry response to a PA-request for a substantially larger block. This isn't about forcing anyone in any particular direction, but about whether it is of greater benefit to the community at large to allocate such blocks to organizations with a potential to enable connectivity between large numbers of new users and the existing v4 network. It is about prioritizing the use of a scarce resource as opposed to distributing a plentiful supply. //per From michael.dillon at bt.com Thu Sep 17 17:11:53 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Sep 2009 16:11:53 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <1253191769.4949.15.camel@obelix> Message-ID: <28E139F46D45AF49A31950F88C4974580324E546@E03MVZ2-UKDY.domain1.systemhost.net> > Agree for as long as there are addresses enough to meet the applicants > needs. Yet it is IMHO pointless to hand out micro-blocks as a sorry > response to a PA-request for a substantially larger block. In particular, what if the applicant's competitor just received a much larger allocation two weeks earlier? That's why I think that any policy change related to the last IPv4 allocations should focus on some way to make sure that all LIRs run out of IPv4 at roughly the same time. Maybe the policy change needs to take effect before we reach the last /8 from IANA. Maybe we need some kind of cap on maximum allocation that shrinks month by month. Maybe we should link the allocation size to the number of weeks it would take to use it up given the applicant's historical run-rate, and then shrink that number of weeks every month. > This isn't > about forcing anyone in any particular direction, but about whether it > is of greater benefit to the community at large to allocate > such blocks > to organizations with a potential to enable connectivity between large > numbers of new users and the existing v4 network. Has anyone clearly explained how any organization would enable such connectivity in a way that existing LIRs could not? It sounds like people are assuming that there may be some magic bullet while in reality there are just network providers providing services. The technical details of those services change over time for all LIRs. Innovation is not restricted to new entrants. --Michael Dillon From niels=apwg at bakker.net Thu Sep 17 19:38:06 2009 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Thu, 17 Sep 2009 19:38:06 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <28E139F46D45AF49A31950F88C4974580324E546@E03MVZ2-UKDY.domain1.systemhost.net> References: <1253191769.4949.15.camel@obelix> <28E139F46D45AF49A31950F88C4974580324E546@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090917173806.GE31607@burnout.tpb.net> >> Agree for as long as there are addresses enough to meet the applicants >> needs. Yet it is IMHO pointless to hand out micro-blocks as a sorry >> response to a PA-request for a substantially larger block. * michael.dillon at bt.com (michael.dillon at bt.com) [Thu 17 Sep 2009, 17:13 CEST]: >In particular, what if the applicant's competitor just received a much >larger allocation two weeks earlier? Same thing that happens when the person in front of you in the line at the cafetaria at work takes that last cupcake: you're outta luck. This is also why nobody has proposed to go back and yank valid assignments, no matter if they are two weeks or two decades old. -- Niels. From Remco.vanMook at eu.equinix.com Thu Sep 17 19:49:00 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 17 Sep 2009 19:49:00 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 Message-ID: <25B76451F7215744AFD4195362E55A1C04A175@NLEN1EX1.eu.win.equinix.com> Not everybody is going to run out at the same time because there are likely already LIRs whose assignment rate is so low they'll still have space from their current allocation in 2015 or so - intentional or not. Remco ----- Original Message ----- From: address-policy-wg-admin at ripe.net To: address-policy-wg at ripe.net Sent: Thu Sep 17 16:11:53 2009 Subject: RE: [address-policy-wg] The final /8 policy proposals, part 3.2 > Agree for as long as there are addresses enough to meet the applicants > needs. Yet it is IMHO pointless to hand out micro-blocks as a sorry > response to a PA-request for a substantially larger block. In particular, what if the applicant's competitor just received a much larger allocation two weeks earlier? That's why I think that any policy change related to the last IPv4 allocations should focus on some way to make sure that all LIRs run out of IPv4 at roughly the same time. Maybe the policy change needs to take effect before we reach the last /8 from IANA. Maybe we need some kind of cap on maximum allocation that shrinks month by month. Maybe we should link the allocation size to the number of weeks it would take to use it up given the applicant's historical run-rate, and then shrink that number of weeks every month. > This isn't > about forcing anyone in any particular direction, but about whether it > is of greater benefit to the community at large to allocate > such blocks > to organizations with a potential to enable connectivity between large > numbers of new users and the existing v4 network. Has anyone clearly explained how any organization would enable such connectivity in a way that existing LIRs could not? It sounds like people are assuming that there may be some magic bullet while in reality there are just network providers providing services. The technical details of those services change over time for all LIRs. Innovation is not restricted to new entrants. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Sep 17 21:07:59 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 17 Sep 2009 20:07:59 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <20090917173806.GE31607@burnout.tpb.net> Message-ID: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> > >> Agree for as long as there are addresses enough to meet the > >> applicants needs. Yet it is IMHO pointless to hand out > micro-blocks > >> as a sorry response to a PA-request for a substantially > larger block. > > * michael.dillon at bt.com (michael.dillon at bt.com) [Thu 17 Sep > 2009, 17:13 CEST]: > >In particular, what if the applicant's competitor just > received a much > >larger allocation two weeks earlier? > > Same thing that happens when the person in front of you in > the line at the cafetaria at work takes that last cupcake: > you're outta luck. Wrong! If RIPE has changed their policies so that they apply different criteria to you and your competitor, you are not out of luck. You now have grounds for a nice lawsuit against both RIPE and your competitor. The point is that if RIPE changes the policy, it has to do so in a way that does not convert the bad luck of running out of IPv4, into selective discrimination. --Michael Dillon From sander at steffann.nl Thu Sep 17 22:03:13 2009 From: sander at steffann.nl (Sander Steffann) Date: Thu, 17 Sep 2009 22:03:13 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Hello Michael, > The point is that if RIPE changes the policy, it has to do so in > a way that does not convert the bad luck of running out of IPv4, > into selective discrimination. Which is why I proposed to reserve address space for initial allocations. Existing LIRs already have their initial allocation, new LIRs can get a (much smaller) initial allocation. And because by that time there will be no IPv4 addresses for subsequent allocations everybody will have to deal with the shortage. New LIRs will never get as much addresses as existing LIRs, but I think this is as fair as we can make it: at least give new LIRs an opportunity to participate in the IPv4 internet. What I find discriminating is for existing LIRs to use up all IPv4 addresses, which forces new LIRs to but IPv4 address space or services from them. Reserving address space for those initial allocations won't make a real difference for existing LIRs (RIPE NCC allocates about 3 / 8's a year, so if we set aside (for example) a /12 for initial allocations that would mean we run out one week earlier). It will however give new LIRs the possibility to participate in the IPv4 internet, show to regulators that we are not anti-competitive, etc. Just to be clear: I don't want to make it 'easy' for new LIRs to get address space. Everybody will suffer equally when we run out of IPv4. Giving a /24 as initial allocation is still 8 times as small as the current minimum allocation size so it won't be easy for new LIRs. They will never get a /21 minimum allocation as we are used to currently, but at least they have some address space to work with. That way it will just be hard for them, instead of impossible. - Sander From mohta at necom830.hpcl.titech.ac.jp Fri Sep 18 06:30:18 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 18 Sep 2009 13:30:18 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4AB30CDA.7010204@necom830.hpcl.titech.ac.jp> michael.dillon at bt.com wrote: > The point is that if RIPE changes the policy, it has to do so in > a way that does not convert the bad luck of running out of IPv4, > into selective discrimination. Or, better, in a way that does not cause the bad luck for foreseeable future, which is possible by reducing amount of address allocation assuming extensive use of NAT and start working on using Classes E and part of D for unicast. Note that NAT can be end to end tranparent. Masataka Ohta From drc at virtualized.org Fri Sep 18 07:04:46 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 17 Sep 2009 22:04:46 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> Michael, On Sep 17, 2009, at 12:07 PM, wrote: >> Same thing that happens when the person in front of you in >> the line at the cafetaria at work takes that last cupcake: >> you're outta luck. > Wrong! Err, no. > If RIPE has changed their policies so that they apply different > criteria to you and your competitor, you are not out of luck. You > now have grounds for a nice lawsuit against both RIPE and your > competitor. By this logic, RIR policies can never change or the RIR will get sued. Obviously silly. > The point is that if RIPE changes the policy, it has to do so in > a way that does not convert the bad luck of running out of IPv4, > into selective discrimination. It isn't "bad luck", it is a function of having a limited resource. Bakeries do not get sued when they run out of cupcakes. I suspect all RIPE needs to do is ensure polices are non-discriminatory going forward (but then again, I'm not a net.lawyer. Regards, -drc From jim at rfc1035.com Fri Sep 18 10:08:51 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 18 Sep 2009 09:08:51 +0100 Subject: [address-policy-wg] what's "non-discriminatory"? In-Reply-To: <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> Message-ID: <49ABFA20-D493-4D5A-A86A-D0360F424B6F@rfc1035.com> > It isn't "bad luck", it is a function of having a limited resource. > Bakeries do not get sued when they run out of cupcakes. FWIW I am not a lawyer either. However I do know that anybody can sue anyone over anything. Whether their case has validity or even reaches court is another matter. So the cupcake customer could sue the bakery. And the bakery could counter-sue the customer to make them buy cupcakes before they run out. > I suspect all RIPE needs to do is ensure polices are non- > discriminatory Indeed. But define "non-discriminatory". Current address policies discriminate against those who can't afford NCC membership. Or don't speak English. I think it might be advisable to get legal advice on the impact of proposed address policy changes: eg They provide an impact assessment or something like that as part of the PDP. From mohacsi at niif.hu Fri Sep 18 10:21:24 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 18 Sep 2009 10:21:24 +0200 (CEST) Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <4AB30CDA.7010204@necom830.hpcl.titech.ac.jp> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <4AB30CDA.7010204@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, 18 Sep 2009, Masataka Ohta wrote: > michael.dillon at bt.com wrote: > >> The point is that if RIPE changes the policy, it has to do so in >> a way that does not convert the bad luck of running out of IPv4, >> into selective discrimination. > > Or, better, in a way that does not cause the bad luck for foreseeable > future, which is possible by reducing amount of address allocation > assuming extensive use of NAT and start working on using Classes E > and part of D for unicast. This hardly work: you have to change protocol stack of billions of device. > > Note that NAT can be end to end tranparent. Can you explain how? Best Regards, Janos Mohacsi From sander at steffann.nl Fri Sep 18 10:33:58 2009 From: sander at steffann.nl (Sander Steffann) Date: Fri, 18 Sep 2009 10:33:58 +0200 (CEST) Subject: [address-policy-wg] what's "non-discriminatory"? In-Reply-To: <49ABFA20-D493-4D5A-A86A-D0360F424B6F@rfc1035.com> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> <49ABFA20-D493-4D5A-A86A-D0360F424B6F@rfc1035.com> Message-ID: <2298.80.101.103.96.1253262838.squirrel@webmail.sintact.nl> Hi Jim, > I think it might be advisable to get legal advice on the impact of > proposed address policy changes: eg They provide an impact assessment > or something like that as part of the PDP. An Impact Analysis is already done for every policy proposal that reaches the Review phase of the PDP (http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2007/msg00432.html). I'll make sure that this includes a legal analysis. Sander From jorgen.eriksson at iis.se Fri Sep 18 10:27:06 2009 From: jorgen.eriksson at iis.se (=?utf-8?B?SsO2cmdlbiBFcmlrc3Nvbg==?=) Date: Fri, 18 Sep 2009 10:27:06 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> Message-ID: <983F17705339E24699AA251B458249B50CC4773532@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 18 2009 07:07, David Conrad wrote: > Bakeries do not get sued when they run out of cupcakes. > Your average cupcake buyer does not base a zillion-dollar business based on the cupcake availability... /Jorgen -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wj8DBQFKs0Ra2Jfo35gNO/0RApKrAJ9SafWr+0fAJq7/K2Z97ZUtwOdOXACg9Tcc tyjFgKeCKCPfU5PW0g1gAlQ= =30cE -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas at Schachtner.eu Fri Sep 18 10:51:04 2009 From: Andreas at Schachtner.eu (Andreas Schachtner) Date: Fri, 18 Sep 2009 10:51:04 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <4AB30CDA.7010204@necom830.hpcl.titech.ac.jp> Message-ID: <20090918085104.B8D78DAF3E@linux.local> ... > > Note that NAT can be end to end tranparent. > > Can you explain how? It has been explained in length. It should be in the archive of this ML: http://www.ripe.net/ripe/maillists/archives/ Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Fri Sep 18 19:46:39 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 19 Sep 2009 02:46:39 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 3.2 In-Reply-To: References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <4AB30CDA.7010204@necom830.hpcl.titech.ac.jp> Message-ID: <4AB3C77F.7090809@necom830.hpcl.titech.ac.jp> Mohacsi Janos wrote: >> Or, better, in a way that does not cause the bad luck for foreseeable >> future, which is possible by reducing amount of address allocation >> assuming extensive use of NAT and start working on using Classes E >> and part of D for unicast. > This hardly work: you have to change protocol stack of billions of device. For network devices and class E, it is no difficult than subnetting. Class D may needs some more time. For end hosts, hosts within leagacy NAT does not need any change. >> Note that NAT can be end to end tranparent. > Can you explain how? How, do you think, legacy NAT is NOT end to end? The below is explanation on it in draft-ohta-e2e-nat-00.txt. According to the end to end argument [SALTZER]: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) NAT can completely and correctly be implemented only with the knowledge and help of the end hosts behind a NAT gateway. That is, by let end hosts cooperate with NAT gateways, NAT can be and actually is end to end, which requires modification on end hosts. Note that an unmodified end host can operate just as an end host behind regacy NAT and that, with the modification, end hosts may also be modified to treat class E and part of class D for unicast. Masataka Ohta From gert at space.net Sun Sep 20 22:14:35 2009 From: gert at space.net (Gert Doering) Date: Sun, 20 Sep 2009 22:14:35 +0200 Subject: [address-policy-wg] agenda for upcoming APWG meeting Message-ID: <20090920201435.GW79272@Space.Net> Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in two weeks in Lissabon. This time, we the following three time slots: Wednesday, Oct 7, 09:00 - 10:30 Wednesday, Oct 7, 11:00 - 12:30 Thursday, Oct 8, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. The agenda is fairly lightly loaded so far, especially for the Thursday time slot, all we have is "if you have something in mind that needs discussion, this is the place to go". So we certainly welcome your input. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-05 [multiple IPv6 /32 allocations] - withdrawn 2008-05 [Anycast for ENUM] - accepted 2009-02 [Resources to the RIPE NCC] - accepted - overview over proposals currently in Last Call 2009-06 [Routing Requirements] 2009-07 [global ASN block policy] 2009-08 [IPv6 PI for LIRs] - common policy topics in all regions (end of IPv4, transfers, ...) C. Rough Edges of the current policies Report from the RIPE NCC Registration Services department on issues and unintended side-effects showing up in the daily implementation of the RIPE policies. (+ brief discussion) D. "Routing Issues" update At RIPE 58, we decided to work together with the routing WG to remove "routing policy" from the address policy documents, and have the routing WG come up with an updated routing recommendation document. This is to briefly summarize what this is all about and point to the document. Discussion should take place in the routing WG. E. Document Cosmetic Surgeries Project - Filiz Yilmaz (separate item from "B.", because it's really a separate activity - and this gives us a bit scheduling flexibility) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- E. New Proposals since RIPE 58 overview about what's coming [5-10 min] F. Discussion of open policy proposals ---- various stuff, not directly related to IPv4 run-out --- 2006-05 PI Assignment Size [?? min] 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team) ---- directly related to IPv4 run-out --- 2008-06 Use of Final /8 (Philip Smith) 2009-03 Run Out Fairly (Daniel Karrenberg) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (Alain Bidron) ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- X. Ideas how to tackle any problems that have been experienced by the NCC Registration Services Department. (open discussion, based on the report and comments on Wednesday) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From flor at ripe.net Mon Sep 21 14:11:44 2009 From: flor at ripe.net (Flor Paredes) Date: Mon, 21 Sep 2009 14:11:44 +0200 Subject: [address-policy-wg] New IPv4 blocks allocated to RIPE NCC Message-ID: <4AB76D80.40305@ripe.net> Dear Colleagues, The RIPE NCC received the IPv4 address ranges 2/8 and 46/8 from the IANA in September 2009. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that several "pilot" prefixes are being announced from each /8. These prefixes are: 2.0.0.0/16, pingable 2.0.0.1 2.1.0.0/21, pingable 2.1.0.1 2.1.24.0/24, pingable 2.1.24.1 46.0.0.0/16, pingable 46.0.0.1 46.1.0.0/21, pingable 46.1.0.1 46.1.24.0/24, pingable 46.1.24.1 They all originate in AS12654. More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Regards, Flor Paredes Registration Services Manager RIPE NCC From andy at nosignal.org Mon Sep 21 18:35:24 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 21 Sep 2009 17:35:24 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3 In-Reply-To: <275EA11D-0689-471B-9876-5EEBFADA6246@steffann.nl> References: <275EA11D-0689-471B-9876-5EEBFADA6246@steffann.nl> Message-ID: On 24 Aug 2009, at 21:04, Sander Steffann wrote: > Most people preferred option b: All requests are downscaled by a > certain factor > Some people preferred option a: Everyone gets one (and only one) > fixed size block > Because most people preferred option b, let's discuss some of the > details to see if we can make that work. If we are going to > downscale address space requests, how should we do that? Some issues: Slightly rephrasing Sander's questions .. - Do we want a maximum allocation size ? Maybe, although certainly not to the levels discussed in recent threads, e.g. /26. I still think that PA should be highly aggregatable for it to be fit for purpose. If we have typical PA allocations of /26, which by and large will be unroutable, we make the last /8 broadly useless. If we do that, we effectively make the v4 dry period start one /8 earlier. Does this matter ? Well, if our work makes the last /8 useless, it moves the sky a thousand feet closer to the earth. If we don't do this work, then the sky is STILL FALLING. - Do I think the minimum allocation size should fall ? Maybe, but if everyone decides to be a 'good citizen' and ask for a / 22 rather than /21, how much extra time would we buy ? 3 or 4 months ? Perhaps a smaller minimum allocation size for the last /8 pushes the sky back a few hundred feet, but it sure looks like it's getting closer.. - Do I think companies should be limited to one PA allocation from the last /8 ? Probably not, because we will make a lot of business for lawyers trying to define what 'one company' is. If a company has an arm in Switzerland, one in the UK, one in France, then does spending money on three LIR memberships earn 3x PA ? What about if an e-commerce organisation, an ISP, and a hosting company have the same ultimate parent company, must only one of those organisations receive addresses ? Can I bypass this by requesting PI ? If so, all of my end users will just have to obtain PI through my LIR and we have the same amount of addresses in use, but an extra route in the routing table to carry - the net result is a worse situation, but the same addresses in use. Does that sky look any closer to you.. ? - Should we make an exception for people who say downscaling is not possible, e.g. https server farm. Hmm, whats this blue thing surrounding and crushing me, argh ! - What are our motives ? Are we building a policy that is designed to placate the regulators and governments at the time of the last /8 ? Because, if so, have we not done enough v6 promotion ? If our motivation is the extend the life of v4, then this is playing into the hands of Big NAT vendors. We can do much harm whilst trying to do good in the construction of intervention policies. The only fix is to deploy v6, so policies which are designed to extend the life of v4 will muddy the pro-v6 message that we want to send to operators. Andy Davidson From andy at nosignal.org Mon Sep 21 18:42:50 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 21 Sep 2009 17:42:50 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3 In-Reply-To: References: <275EA11D-0689-471B-9876-5EEBFADA6246@steffann.nl> Message-ID: On 21 Sep 2009, at 17:35, Andy Davidson wrote: > Slightly rephrasing Sander's questions .. Sorry, I missed another question which I would like to add. If we design a policy which is somehow more 'fair' than the policies which we assign with today, what is the rationale for leaving it until the last /8 before putting it into action ? Thanks Andy From michael.dillon at bt.com Tue Sep 22 09:57:35 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 22 Sep 2009 08:57:35 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 3 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745803338E53@E03MVZ2-UKDY.domain1.systemhost.net> > - Do we want a maximum allocation size ? Yes, based on the applicant's run-rate. In other words the maximum is not an arbitrary fixed amount of IP space, but an arbitrary fixed time period that is used, with the run-rate, to calculate the allocation size. The end result is that everybody's last allocation runs out at roughly the same time. > If we have > typical PA allocations of /26, which by and large will be > unroutable, we make the last /8 broadly useless. If we do > that, we effectively make the v4 dry period start one /8 earlier. Any policy change is going to make the v4 scarcity period start earlier so the best we can do is to make the shape of that scarcity period less harsh. This is why I keep talking about an attempt to make everyone's free space run out at roughly the same time. I believe that this will mimimize the negative impact even though it would result in a certain amount of routing table consumption for very long prefixes. > Does this matter ? Well, if our work makes the last /8 > useless, it moves the sky a thousand feet closer to the > earth. If we don't do this work, then the sky is STILL FALLING. The sky is falling regardless of our actions. And if RIPE hands out /26 blocks that end up being unroutable, the unroutability is the ISP's fault, not RIPE's. In other words, if LIRs vote for a policy change that results in /26 allocations, one would expect that those LIRs would follow through by changing their routing filters. > - Do I think the minimum allocation size should fall ? > > Maybe, but if everyone decides to be a 'good citizen' and ask for a / > 22 rather than /21, how much extra time would we buy ? 3 or > 4 months ? > > Perhaps a smaller minimum allocation size for the last /8 > pushes the sky back a few hundred feet, but it sure looks > like it's getting closer.. If there is a good reason to simply reduce allocation sizes then there is no good reason why we should wait until the final /8 to make that reduction. > - Do I think companies should be limited to one PA allocation > from the last /8 ? > > Probably not, because we will make a lot of business for > lawyers trying to define what 'one company' is. If a company > has an arm in Switzerland, one in the UK, one in France, then > does spending money on three LIR memberships earn 3x PA ? All modern multinational companies, and many larger domestic companies are actually formed as a collection of many corporations. Sometimes this is simply a result of the way mergers and acquisitions are done, and sometimes it is done for tax reasons. These component corporate entities do not necessarily use the mother company's brand name in their corporate name, so RIPE may not even know that two LIRs are related. I think that we will do better by focusing on the demand, and make rules for applicants who ask for address space. Separately, RIPE might want to work on the issues of merging LIRs. > We can do much harm whilst trying to do good in the construction of > intervention policies. The only fix is to deploy v6, so policies > which are designed to extend the life of v4 will muddy the > pro-v6 message that we want to send to operators. It is still reasonable to change the IPv4 policy so that everybody suffers equally as we use up the last drops of IPv4. --Michael Dillon From nigel at titley.com Tue Sep 22 12:14:58 2009 From: nigel at titley.com (Nigel Titley) Date: Tue, 22 Sep 2009 11:14:58 +0100 Subject: [address-policy-wg] what's "non-discriminatory"? In-Reply-To: <2298.80.101.103.96.1253262838.squirrel@webmail.sintact.nl> References: <28E139F46D45AF49A31950F88C497458032A697C@E03MVZ2-UKDY.domain1.systemhost.net> <9A606DA9-1DBA-461D-A8D6-C1633C16C180@virtualized.org> <49ABFA20-D493-4D5A-A86A-D0360F424B6F@rfc1035.com> <2298.80.101.103.96.1253262838.squirrel@webmail.sintact.nl> Message-ID: <4AB8A3A2.1060203@titley.com> Sander Steffann wrote: > Hi Jim, > > >> I think it might be advisable to get legal advice on the impact of >> proposed address policy changes: eg They provide an impact assessment >> or something like that as part of the PDP. >> > > An Impact Analysis is already done for every policy proposal that reaches > the Review phase of the PDP > (http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2007/msg00432.html). > > I'll make sure that this includes a legal analysis. > I raised this issue at the last RIPE NCC board meeting. We are taking advice on the legal ramifications of the various last /8 policy proposals. Nigel From filiz at ripe.net Tue Sep 22 15:33:22 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 22 Sep 2009 15:33:22 +0200 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) Message-ID: <20090922133322.ABE602F583@herring.ripe.net> PDP Number: 2009-03 Run Out Fairly Dear Colleagues, The draft document for the proposal described in 2009-03 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-471-draft2009-03.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 20 October 2009. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC From michael.dillon at bt.com Tue Sep 22 15:51:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 22 Sep 2009 14:51:07 +0100 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) In-Reply-To: <20090922133322.ABE602F583@herring.ripe.net> Message-ID: <28E139F46D45AF49A31950F88C49745803393DD5@E03MVZ2-UKDY.domain1.systemhost.net> The impact analysis states: Reducing the default allocation and assignment period (in three steps) to three months also means that, in the RIPE NCC service region, the industry as a whole will run out of unassigned IP addresses shortly after the RIPE NCC registry runs out. In principle, no LIR will have an excess amount of free addresses left from previous allocations to grow their business for more than three months. I think that is a good thing since it preserves the level playing field nature of RIPE allocation policy. This is far better than having a sudden drastic policy change take effect when the last /8 is allocated. In addition, the 2010 start date gives LIRs enough planning time to get management approval for activities to mitigate the problem, such as deploying IPv6 and forcing low-margin customers off of IPv4 to free the remaining IPv4 addresses for high-margin customers. --Michael Dillon From michiel at klaver.it Tue Sep 22 16:31:36 2009 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 22 Sep 2009 16:31:36 +0200 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) In-Reply-To: <20090922133322.ABE602F583@herring.ripe.net> References: <20090922133322.ABE602F583@herring.ripe.net> Message-ID: <4AB8DFC8.40600@klaver.it> Filiz Yilmaz wrote: > PDP Number: 2009-03 > Run Out Fairly > > Dear Colleagues, > > The draft document for the proposal described in 2009-03 has been > published. The impact analysis that was conducted for this proposal > has also been published. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-03.html > > and the draft document at: > > http://www.ripe.net/ripe/draft-documents/ripe-471-draft2009-03.html > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 20 October 2009. > > Regards, > > Filiz Yilmaz > > Policy Development Manager > RIPE NCC > The new proposed policy text at the draft document under section "6.0 Policies and Guidelines for Assignments" states some fixed dates for reducing the assignment period. Those are based at the predictions made by Geoff Huston using the data of current assignment rates. What if people realize IPv4 addresses become scarce and there will be a massive run on the last available pool, then the final date of exhaustion will be a lot sooner than projected. I think 2009-03 is a decent proposal, but should be based on on the pool of available address space trough time and not using fixed dates. For example: - When the available pool of allocatable IPv4 address space is at or below an /6, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to nine months. - When the available pool of allocatable IPv4 address space is at or below an /7, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to six months. - When the available pool of allocatable IPv4 address space is at or below an /8, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to three months. With kind regards, Michiel Klaver IT Professional From mark at streamservice.nl Tue Sep 22 18:35:30 2009 From: mark at streamservice.nl (Mark Scholten) Date: Tue, 22 Sep 2009 18:35:30 +0200 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) In-Reply-To: <4AB8DFC8.40600@klaver.it> References: <20090922133322.ABE602F583@herring.ripe.net> <4AB8DFC8.40600@klaver.it> Message-ID: <01ab01ca3ba2$b3277a10$19766e30$@nl> I support this proposal with fixed dates as currently written on the given link (version 1.0/submission date 7 April 2009). -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michiel Klaver Sent: dinsdag 22 september 2009 16:32 To: address-policy-wg at ripe.net; filiz at ripe.net Subject: Re: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) Filiz Yilmaz wrote: > PDP Number: 2009-03 > Run Out Fairly > > Dear Colleagues, > > The draft document for the proposal described in 2009-03 has been > published. The impact analysis that was conducted for this proposal > has also been published. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-03.html > > and the draft document at: > > http://www.ripe.net/ripe/draft-documents/ripe-471-draft2009-03.html > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 20 October 2009. > > Regards, > > Filiz Yilmaz > > Policy Development Manager > RIPE NCC > The new proposed policy text at the draft document under section "6.0 Policies and Guidelines for Assignments" states some fixed dates for reducing the assignment period. Those are based at the predictions made by Geoff Huston using the data of current assignment rates. What if people realize IPv4 addresses become scarce and there will be a massive run on the last available pool, then the final date of exhaustion will be a lot sooner than projected. I think 2009-03 is a decent proposal, but should be based on on the pool of available address space trough time and not using fixed dates. For example: - When the available pool of allocatable IPv4 address space is at or below an /6, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to nine months. - When the available pool of allocatable IPv4 address space is at or below an /7, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to six months. - When the available pool of allocatable IPv4 address space is at or below an /8, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to three months. With kind regards, Michiel Klaver IT Professional From rv at NIC.DTAG.DE Tue Sep 22 22:38:44 2009 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Tue, 22 Sep 2009 22:38:44 +0200 Subject: [address-policy-wg] late comments on 2009-06 Message-ID: <14507.1253651924@x37.NIC.DTAG.DE> Dear colleagues, the last call for 2009-06 is very close to expiring... I'm sorry I'm coming this late with a few comments. I certainly support the the motion to remove from the contraints for routing announcements from the address allocation policy; I voiced my support already at the last RIPE meeting with strong words. I hope that Rob Evans' initiative to draft a document on recommended annoucement practices in IPv6 in routing WG will result in document providing guidance on usage of aggregates, more specifics etc. without unduely stressing the global routing system. Admittedly this will be much harder than the removal of a few words from existing policy text (as 2009-06 does). Recently a potential downside of the removal of routing constraints from allocation policy came to my attention: NCC resource analysts might begin to encourage or even force LIRs to plan to deaggragate announcements when discussing requests for address space. For the record: I'd strongly request that NCC should refrain from doing so until documents giving guidance on appropriate use of deaggregation, or announcements of more specifics have been written and agreed upon. Applying such restraint seems not to require explicit text in the allocation policy - though I can see that NCC using or not using such restraint can in some cases lead to different results in evaluating requests for address space; i.e. some times allocating an additional separate address block when using a more specific out of another allocation might be another way for solving a particular routing requirement. Before closing let me make another nit: I feel quite uncomfortable to see the the second paragraph the impact analysis for fragmentaion/aggregation: it would be better to ONLY have the "we cannot seriously estimate" of the first paragraph than juggle meaningless short sighted numbers. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE Phone: +49 251 7985 200 fax: +49 251 7985 109 From rhe at nosc.ja.net Thu Sep 24 15:03:52 2009 From: rhe at nosc.ja.net (Rob Evans) Date: Thu, 24 Sep 2009 14:03:52 +0100 Subject: [address-policy-wg] late comments on 2009-06 In-Reply-To: <14507.1253651924@x37.NIC.DTAG.DE> References: <14507.1253651924@x37.NIC.DTAG.DE> Message-ID: <4ABB6E38.2050601@nosc.ja.net> Hi Ruediger, > I certainly support the the motion to remove from the contraints for > routing announcements from the address allocation policy; I voiced > my support already at the last RIPE meeting with strong words. Thanks. > Recently a potential downside of the removal of routing constraints from > allocation policy came to my attention: NCC resource analysts might begin > to encourage or even force LIRs to plan to deaggragate announcements > when discussing requests for address space. I thought the situation at the moment was that the only justification for additional IPv6 addresss space was utilisation (section 5.2 of the policy). Routing considerations are not taken into account, so what we were doing was allowing more people to use IPv6. Are you suggesting the potential deaggregators can already get multiple prefixes per LIR? If that is the case, then perhaps we do not need to relax the aggregation requirement. The proposal does not remove section 3.4 of the policy (goal of aggregation), but attempts to balance that and 3.5 (goal of conservation). Regards, Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From gert at space.net Thu Sep 24 16:37:54 2009 From: gert at space.net (Gert Doering) Date: Thu, 24 Sep 2009 16:37:54 +0200 Subject: [address-policy-wg] late comments on 2009-06 In-Reply-To: <4ABB6E38.2050601@nosc.ja.net> References: <14507.1253651924@x37.NIC.DTAG.DE> <4ABB6E38.2050601@nosc.ja.net> Message-ID: <20090924143754.GK628@Space.Net> Hi Rob, Ruediger, On Thu, Sep 24, 2009 at 02:03:52PM +0100, Rob Evans wrote: > were doing was allowing more people to use IPv6. Are you suggesting the > potential deaggregators can already get multiple prefixes per LIR? They can't. This is why multiple people have brought up this issue in the APWG, originally asking for "special rules under which a second PA block could be assigned" - which found no consensus, so we changed the angle of attacking this. > If that is the case, then perhaps we do not need to relax the aggregation > requirement. We do - I think this was a misunderstanding between Ruediger and you. Ruediger is worried that the removal of the existing requirements might lead to misinterpretation on the side of the NCC IPRAs, who could then (theoretically) actually *suggest* large-scale deaggregation to new IPv6 applicants. Which would, of course, be harmful, and not the aim of this policy change. So we definitely need to go forward with the routing WG document on IPv6 announcement best practices :-) - which could then be used by the IPRAs as "operator community" reference. Confusion cleared up? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From andy at nosignal.org Thu Sep 24 17:18:49 2009 From: andy at nosignal.org (Andy Davidson) Date: Thu, 24 Sep 2009 16:18:49 +0100 Subject: [address-policy-wg] 2009-08 Last Call for Comments (IPv6 Provider Independent (PI) Assignments for LIRs) In-Reply-To: References: Message-ID: Hi, Sorry for the very late answer. On 20 Aug 2009, at 15:43, IP-Office KPN wrote: > I support the general idea of the proposal, but I have some questions: Thank you. > The proposal states that (last paragraph): > "If an organisation already received a PI assignment before becoming > an > LIR, the PI assignment should be returned upon receiving an IPv6 > allocation if there are no specific routing requirements to justify > both." > > First question: > Only in this last paragraph of the proposal there is mention of "PI > assignment" as opposed to "IPv6 assignment". Was this done > intentionally? No. The text appears in the IPv6 PI assignment section of the document so only applies to assignments of this type. It does bring about functional parity with v4, but v4 policy is not changed by this policy proposal. > Second question: > Is it (therefore) not possible to become a LIR and just keep the PI > assignment instead of asking for a IPv6 PA allocation? Yes, why not - if you do not make assignments to end users, and only need a /48, but you want to support the work of the ncc, then ... > Third question: > Also, (just to be sure) as this Policy document exclusively deals with > IPv6, does this policy proposal also have impact on the IPv4 PI > space an > organisation already has when it wants to become an LIR? No change to v4 policy. Best wishes Andy From gert at Space.Net Thu Sep 24 20:41:40 2009 From: gert at Space.Net (Gert Doering) Date: Thu, 24 Sep 2009 20:41:40 +0200 Subject: [address-policy-wg] Decision regarding 2009-08 Message-ID: <20090924184140.GU628@Space.Net> Dear address policy WG, one of our policy proposals (2009-08, IPv6 PI assignments for LIRs) has reached the end of the "last call" phase, and is now being discussed among the chairs of all working groups to decide whether the RIPE policy process has been properly followed, and whether consensus has been reached. The APWG chairs have decided that consensus has been reached, but the amount of participation from the WG was small enough that this was a difficult decision. - at the RIPE meeting, there was support for moving in this direction - in the discussion and review phases, there were 3 e-mails stating explicit support. One e-mail stated non-support, but that was referring to another mail with questions about the proposal, so it was a bit unclear on what exactly the "non-support" referred to. - during last call phase, there was exactly 1 (one) e-mail on the list, and that e-mail was a question regarding the proposal. We, as the WG chairs, think that the change proposed is useful to have a more workable policy for "real world" networks. Thus we have decided to move forward, even if the amount of participation was a bit low. In general, we really need to see a few more voices in the various phases - otherwise it's really hard to claim consensus. (Which means that we, as the WG chairs, will have to be a bit more proactive in getting responses out of YOU...). regards, Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From slz at baycix.de Thu Sep 24 20:56:51 2009 From: slz at baycix.de (Sascha Lenz) Date: Thu, 24 Sep 2009 20:56:51 +0200 Subject: [address-policy-wg] Decision regarding 2009-08 In-Reply-To: <20090924184140.GU628@Space.Net> References: <20090924184140.GU628@Space.Net> Message-ID: <4ABBC0F3.2000306@baycix.de> Hi Gert & all, Gert Doering schrieb: > Dear address policy WG, > > one of our policy proposals (2009-08, IPv6 PI assignments for LIRs) has > reached the end of the "last call" phase, and is now being discussed > among the chairs of all working groups to decide whether the RIPE policy > process has been properly followed, and whether consensus has been > reached. [...] > We, as the WG chairs, think that the change proposed is useful to have > a more workable policy for "real world" networks. Thus we have decided > to move forward, even if the amount of participation was a bit low. If i didn't say that already: I do support the proposal :-) > > In general, we really need to see a few more voices in the various > phases - otherwise it's really hard to claim consensus. (Which means > that we, as the WG chairs, will have to be a bit more proactive in > getting responses out of YOU...). My personal problem here is, that i actually do not always recall IF and WHAT i did comment on WHICH proposal and what phase of the PDP that was again. Call it bad Mail(linglist)-Archiv handling or getting old and forgetting things. Can't we have a nifty little Web 2.1 Tool on a RIPE webpage to track pros and cons and on a proposal with checkboxes to support it or not? :-) ... oh my god, am i turning into a manager? brrrr (Sounds funny, but that's the TRUE reason i probably miss raising my voice to several proposals.. i don't always have time to immediately reply and then i forget it, or i don't want to interrupt an ongoing rant about a proposal and wait until things cool off and then forget to answer and so on... is it only me? probably so *sigh* ) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From andy at nosignal.org Fri Sep 25 00:18:45 2009 From: andy at nosignal.org (Andy Davidson) Date: Thu, 24 Sep 2009 23:18:45 +0100 Subject: [address-policy-wg] Decision regarding 2009-08 In-Reply-To: <4ABBC0F3.2000306@baycix.de> References: <20090924184140.GU628@Space.Net> <4ABBC0F3.2000306@baycix.de> Message-ID: <93273B39-EA92-4D9C-86A1-DF045C53D1CA@nosignal.org> Hi there, On 24 Sep 2009, at 19:56, Sascha Lenz wrote: > If i didn't say that already: I do support the proposal :-) Thank you. > Can't we have a nifty little Web 2.1 Tool on a RIPE webpage to track > pros and cons and on a proposal with checkboxes to support it or > not? :-) ... I like the idea of tools that encourage increased participation, but this tool feels a bit like a 'vote' rather than a consensus driven democracy. Andy From nick at inex.ie Fri Sep 25 12:26:00 2009 From: nick at inex.ie (Nick Hilliard) Date: Fri, 25 Sep 2009 11:26:00 +0100 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) In-Reply-To: <4AB8DFC8.40600@klaver.it> References: <20090922133322.ABE602F583@herring.ripe.net> <4AB8DFC8.40600@klaver.it> Message-ID: <4ABC9AB8.5090100@inex.ie> On 22/09/2009 15:31, Michiel Klaver wrote: > What if people realize IPv4 addresses become scarce and there will be a > massive run on the last available pool, then the final date of > exhaustion will be a lot sooner than projected. > > I think 2009-03 is a decent proposal, but should be based on on the pool > of available address space trough time and not using fixed dates. For > example: There are several ways of trying to determine when to kick in the smaller assignment windows: - static dates (currently used in the proposal) - date based on amount of address space left - variants of date based on historical run-rate (i.e. move to 9 months when there is an estimated 9(+X) months of address space left, based on previous run-rate) Would it be possible for RIPE to provide some information on their current run-rate? Nick From david.freedman at uk.clara.net Fri Sep 25 12:47:26 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 25 Sep 2009 11:47:26 +0100 Subject: [address-policy-wg] ripe471 - language query Message-ID: <4ABC9FBE.1010608@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick query w.r.t the ripe471 document relating to a conversation I had with another registry today who were confused by the use of the language: Section 5.3 (Additional Allocations) states: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." Whereas Section 5.4 (Sub Allocations) states: "LIRs are still required to demonstrate about 80% usage for all their allocations." The question is therefore, do we mean: - - That all the address space currently allocated to the registry should be summed and if the registry consumes more than 80% of this they qualify for an additional allocation or - - That all allocations the registry has must each consume more than 80% before the registry qualifies for an additional allocation. and if so, could the language in the document be cleaned up to avoid such ambiguity? Dave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8n74ACgkQtFWeqpgEZrL9tgCfUbDNmABC8AfnJ4YU/Rd1waU0 Ga8Anjd3WAb1cuyQ/xvd0LH9Z9ZAFilo =q7Pd -----END PGP SIGNATURE----- From alexlh at ripe.net Fri Sep 25 14:42:16 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Fri, 25 Sep 2009 14:42:16 +0200 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) In-Reply-To: <4ABC9AB8.5090100@inex.ie> References: <20090922133322.ABE602F583@herring.ripe.net> <4AB8DFC8.40600@klaver.it> <4ABC9AB8.5090100@inex.ie> Message-ID: Dear Nick, > Would it be possible for RIPE to provide some information on their > current run-rate? Please find the amount of IPv4 address space allocated over the last twelve months below: month IPs IPs in slash notation 2008-10 3266560 /11,/12,/16,/17,/18,/20,/21 2008-11 3047424 /11,/13,/14,/15,/17 2008-12 3274752 /11,/12,/16,/17,/18,/19,/20,/21 2009-01 6502400 /10,/11,/15,/16,/19,/20,/21 2009-02 4182016 /11,/12,/13,/14,/15,/16,/17,/18,/20 2009-03 2643968 /11,/13,/18,/20,/21 2009-04 2478080 /11,/14,/16,/17,/18,/20 2009-05 3629056 /11,/12,/14,/15,/16,/18,/19 2009-06 4540416 /10,/14,/16,/18,/21 2009-07 2844672 /11,/13,/15,/16,/18,/19,/21 2009-08 7272448 /10,/11,/13,/14,/15,/17,/18,/19,/20,/21 2009-09 1277952 /12,/15,/16,/17 The twelve month average is 3746645 IPs or a bit over /11,/12,/13. Best regards, Alex Le Heux RIPE NCC From filiz at ripe.net Mon Sep 28 14:54:29 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 28 Sep 2009 14:54:29 +0200 Subject: [address-policy-wg] 2009-07 Proposal Accepted (Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries) Message-ID: <20090928125429.928442F583@herring.ripe.net> PDP Number: 2009-07 Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Dear Colleagues, Consensus has been reached, and the proposal described in 2009-07 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: ripe-480, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries" http://www.ripe.net/ripe/docs/ripe-480.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2009-07.html Please note that this is a global policy and will therefore come into effect only after it has been accepted as a policy in all other RIR regions and then ratified by ICANN. Thank you for your input. Regards Filiz Yilmaz Policy Development Manager RIPE NCC From nick at inex.ie Mon Sep 28 14:57:13 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 28 Sep 2009 13:57:13 +0100 Subject: [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly) In-Reply-To: References: <20090922133322.ABE602F583@herring.ripe.net> <4AB8DFC8.40600@klaver.it> <4ABC9AB8.5090100@inex.ie> Message-ID: <4AC0B2A9.1070607@inex.ie> On 25/09/2009 13:42, Alex Le Heux wrote: > 2008-10 3266560 /11,/12,/16,/17,/18,/20,/21 > 2008-11 3047424 /11,/13,/14,/15,/17 > 2008-12 3274752 /11,/12,/16,/17,/18,/19,/20,/21 > 2009-01 6502400 /10,/11,/15,/16,/19,/20,/21 > 2009-02 4182016 /11,/12,/13,/14,/15,/16,/17,/18,/20 > 2009-03 2643968 /11,/13,/18,/20,/21 > 2009-04 2478080 /11,/14,/16,/17,/18,/20 > 2009-05 3629056 /11,/12,/14,/15,/16,/18,/19 > 2009-06 4540416 /10,/14,/16,/18,/21 > 2009-07 2844672 /11,/13,/15,/16,/18,/19,/21 > 2009-08 7272448 /10,/11,/13,/14,/15,/17,/18,/19,/20,/21 > 2009-09 1277952 /12,/15,/16,/17 taking this and http://www.potaroo.net/tools/ipv4/ into account, the run rate is between 2.5 and 3 /8s per annum; alternatively, a /8 will be gobbled up in about 4 months under normal circumstances. Turning this around, the "what do we do with the last /8" discussions really revolve around what to do with 4 months worth of address space. So, if people are proposing radical changes to the assignment policy, does it really make sense to do so for a mere 4 months of run-time. Or probably a lot less, if address stock-piling and panic sets in? I can't help seeing this as a knee-jerk reaction to the unknown. The current date-based suggestion in 2009-03 currently works out as starting the "Run Out Fairly" proposal about a year before IANA depletion, and 2 years before RIR depletion (according to Geoff Huston's estimates), with the 3 month window kicking at around the IANA depletion date and about year before RIR depletion, or given RIPE NCC's burn rate and proposal 2008-03, between 4 and 13 months before RIPE depletion, depending on how things pan out. I.e. if the RIPE NCC were to receive 2 x /8 immediately before IANA exhaustion, then there would be about 4.2*3 = 13 months space available. At the other end of the scale, if the RIPE NCC were almost exhausted at the time that IANA gets to its last 5 /8s, then there would be only a little more than 4 months address space available. Limiting allocations / assignments to 3 months worth of address space would be fine if we knew that this policy were to last around 12 months. However, if it were only to operate on 4 months worth of space, that would be a bad thing, because it would introduce new guidelines at a time of market consternation / panic. I'd like to propose that last minute tweaks are objectively bad - and 4 months is very last-minute. Please excuse the thinking-out-loud thing going on here. It just seems that we need to model RIPE's run-out process carefully so that we have a good idea of when IANA will assign the RIPE NCC its last /8s, and what policies are in place to deal with them (whether 2009-03 or "last /8" type). Has any modelling of this form been done within the NCC? Using naive projection, I'd suggest that the RIPE NCC may be in line to get 2x/8 in 2010-05, 2011-01 and possibly 2011-09 before it receives the last /8. Going by this finger-in-the-air estimate and Geoff Huston's prognostications, the RIPE NCC will either be at the end of its previous 2x/8 or will just be starting off on a new 2x/8 when it receives the last /8 disbursement. This would suggest that there is a significant risk that 2009-03 will end up running its 3 month requirement window period at a time when the RIPE NCC only has enough space for 4 months worth of assignments. I find that alarming. Nick From gert at space.net Mon Sep 28 15:14:52 2009 From: gert at space.net (Gert Doering) Date: Mon, 28 Sep 2009 15:14:52 +0200 Subject: [address-policy-wg] agenda for upcoming APWG meeting (draft 2) In-Reply-To: <20090920201435.GW79272@Space.Net> References: <20090920201435.GW79272@Space.Net> Message-ID: <20090928131452.GM628@Space.Net> Hi APWG, RIPE meeting, below you can find an updated draft for the RIPE address policy WG meeting's agenda, which will take place in Lisbon in the following three time slots: Wednesday, Oct 7, 09:00 - 10:30 Wednesday, Oct 7, 11:00 - 12:30 Thursday, Oct 8, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz [25-30 min] - overview over concluded proposals 2009-05 [multiple IPv6 /32 allocations] - withdrawn 2008-05 [Anycast for ENUM] - accepted 2009-02 [Resources to the RIPE NCC] - accepted - overview over proposals currently in Last Call 2009-06 [Routing Requirements] 2009-07 [global ASN block policy] 2009-08 [IPv6 PI for LIRs] - common policy topics in all regions (end of IPv4, transfers, ...) C. Rough Edges of the current policies [20-30 min] Report from the RIPE NCC Registration Services department on issues and unintended side-effects showing up in the daily implementation of the RIPE policies. (+ brief discussion) D. "Routing Issues" update [10 min] At RIPE 58, we decided to work together with the routing WG to remove "routing policy" from the address policy documents, and have the routing WG come up with an updated routing recommendation document. This is to briefly summarize what this is all about and point to the document. Discussion should take place in the routing WG. E. Document Cosmetic Surgeries Project - Filiz Yilmaz [20 min] (separate item from "B.", because it's really a separate activity - and this gives us a bit scheduling flexibility) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- E. New Proposals since RIPE 58 overview about what's coming [5-10 min] F. Discussion of open policy proposals ---- various stuff, not directly related to IPv4 run-out --- 2006-05 PI Assignment Size [?? min] 2008-07 Ensuring Efficient Use of Historical IPv4 Resources [10 min?] (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders [5 min] (Nigel Titley, CA TF - update what happened since RIPE 58) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs [10-20 min] (5 RIR design team, represented by Axel Pawlik) ---- directly related to IPv4 run-out --- 2009-03 Run Out Fairly (Daniel Karrenberg) [15 min] 2008-06 Use of Final /8 (Philip Smith) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (Alain Bidron) these two proposals will be handled together, and [45 min] the topic will be discussed a bit more "loose" than strictly following these proposals ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- G. IPv6 addressing outside traditional ``Internet'' deployments [30 min] Dr. Joerg Wellbrink, german ministry of defense H. New Policy Proposal: "IPv4 temporary assignment pool", Nick Hilliard [15 min] I. (resuming of the `open policy proposals' discussions, if needed) X. Ideas how to tackle any problems that have been experienced by the NCC Registration Services Department. (open discussion, based on the report and comments on Wednesday) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ingrid at ripe.net Wed Sep 30 16:01:13 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 30 Sep 2009 16:01:13 +0200 Subject: [address-policy-wg] 2009-06 Proposal Accepted (Removing Routing Requirements from the IPv6 Address Allocation Policy) Message-ID: <20090930140113.32DF32F594@herring.ripe.net> PDP Number: 2009-06 Removing Routing Requirements from the IPv6 Address Allocation Policy Dear Colleagues Consensus has been reached, and the proposal described in 2009-06 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-481.html Note: This document also incorporates the changes coming from the proposal described in 2009-08, IPv6 Provider Independent (PI) Assignments for LIRs, for which consensus was also reached. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-06.html Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC From ingrid at ripe.net Wed Sep 30 16:06:19 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 30 Sep 2009 16:06:19 +0200 Subject: [address-policy-wg] 2009-08 Proposal Accepted (IPv6 Provider Independent (PI) Assignments for LIRs) Message-ID: <4AC365DB.2020401@ripe.net> PDP Number: 2009-08 IPv6 Provider Independent (PI) Assignments for LIRs Dear Colleagues Consensus has been reached, and the proposal described in 2009-08 has been accepted by the RIPE community. The related RIPE policy document has now been updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-481.html Note: This document also incorporates the changes coming from the proposal described in 2009-06, Removing Routing Requirements from the IPv6 Address Allocation Policy, for which consensus was also reached. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-08.html Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC From ingrid at ripe.net Wed Sep 30 16:22:55 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 30 Sep 2009 16:22:55 +0200 Subject: [address-policy-wg] Implementation details 2009-06 and 2009-08 Message-ID: <4AC369BF.9090009@ripe.net> Dear Colleagues, In my previous emails regarding the two accepted policy proposals (2009-06 and 2009-08) I overlooked to add information regarding approximate implementation timelines. We expect to be able to implement 2009-06 (Removing Routing Requirements from the IPv6 Address Allocation Policy) within one month and 2009-08 (IPv6 Provider Independent (PI) Assignments for LIRs) within three months. Regards Ingrid Wijte Policy Development Officer RIPE NCC