2006-05 New Draft Document Published (PI Assignment Size)
Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC
On 21 October 2010 12:36, Emilio Madaio <emadaio@ripe.net> wrote:
Either I'm going mental or doesn't the line: "Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10." make the proposal completely pointless J -- James Blessing 07989 039 476
On 21/10/2010 12:48, James Blessing wrote:
Either I'm going mental or doesn't the line:
"Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10."
make the proposal completely pointless
In what regard? Nick
On 21 October 2010 13:01, Nick Hilliard <nick@inex.ie> wrote:
On 21/10/2010 12:48, James Blessing wrote:
Either I'm going mental or doesn't the line:
"Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10."
make the proposal completely pointless
In what regard?
"The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24" Last time I looked /24 = 256 addresses Therefore you can't give a 'new' end user a /24 as they have no address space to return and 256 > 248. If it was 2048 then I could understand the logic... J -- James Blessing 07989 039 476
Hi, Am 21.10.2010 um 14:05 schrieb James Blessing:
On 21 October 2010 13:01, Nick Hilliard <nick@inex.ie> wrote:
On 21/10/2010 12:48, James Blessing wrote:
Either I'm going mental or doesn't the line:
"Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10."
make the proposal completely pointless
In what regard?
"The RIPE NCC will assign additional IPv4 addresses to an End User in order to make the assignment size a multiple of a /24"
Last time I looked /24 = 256 addresses
Therefore you can't give a 'new' end user a /24 as they have no address space to return and 256 > 248.
If it was 2048 then I could understand the logic...
You request a /30 and you don't get a /24. You request a /29 and get a /24. ..and so on. Just no more than 248 "additional" IPs to fill the request so it matches /24 boundaries. I think that's how it's meant(?) though it does not make SO much sense. Should be clearer in wording. But i'm still of the opinion that no new IPv4 policy makes any sense anymore anyways. Do we even have continuous /24s anymore in a few months? :-) Anyways, i support the proposal in general since it wastes remaining IPv4 space, i like that. -- bye -slz
Hi, On Thu, Oct 21, 2010 at 12:48:58PM +0100, James Blessing wrote:
On 21 October 2010 12:36, Emilio Madaio <emadaio@ripe.net> wrote:
Either I'm going mental or doesn't the line:
"Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10."
make the proposal completely pointless
It's a "stop the floodgates" clause to try to prevent abuse of this proposal. For the intended purpose ("give people a /24 that do not have the necessary amount of machines and do not want to lie to the NCC") it should not pose a problem - you have 3 machines plus a router, you need 4 addresses = /29. Add 248 addresses, reach /24. The emphasis is "additional" = "in addition to the addresses the requester can justify". The stopgap function is: if the same entity comes back three months later and asks for another /29-to-be-extended-to-a-/24, they won't get it. "Fill your existing /24 first." If that's not sufficiently clear, we might need to reword. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? 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
On 21 October 2010 13:10, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Oct 21, 2010 at 12:48:58PM +0100, James Blessing wrote:
On 21 October 2010 12:36, Emilio Madaio <emadaio@ripe.net> wrote:
Either I'm going mental or doesn't the line:
"Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10."
make the proposal completely pointless
It's a "stop the floodgates" clause to try to prevent abuse of this proposal.
For the intended purpose ("give people a /24 that do not have the necessary amount of machines and do not want to lie to the NCC") it should not pose a problem - you have 3 machines plus a router, you need 4 addresses = /29. Add 248 addresses, reach /24.
The emphasis is "additional" = "in addition to the addresses the requester can justify".
The stopgap function is: if the same entity comes back three months later and asks for another /29-to-be-extended-to-a-/24, they won't get it. "Fill your existing /24 first."
If that's not sufficiently clear, we might need to reword.
Okay no I understand the intent better... How about the following situation: I have 256 machines and 1 router, that's 257 addresses required. Under the new wording I can't then have a /23 because I have a requirement for 253 more addresses to make it up... (I admit its unlikely but a potential situation that needs to be resolved) There is also a potential issue where you have a requirement to subnet multiple locations where you are using a number less than the full number of addresses (eg 33 sites with /29 but only 5 address being used at each site to round up to a /23 you need more that 248 addresses...) "Further assignments under section 6.10 will not be permitted for an End User until all existing assignments have reached 80% utilisation" J -- James Blessing 07989 039 476
On 21 October 2010 14:23, James Blessing <james.blessing@despres.co.uk> wrote:
I have 256 machines and 1 router, that's 257 addresses required. Under the new wording I can't then have a /23 because I have a requirement for 253 more addresses to make it up...
Under that circumstance you'd get a /23 under existing policy. The intent seems to be that if you'd normally be assigned a /29-/25, it's rounded up to a /24. The limit of 248 addresses presumably being to stop abuse, by enabling the NCC to assess this 'slack' across multiple allocations. David
On 22 October 2010 01:24, David Croft <david@sargasso.net> wrote:
On 21 October 2010 14:23, James Blessing <james.blessing@despres.co.uk> wrote:
I have 256 machines and 1 router, that's 257 addresses required. Under the new wording I can't then have a /23 because I have a requirement for 253 more addresses to make it up...
Under that circumstance you'd get a /23 under existing policy.
Really? Not a /24 and a /29?
The intent seems to be that if you'd normally be assigned a /29-/25, it's rounded up to a /24. The limit of 248 addresses presumably being to stop abuse, by enabling the NCC to assess this 'slack' across multiple allocations.
Oh, I agree with what the policy is trying to do. My problem is the wording just needs a little tweak (see my previous suggestion) J -- James Blessing 07989 039 476
On 21/10/2010 13:23, James Blessing wrote:
How about the following situation:
I have 256 machines and 1 router, that's 257 addresses required. Under the new wording I can't then have a /23 because I have a requirement for 253 more addresses to make it up...
(I admit its unlikely but a potential situation that needs to be resolved)
So, can I take it then that you broadly agree with the principle of the policy, but it's just the details which you believe need to be worked on? There are edge cases which cause this policy to creak, and it's not hard to construct "I Cannot Be Played on Record Player X" situations. The policy proposal is not intended to fix 100% of all situations. Instead it is intended to deal with ninety something percent of them. If a policy were created to deal with all potential situations, it would get messy. I did put some thought into this, but retreated from the idea. Incidentally, the reason that 248 was chosen as a cut-off point was that /29 is realistically the smallest chunk of address space that you would want to run a multihomed site on. /29 gives you space for your router interface + two endpoint addresses on a LAN. I already hear you saying "But, but, BUT! You _could_ run a multihomed site on 1, 2 or 4 addresses". Of course you could. But this is not an exercise in playing number games. The intent of /29 is to deal with the smallest realistic network that an end-user is actually going to deploy when they actually go multihomed (1 router + 2 hosts). We could argue endlessly about 248 vs 252 vs 254. But in practice, the exact choice of number is going to make very little difference.
There is also a potential issue where you have a requirement to subnet multiple locations where you are using a number less than the full number of addresses (eg 33 sites with /29 but only 5 address being used at each site to round up to a /23 you need more that 248 addresses...)
This is already a problem with the existing assignment rules. I don't plan to fix this :-)
"Further assignments under section 6.10 will not be permitted for an End User until all existing assignments have reached 80% utilisation"
I don't think it would help to complicate the proposal much more. "Le mieux est l'ennemi du bien". Nick
On Thu, Oct 21, 2010 at 14:10, Gert Doering <gert@space.net> wrote:
If that's not sufficiently clear, we might need to reword.
The wording is clear once you know the intended meaning. Yet, after reading it twice, I was not certain that I understood the intent and all consequences of this rule before I read your explanantion. IMO, the main problem is that "additional" is ambivalent even though it's used in the first sentence, as well. Thus, I would suggest: The RIPE NCC will assign additional IPv4 addresses to an End User in order to pad the assignment size to a multiple of a /24 if an End User demonstrates: [...] Cumulatively, no more than 248 padding IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10. Richard
I'm in favour of this policy Maybe we should change the sentence "Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10." Into something like "Cumulatively, an PI assignment will not reach beyond the next /24 boundary from the motivated need. This might thus result in an PI assignment of more than one subnet of which each subnet is a minimum of a /24". (p.e. a /23, /24 when a need of ~ 520 IP-addresses is motivated). With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office +31 70 45 13398 kpn-ip-office@kpn.com -----Oorspronkelijk bericht----- Van: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] Namens Emilio Madaio Verzonden: donderdag 21 oktober 2010 13:37 Aan: policy-announce@ripe.net CC: address-policy-wg@ripe.net Onderwerp: [address-policy-wg] 2006-05 New Draft Document Published (PI Assignment Size) Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC
On 21/10/2010 14:38, kpn-ip-office@kpn.com wrote:
I'm in favour of this policy
Maybe we should change the sentence
"Cumulatively, no more than 248 additional IPv4 addresses may be assigned to any particular End User for the purposes outlined in section 6.10."
Into something like
"Cumulatively, an PI assignment will not reach beyond the next /24 boundary from the motivated need. This might thus result in an PI assignment of more than one subnet of which each subnet is a minimum of a /24".
(p.e. a /23, /24 when a need of ~ 520 IP-addresses is motivated).
I agree that the wording needs a little work to make the intent clearer, but I'm not convinced that this particular suggestion is necessarily better. Nick
Hi, I was wondering what the status is of this policy. I haven't seen any updates or feedback on this and I think that it would make a lot of sense to proceed with this proposal. For those that didn't go to the RIPE 61 meeting (like myself) or missed Nick Hilliard his preso on the topic : http://ripe61.ripe.net/presentations/318-inex-ripe-rome-apwg-minassignments- 2010-11-17.pdf You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html Regards, Erik Bais
On 01/02/2011 11:14, Erik Bais wrote:
I was wondering what the status is of this policy.
Hi Eric, It's blocking on me to re-formulate and send back to the working group. Unfortunately, I'm just tied up with other stuff at the moment. I'm hoping to get time to deal with this soon. Nick
Hi Nick,
On 01/02/2011 11:14, Erik Bais wrote:
I was wondering what the status is of this policy.
Hi Eric,
It's blocking on me to re-formulate and send back to the working group. Unfortunately, I'm just tied up with other stuff at the moment. I'm hoping to get time to deal with this soon.
Nick
I noticed that the policy is scheduled on the agenda for the next RIPE meeting, but I didn't see anything change in status yet. Did anything change to its currently published form and how it is on the RIPE website published ? If not, it is possible to get this phase concluded asap for the following reasons : 1) We are about to shift the period of assignment for PI from 6 months to 3 months. And by not having something like this in place, we'll end up with PI space that is un-routable, as everyone (or at least a large portion of ISP's) is filtering everything smaller than a /24. 2) For LIR's, being able to do a PI request, without having to make up the story upto the next /24, will make things a lot easier. 3) For the IPRA's, reduction in workload as they don't have to shift through all the made up stories on PI requests and actual legitimate PI requests. As some might say that this policy is out-dated due to the nearby IPv4 depletion, it would be my statement that this is the moment why you would want this and want this ASAP for the above mentioned reasons. In short, can we move ahead with this and yes I do support this. :)
You can find the full proposal at:
and the draft document at:
http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html
Regards, Erik Bais
Erik Bais wrote:
Hi Nick,
On 01/02/2011 11:14, Erik Bais wrote:
I was wondering what the status is of this policy.
Hi Eric,
It's blocking on me to re-formulate and send back to the working group. Unfortunately, I'm just tied up with other stuff at the moment. I'm hoping to get time to deal with this soon.
Nick
I noticed that the policy is scheduled on the agenda for the next RIPE meeting, but I didn't see anything change in status yet.
Did anything change to its currently published form and how it is on the RIPE website published ?
If not, it is possible to get this phase concluded asap for the following reasons :
1) We are about to shift the period of assignment for PI from 6 months to 3 months. And by not having something like this in place, we'll end up with PI space that is un-routable, as everyone (or at least a large portion of ISP's) is filtering everything smaller than a /24. 2) For LIR's, being able to do a PI request, without having to make up the story upto the next /24, will make things a lot easier. 3) For the IPRA's, reduction in workload as they don't have to shift through all the made up stories on PI requests and actual legitimate PI requests.
As some might say that this policy is out-dated due to the nearby IPv4 depletion, it would be my statement that this is the moment why you would want this and want this ASAP for the above mentioned reasons.
In short, can we move ahead with this and yes I do support this. :)
Hello, I'am new here, from land of massive PI requests ;) We are LIR providing SponsorLIR service for little ISPs in Poland. Providing /24 as the smallest entity is a good idea in my opinion, however because little ISPs "wake up" recently willing to replace their i.e. /22 PA to PI (to be multihomed and independent) I hope that getting more than /24 will still be possible - of course if still available in RIR resources. Regards, Marcin
You can find the full proposal at:
and the draft document at:
http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html
Regards, Erik Bais
participants (10)
-
David Croft -
Emilio Madaio -
Erik Bais -
Gert Doering -
James Blessing -
kpn-ip-office＠kpn.com -
Marcin Kuczera -
Nick Hilliard -
Richard Hartmann -
Sascha Lenz