DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space)
[resent after it got filtered] Dear all, So here goes. This is what I think that policy should look like. Any comments before I formally submit it? Best, Remco Number: (assigned by the RIPE NCC) Policy Proposal Name: Allow smaller initial allocations Author: name: Remco van Mook email: remco.vanmook@eu.equinix.com organisation: Equinix Proposal Version: 0.1 Submission Date: July 17, 2009 Suggested RIPE WG for discussion and publication: Address Policy Proposal Type: modify Policy Term: Permanent Summary of proposal: Allow new LIRs to get a smaller initial allocation than the standard at their specific request Policy text: Current (if modify): 5.1 First Allocation The RIPE NCC¹s minimum allocation size is /21. New: 5.1 First Allocation The RIPE NCC¹s minimum allocation size is /21. Consequently, the initial allocation size is /21. However, at the explicit request of the member, a smaller initial allocation up to a /24 can be made. In those cases, the RIPE NCC shall not make efforts to keep adjacent address space available for possible future allocation requests. Rationale: Arguments supporting the proposal Potential LIRs are currently forced to request PI space if they do not require a /21 of address space and want to contribute to the conservation of available global IPv4 resources. This policy change removes that obstacle and reduces the amount of requests for PI space for that purpose. The text looks a bit awkward because this is the only place where the minimum allocation size is specified and I wanted to keep that in - the minimum now being a general rule instead of a hard limit. Arguments opposing the proposal This policy change arguably increases fragmentation. On the other side, PI space assignments are made regardless of the minimum allocation size so the chances of actually increasing fragmentation are minimal. People do filtering based on minimum allocation sizes (I've not seen it in real life but that's the ever-returning argument) but that can be avoided using the ranges normally used for assigning PI for undersized allocations. On 17-07-09 14:02, "Sascha Lenz" <slz@baycix.de> wrote:
Hi,
Remco van Mook schrieb:
Hi Mark,
It is heartening to see that your drive to conservation of IPv4 space alone is pushing you to put all this effort in to get PI space. I¹m sure we can suggest a policy change approved that would set the standard initial allocation to /21 but allow for smaller allocations up to /24 if specifically requested by the new LIR.
[...]
... apart from the fact that i don't think the whole community agrees that we need any form of IPv4 conservation anyways :-) ... i think this would be the apropriate step here, yes.
I would support a more "floating" (first) allocation policy, because even that i think that we don't need to conserve IPv4 space too much, i also don't think that we need to waste it either if there are other simple options like what you suggest (smaller Allocation on request or so).
-- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
------ End of Forwarded Message 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.
Hi, On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote:
So here goes. This is what I think that policy should look like. Any comments before I formally submit it?
Do we *really* need this? The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business. A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table). Operationally, the "/24 PA" would come from the same blocks as /24 PI anyway (minimum allocation size, etc.)... If you're convinced that this really is a good thing, by all means go ahead (and I won't oppose), I'm just afraid that this is a waste of "policy making brain power", solving a not really existing problem... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 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
I beleive the discussion that also started this was due to RIPE being very strict and overly complicated (in my opinion) about PI assignments. (even the first /24+AS) RIPE suggests a lot of: 'Customer should become LIR himself', even if he doesn't need the /21 in the forseeable future. I think your definition of a LIR is something else then RIPE defines it as. Nevertheless, I do agree with your definition of a LIR and I'd rather see the PI assignments being handled in < /21 allocations, and most definately in another (easier, less time consuming) way when a LIR requests one on behalf of a customer. Gert Doering wrote:
Hi,
On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote:
So here goes. This is what I think that policy should look like. Any comments before I formally submit it?
Do we *really* need this?
The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business.
A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table).
Operationally, the "/24 PA" would come from the same blocks as /24 PI anyway (minimum allocation size, etc.)...
If you're convinced that this really is a good thing, by all means go ahead (and I won't oppose), I'm just afraid that this is a waste of "policy making brain power", solving a not really existing problem...
Gert Doering -- APWG chair
-- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl
Hello! On Wed, Jul 22, 2009 at 10:28:14AM +0200, Gert Doering wrote:
On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote:
So here goes. This is what I think that policy should look like. Any comments before I formally submit it?
Do we *really* need this?
Yes, we need this. I support this proposition.
The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business.
A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table).
PI does not allow end user assignments in it. In my opinion it is good reason for allow /24 allocations.
Operationally, the "/24 PA" would come from the same blocks as /24 PI anyway (minimum allocation size, etc.)...
If you're convinced that this really is a good thing, by all means go ahead (and I won't oppose), I'm just afraid that this is a waste of "policy making brain power", solving a not really existing problem...
-- Dmitry Kiselev
Hi, On Wed, Jul 22, 2009 at 11:48:56AM +0300, Dmitry Kiselev wrote:
The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business.
A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table).
PI does not allow end user assignments in it. In my opinion it is good reason for allow /24 allocations.
Well. I can't really see a scenario where I would assign addresses to end users and would be happy with a /24 allocation - our end users get assignments up to a /23 from us... I think one of the focal points here is the question on whether 'giving a hosted web server an IP address' is 'assigning address space to end users'. The boundary cases ("the customer has a virtual web presence and not even a dedicated IP address" and "the customer is running their own web farm and the ISP routes a /24 towards their firewall") are pretty clear - but there is lots of space for different way to do web server hosting in between (managed servers, rented servers, real servers, vmware entities, vserver/jailed virtual servers, ...) The IPv4 PI policy currently defines the transfer networks between an ISP network and an access customer as "part of the ISP infrastructure" - so if you give /32s to DSL end customers, you could run your whole ISP on a PI block (but you can't give one of these customers a /30 to use behind their router). Which is a bit funny indeed. People have argued to remove the PA/PI distinction. I don't think that this is the right way (due to the fact that PA allocations necessarily need to be more liberal than PI assignments), but maybe we need to loosen up PI rules a bit, as in: "Using addresses from a PI block to number other parties' devices is permitted as long as these devices are connected to the same network, documentation about the usage can be presented to the RIPE NCC, and full responsibility for the addresses (abuse handling etc) is done by the PI holder". (After all, one of the reasons why we document end user assignments in a public database is to be able to contact a person feeling responsible for troubleshooting and abuse handling) "same network" is important to make it crystal clear that "get a chunk of PI and sell off smaller bits to 3rd parties connecting at random to other ISPs" is not the desired intention. Now come and flame me :-) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 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
Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose, NCC have always agreed, surely this is a non-issue? ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin@ripe.net on behalf of Gert Doering Sent: Wed 7/22/2009 10:07 To: Dmitry Kiselev Cc: Gert Doering; Remco van Mook; Address Policy Working Group Subject: Re: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) Hi, On Wed, Jul 22, 2009 at 11:48:56AM +0300, Dmitry Kiselev wrote:
The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business.
A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table).
PI does not allow end user assignments in it. In my opinion it is good reason for allow /24 allocations.
Well. I can't really see a scenario where I would assign addresses to end users and would be happy with a /24 allocation - our end users get assignments up to a /23 from us... I think one of the focal points here is the question on whether 'giving a hosted web server an IP address' is 'assigning address space to end users'. The boundary cases ("the customer has a virtual web presence and not even a dedicated IP address" and "the customer is running their own web farm and the ISP routes a /24 towards their firewall") are pretty clear - but there is lots of space for different way to do web server hosting in between (managed servers, rented servers, real servers, vmware entities, vserver/jailed virtual servers, ...) The IPv4 PI policy currently defines the transfer networks between an ISP network and an access customer as "part of the ISP infrastructure" - so if you give /32s to DSL end customers, you could run your whole ISP on a PI block (but you can't give one of these customers a /30 to use behind their router). Which is a bit funny indeed. People have argued to remove the PA/PI distinction. I don't think that this is the right way (due to the fact that PA allocations necessarily need to be more liberal than PI assignments), but maybe we need to loosen up PI rules a bit, as in: "Using addresses from a PI block to number other parties' devices is permitted as long as these devices are connected to the same network, documentation about the usage can be presented to the RIPE NCC, and full responsibility for the addresses (abuse handling etc) is done by the PI holder". (After all, one of the reasons why we document end user assignments in a public database is to be able to contact a person feeling responsible for troubleshooting and abuse handling) "same network" is important to make it crystal clear that "get a chunk of PI and sell off smaller bits to 3rd parties connecting at random to other ISPs" is not the desired intention. Now come and flame me :-) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 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
Hi, On Wed, Jul 22, 2009 at 10:09:32AM +0100, David Freedman wrote:
Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose, NCC have always agreed, surely this is a non-issue?
Well, the question came up on this list (on whether "web server hosting" would be a valid purpose for IPv6 PI), and it seem that other people had issues requesting IPv4 PI for customers that do "web server hosting". So at least some clarification might be helpful, if only to help the hostmasters (IPRAs) to cause less irritation due to different interpretations on both sides... Maybe we can get a few words from the NCC on how PI requests are evaluated in the context of "we want to run web servers in that space" today? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 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
Well, the question came up on this list (on whether "web server hosting" would be a valid purpose for IPv6 PI), and it seem that other people had issues requesting IPv4 PI for customers that do "web server hosting".
Sure, I mean the way I see it, it isn't an allocation to an end user, as the assignment holder yourself you are allowing the customer to use your infrastructure addresses and as such you have full responsibility for them. Since we don't live in a (well) adopted RFC2616/RFC3546 world, each customer with an SSL cert needs to use one of your addresses for this purpose, this to me is a valid reason for needing an assignment of $size based on your usage expectations and growth model. Would like to think that I have been involved in numerous PI applications over the years (even recently) where this has been used as a justification and not a single IPRA has had an objection when this is stated clearly and shown to be the case. I think I would like to see the original application wording. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: Wed 7/22/2009 10:16 To: David Freedman Cc: Gert Doering; Dmitry Kiselev; Remco van Mook; Address Policy Working Group Subject: Re: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) Hi, On Wed, Jul 22, 2009 at 10:09:32AM +0100, David Freedman wrote:
Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose, NCC have always agreed, surely this is a non-issue?
Well, the question came up on this list (on whether "web server hosting" would be a valid purpose for IPv6 PI), and it seem that other people had issues requesting IPv4 PI for customers that do "web server hosting". So at least some clarification might be helpful, if only to help the hostmasters (IPRAs) to cause less irritation due to different interpretations on both sides... Maybe we can get a few words from the NCC on how PI requests are evaluated in the context of "we want to run web servers in that space" today? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 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
Hello! On Wed, Jul 22, 2009 at 11:07:47AM +0200, Gert Doering wrote:
The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business.
A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table).
PI does not allow end user assignments in it. In my opinion it is good reason for allow /24 allocations.
Well. I can't really see a scenario where I would assign addresses to end users and would be happy with a /24 allocation - our end users get assignments up to a /23 from us...
<snip> Keeping in mind IPv4 runout I see no reasons why we should force LIR to receive more address space then he need/requested. I think it is no matter why LIR need such tiny block, he is free to run own network as he want. May be we should add an extra text to this proposal which will require renumbering if additional allocation is requested and all allocations size below some threshold. It should prevent unnecessary GRT grow. If /21 limitation shifts to /24, NCC IPRAs will get additional option to force PI applicant become a member. It is negative impact of proposal, I think. -- Dmitry Kiselev
Gert Doering wrote:
I think one of the focal points here is the question on whether 'giving a hosted web server an IP address' is 'assigning address space to end users'.
Yep, I agree. I usually don't come across those cases in my line of work either, but in the cases I read about in the last couple of weeks it were usually hosting providers with physically independent hosting locations that needed addresses to assign to their customers (who, maybe for redundancy reasons, want two servers with a small subnet in two locations). This case isn't covered by the current PI policy and so the problems began. Your idea:
People have argued to remove the PA/PI distinction. I don't think that this is the right way (due to the fact that PA allocations necessarily need to be more liberal than PI assignments), but maybe we need to loosen up PI rules a bit, as in:
"Using addresses from a PI block to number other parties' devices is permitted as long as these devices are connected to the same network, documentation about the usage can be presented to the RIPE NCC, and full responsibility for the addresses (abuse handling etc) is done by the PI holder".
seems very reasonably to me (modulo some inaccuracies due to human language), I think this is the way to go forward regarding this problem. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms@man-da.de Geschäftsführer Marcus Stögbauer AG Darmstadt, HRB 94 84
On 22 Jul 2009, at 09:19, Remco van Mook wrote:
The RIPE NCC’s minimum allocation size is /21. Consequently, the initial allocation size is /21. However, at the explicit request of the member, a smaller initial allocation up to a /24 can be made. In those cases, the RIPE NCC shall not make efforts to keep adjacent address space available for possible future allocation requests.
First thoughts - No opposed to this at all, but please make the smaller allocations from a new /8 so that existing minimum allocation size documentation/filters do not need to be updated. Because we know that a lot of the time they wont be. :-) Andy -- Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com NetSumo Ltd, Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC /* Opinions are my own and & may not constitute policy of any org I work for */
participants (7)
-
Andy Davidson -
David Freedman -
Dmitry Kiselev -
Gert Doering -
Jeroen Wunnink -
Marcus Stoegbauer -
Remco van Mook