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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: zaterdag 5 september 2009 16:09 To: address-policy-wg@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
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
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
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
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. :-)
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.
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
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
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
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
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
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...., with a reserved /12 for initial allocations of a fixed /24 size. Or do you mean something different? Thanks, Sander
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...., 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
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@ripe.net [mailto:address-policy-wg- admin@ripe.net] On Behalf Of Michiel Klaver Sent: 14 September 2009 15:16 To: Sander Steffann; address-policy-wg@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
On 14/09/2009 6:15, "Michiel Klaver" <michiel@klaver.it> 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
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
On 14/09/2009 12:50, "Sander Steffann" <sander@steffann.nl> 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
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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: dinsdag 15 september 2009 9:49 To: Leo Vegoda Cc: Michiel Klaver; address-policy-wg@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
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
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@ripe.net [mailto:address-policy-wg-admin@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@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
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
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
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
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
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@bt.com (michael.dillon@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.
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@bt.com (michael.dillon@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
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
michael.dillon@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
On Fri, 18 Sep 2009, Masataka Ohta wrote:
michael.dillon@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
...
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
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
Michael, On Sep 17, 2009, at 12:07 PM, <michael.dillon@bt.com> <michael.dillon@bt.com
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
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.
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....). I'll make sure that this includes a legal analysis. Sander
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....).
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
-----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-----
Hi, On 14/09/2009 12:50, "Sander Steffann" <sander@steffann.nl> 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
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
participants (17)
-
Andreas Schachtner -
David Conrad -
Jim Reid -
Jörgen Eriksson -
Leo Vegoda -
marc.neuckens＠belgacom.be -
Mark Scholten -
Masataka Ohta -
michael.dillon＠bt.com -
Michiel Klaver -
Mohacsi Janos -
Nick Hilliard -
niels=apwg＠bakker.net -
Nigel Titley -
Per Heldal -
Randy Bush -
Sander Steffann