Reopening discussion on RIPE Policy Proposal 2006-05
Members, I'd like to re-open the discussion for http://www.ripe.net/ripe/policies/proposals/2006-05.html which is still pending approval. In the current IPv4 address policy, routability on the internet is not a factor that is allowed to be taken into account when a PI space is requested. Yet anything smaller then a /24 is pretty much useless since most providers filter anything below /24 out. -- 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
Jeroen Wunnink wrote:
In the current IPv4 address policy, routability on the internet is not a factor that is allowed to be taken into account when a PI space is requested. Yet anything smaller then a /24 is pretty much useless since most providers filter anything below /24 out.
I think minimum PA allocation should, instead, be /24. Then, ISPs assigning /26 (or /28, maybe) to their customers will start actively exchanging /26. Of course, the number of routing table entries will further explode, but it will so with IPv6. Masataka Ohta
I've ran across a couple of networks who filter on /23, in fact I did it myself for a while while we were waiting for an upgrade. So the /24 is just as arbitrary as any other range. I ain't gonna see this one fly, what people will accept for routing as their business and shouldn't influence allocation or assignment policy. In fact during last meeting there was quite some debate about the fact all references to routing and/or filtering policy should be removed from address policy documents. RIPE and or RIPE NCC will never guarantee routabillity for any address range, adjusting the policy to allow a /24 just to get passed some filters implies you get routed. This is a bad proposal, completely going into the wrong direction and I won't support it, it should have been dropped years ago instead of keeping it sleeping. Grtx, MarcoH On Jul 16, 2009, at 5:17 PM, Jeroen Wunnink wrote:
Members,
I'd like to re-open the discussion for http://www.ripe.net/ripe/policies/proposals/2006-05.html which is still pending approval.
In the current IPv4 address policy, routability on the internet is not a factor that is allowed to be taken into account when a PI space is requested. Yet anything smaller then a /24 is pretty much useless since most providers filter anything below /24 out.
--
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
It's not a bad proposal - there was a great discussion before. Arin has implemented this in their IP policy and it's been working great FOR YEARS. No wonder why we have moved two clients to Arin IP space (infrastructure end) because we were unable to meet Ripe policy requirements. You cannot get a /24 for anycast from Ripe if you cannot meet IP usage requirements, except if you are a ctld (they call it "critical infrastructure" - I don't). Why you didn't oppose "<http://www.ripe.net/ripe/policies/proposals/2008-05.html>Anycasting Assignments for TLDs and Tier 0/1 ENUM" policy that allows ctld operators now to use 4x /24 for DNS anycast? It just got accepted... If you are filtering /24 routes you are filtering out "critical internet infrastructure"... hehe ;) Greg At 00:33 2009.07.17.ÿ, you wrote:
I've ran across a couple of networks who filter on /23, in fact I did it myself for a while while we were waiting for an upgrade. So the /24 is just as arbitrary as any other range.
I ain't gonna see this one fly, what people will accept for routing as their business and shouldn't influence allocation or assignment policy. In fact during last meeting there was quite some debate about the fact all references to routing and/or filtering policy should be removed from address policy documents.
RIPE and or RIPE NCC will never guarantee routabillity for any address range, adjusting the policy to allow a /24 just to get passed some filters implies you get routed.
This is a bad proposal, completely going into the wrong direction and I won't support it, it should have been dropped years ago instead of keeping it sleeping.
Grtx,
MarcoH
On Jul 16, 2009, at 5:17 PM, Jeroen Wunnink wrote:
Members,
I'd like to re-open the discussion for http://www.ripe.net/ripe/policies/proposals/2006-05.html which is still pending approval.
In the current IPv4 address policy, routability on the internet is not a factor that is allowed to be taken into account when a PI space is requested. Yet anything smaller then a /24 is pretty much useless since most providers filter anything below /24 out.
--
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
Hi, On Fri, Jul 17, 2009 at 09:41:00AM +0300, Greg wrote:
It's not a bad proposal - there was a great discussion before.
Having "great discussions" doesn't necessarily make it a *good* proposal either. The amount of discussions and mixed feedback we have seen tells me that we have no consenus yet to go forward with this proposal (not even "very rough"). I have on my TODO list to go through the PI numbers that Alex has posted and try to figure out how "real" this percieved problem is *today*, and then we can go forward with less emotional and more educated discussion. regards, 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 believe the proposal has great merit and needs further discussion, and is directly related to my email on the 12th July. "The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) So the only way to implement Multi-Homed BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object." And while all transits may not route a /24 IP Range, the Tier1 transits we are paying for transit do route /24 networks, but are filtering anything smaller. Keith -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering Sent: 17 July 2009 09:42 To: Greg Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Hi, On Fri, Jul 17, 2009 at 09:41:00AM +0300, Greg wrote:
It's not a bad proposal - there was a great discussion before.
Having "great discussions" doesn't necessarily make it a *good* proposal either. The amount of discussions and mixed feedback we have seen tells me that we have no consenus yet to go forward with this proposal (not even "very rough"). I have on my TODO list to go through the PI numbers that Alex has posted and try to figure out how "real" this percieved problem is *today*, and then we can go forward with less emotional and more educated discussion. regards, 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
* Keith.Nolan@premiereglobal.ie (Nolan, Keith) [Fri 17 Jul 2009, 13:06 CEST]:
I believe the proposal has great merit and needs further discussion, and is directly related to my email on the 12th July.
"The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) So the only way to implement Multi-Homed BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object."
And while all transits may not route a /24 IP Range, the Tier1 transits we are paying for transit do route /24 networks, but are filtering anything smaller.
The RIPE NCC hands out addresses based on a need for addresses, not on a need to satisfy other parties' policies. This is a good thing and it should stay that way. -- Niels. -- <BitKat> zo weten we nog steeds niet of de steganosaurus wel echt bestaan heeft
On the RIPE Website regarding the Ripe Community "RIPE (Réseaux IP Européens) is a collaborative forum open to all parties interested in wide area IP networks. The objective of RIPE is to ensure the administrative and technical co-ordination necessary to enable the operation of the Internet within the RIPE region." I believe the RIPE community has a requirement to set policy to ensure the IP's which RIPE NCC handout based on need, meet the administrative and technical requirements to be usable on the internet, and if that means a /24 is the smallest IPv4 space which can't be aggregated is allowed to be handed out, due to standard industry practice of filtering anything smaller than a /24 or if it means we influence standard practice to have smaller IPv4 space not filtered and increasing the size of the routing tables, I think we need to provide RIPE NCC with clear guidelines to help them meet the communities objective. Keith -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Niels Bakker Sent: 17 July 2009 17:45 To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 * Keith.Nolan@premiereglobal.ie (Nolan, Keith) [Fri 17 Jul 2009, 13:06 CEST]:
I believe the proposal has great merit and needs further discussion, and is directly related to my email on the 12th July.
"The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) So the only way to implement Multi-Homed BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object."
And while all transits may not route a /24 IP Range, the Tier1 transits we are paying for transit do route /24 networks, but are filtering anything smaller.
The RIPE NCC hands out addresses based on a need for addresses, not on a need to satisfy other parties' policies. This is a good thing and it should stay that way. -- Niels. -- <BitKat> zo weten we nog steeds niet of de steganosaurus wel echt bestaan heeft
On 16/07/2009 22:33, Marco Hogewoning wrote:
This is a bad proposal, completely going into the wrong direction and I won't support it, it should have been dropped years ago instead of keeping it sleeping.
To be fair, this is a one-sided viewpoint. The reality is that the current policies cause people to lie on their PI application forms in order to justify a /24. The reason for this is simple. At a certain stage in their existence, many businesses realise that single-homing using PA address space can cause serious business continuity problems. If your single upstream has an outage, your site will go down and your money will stop coming in. If you want diversity through multiple providers, you can forget about it. But more importantly, there is a supplier lock-in associated with using your upstream's PA address space: if you decide to renumber to another address block, then this renumbering process is going to cost money, and if it's not done very carefully, it can also cause loss of revenue. So, when your connectivity provider starts acting the maggot, they can do so with a certain degree of impunity - and this degree has a discrete financial value associated with it. Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy. All these things are serious and legitimate concerns for small businesses. So, if you're one of these businesses which depends on good quality, diverse upstream connectivity, but only have a requirement for relatively small numbers of addresses (for whatever reason - there can be many, ranging from frugality to low interface count), you have three choices for dealing with your business continuity requirements: 1. get a < /24 address block from the RIPE NCC and then discover that this is completely useless, 2. lie to RIPE NCC about your addressing requirements and get yourself a /24, or 3. continue to build your business on the basis of a continuing good relationship with a single upstream provider, and hope that this relationship does not deteriorate to the extent that the cost of continuing in this relationship does not exceed the cost of renumbering out of that address block and severing ties with that provider. I'm not attempting to justify any of these positions or say that a minimum assignment size of /24 is an elegant solution to this problem. All I'm saying is that they are simply the reality for many small businesses, and that continuing to stick our collective heads in the sand about this isn't going to change the reality. The result of this is that -- according to the prefixlen stats for PI assignments provided by the NCC which indicate that hardly anyone applies for < /24, and that the vast majority of assignments are for exactly /24 -- people are quite clearly making a wholesale mockery of the address assignment RIPE policies by consistently and wholeheartedly lying though their teeth on their application forms. This is, in my opinion, a much worse situation than compromising on a minimum assignment size of /24. I also note that most of the people complaining about proposal work with large organisations which are unaffected by the restrictions and workarounds that that 2006-05 attempts to solve. Nick
At 19:12 2009.07.25.ÿ, you wrote:
The result of this is that -- according to the prefixlen stats for PI assignments provided by the NCC which indicate that hardly anyone applies for < /24, and that the vast majority of assignments are for exactly /24 -- people are quite clearly making a wholesale mockery of the address assignment RIPE policies by consistently and wholeheartedly lying though their teeth on their application forms.
This is, in my opinion, a much worse situation than compromising on a minimum assignment size of /24.
I also note that most of the people complaining about proposal work with large organisations which are unaffected by the restrictions and workarounds that that 2006-05 attempts to solve.
Nick
Very wise words. You can only see how fast "large organization friendly" proposals go through and are accepted - this is just my personal view :) See the multiple /24 allocations for cTLDs that just got accepted. For multi-homing purposes and if your infrastructure allows it - you can easily get /24 ARIN ip space allocated from your US provider. However, to comply with Arin IP v4 rules you can only get one such block (/24 per company). We have worked with multiple clients (from Europe) and it works like a charm. We went this route because I don't think anything will change in the future (and thanks God we did it - it's been 2 years+ and nothing have changed). Greg http://www.linuxadmin.org/
On 25 Jul 2009, at 17:44, Greg wrote:
You can only see how fast "large organization friendly" proposals go through and are accepted - this is just my personal view :) See the multiple /24 allocations for cTLDs that just got accepted.
It's not clear what point, if any, you're making here. The recent change to provide space to TLDs for anycasting was discussed on this list. Everyone had a chance to contribute to that policy development. Many did. Including some like me who represent no large organisation or even an LIR. The consensus was that these allocations would be a Good Thing for the Internet, not just the TLD operators who would get the space. Everybody and everything using the Internet benefits if the DNS infrastructure for things like TLDs is made more robust by anycasting, there's not just a small number of DNS hosting companies offering commercial anycast services, etc, etc. I fail to understand why you'd characterise this policy as being "large organisation friendly". It's clearly for the benefit of everyone using the Internet. Oh and most TLD registries are not large organisations. The biggest of them have turnover and staffing equivalent to a modest ISP. My guess is the TLD registries that are NCC members will probably be in the small membership category because, comparitively speaking, they don't need or use a lot of numbering resources. Now it may be that large organisations are better placed than small ones to participate in policy discussions or attend RIPE meetings. That's just a a fact of life. However it doesn't mean policy-making is dominated by those large organisations. The barrier for participation in policy discussions could hardly be any lower: a mail/web client and some understanding of English. Your complaint, if it is indeed a complaint, seems to be a bit like moaning about the government when you've not even bothered to vote.
Jim and all, Anyone with half a brain and only a bit of experiance know that policy making almost always favors large orgs. significantly. Jim Reid wrote:
On 25 Jul 2009, at 17:44, Greg wrote:
You can only see how fast "large organization friendly" proposals go through and are accepted - this is just my personal view :) See the multiple /24 allocations for cTLDs that just got accepted.
It's not clear what point, if any, you're making here.
The recent change to provide space to TLDs for anycasting was discussed on this list. Everyone had a chance to contribute to that policy development. Many did. Including some like me who represent no large organisation or even an LIR. The consensus was that these allocations would be a Good Thing for the Internet, not just the TLD operators who would get the space. Everybody and everything using the Internet benefits if the DNS infrastructure for things like TLDs is made more robust by anycasting, there's not just a small number of DNS hosting companies offering commercial anycast services, etc, etc.
I fail to understand why you'd characterise this policy as being "large organisation friendly". It's clearly for the benefit of everyone using the Internet. Oh and most TLD registries are not large organisations. The biggest of them have turnover and staffing equivalent to a modest ISP. My guess is the TLD registries that are NCC members will probably be in the small membership category because, comparitively speaking, they don't need or use a lot of numbering resources.
Now it may be that large organisations are better placed than small ones to participate in policy discussions or attend RIPE meetings. That's just a a fact of life. However it doesn't mean policy-making is dominated by those large organisations. The barrier for participation in policy discussions could hardly be any lower: a mail/web client and some understanding of English. Your complaint, if it is indeed a complaint, seems to be a bit like moaning about the government when you've not even bothered to vote.
Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
On Sat, 25 Jul 2009 17:12:45 +0100 Nick Hilliard <nick@inex.ie> wrote:
Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy.
RIR policies is not the right tool to regulate ISP behaviour. Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets. //per
Hello Per, That would mean that ALL Ip addresses could be taken to another provider/network and that it works. For example if a client has a /24 PA and they go to another network they need the option to take it with them. At least if you compare it to phone number portability in the Netherlands. This also means that if someone uses a /30 (a server with 2 or 3 SSL certificates for example) and they go to another network they can take the IP addresses (even with a /32). And other networks have to be required to route traffic to them or the old network has to route all traffic for that range to the new network. Currently this is not the case and without changing rules (even within the RIPE policy) it won't change probably. I would be happy to see something in the RIPE policy/rules that it works like the number portability for IP addresses, because RIPE NCC follows Dutch laws (and it is mentioned in new contracts for as far as I know) all network operators that have IP addresses from RIPE will also work like this. This means that filtering anything less than a /24 IPv4 is impossible (filtering by route objects or per IP is possible). It also creates "cheap" options for networks to get IP addresses from other networks if they want. Getting co location in another network and getting as much IP addresses as possible with that network and only using it for 1 or 3 months is enough to transfer the IP addresses. This is something that shouldn't be possible if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Per Heldal Sent: zaterdag 25 juli 2009 21:29 To: Nick Hilliard Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 On Sat, 25 Jul 2009 17:12:45 +0100 Nick Hilliard <nick@inex.ie> wrote:
Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy.
RIR policies is not the right tool to regulate ISP behaviour. Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets. //per
Stream Service || Mark Scholten wrote:
Hello Per,
That would mean that ALL Ip addresses could be taken to another provider/network and that it works. For example if a client has a /24 PA and they go to another network they need the option to take it with them.
This is why PI exists. Try using that as has been suggested already several times by other people.
At least if you compare it to phone number portability in the Netherlands.
If you are going to compare IP addresses to phone numbers, then you have to make the Internet work like the Phone system, which would basically mean a 'flow based' routing system: at connect time get the destination, store this and presto keep on using that. This does not work for the Internet as routes change (for phone you get a disconnect when a route changes due to a fiber cut or some other such event. For the Internet, where a sender could just start spewing packets to a million destinations, and possibly from a million sources, flow-based routing does not work, take a small guess why. Also, this is a POLICY list, not a TECHNICAL PROPOSAL list, for the latter there is the IRTF, note the R for Research, as the IETF is not even ready for these kind of changes (rrg WG comes in mind though). Greets, Jeroen
Hello Per,
That would mean that ALL Ip addresses could be taken to another provider/network and that it works. For example if a client has a /24 PA and they go to another network they need the option to take it with
Hello Jeroen, It was a reaction based on the message Per did write. If you compare IP addresses to phone numbers: compare everything and not just the part you like. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jeroen Massar Sent: zaterdag 25 juli 2009 23:45 To: Stream Service || Mark Scholten Cc: 'Per Heldal'; 'Nick Hilliard'; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Stream Service || Mark Scholten wrote: them. This is why PI exists. Try using that as has been suggested already several times by other people.
At least if you compare it to phone number portability in the Netherlands.
If you are going to compare IP addresses to phone numbers, then you have to make the Internet work like the Phone system, which would basically mean a 'flow based' routing system: at connect time get the destination, store this and presto keep on using that. This does not work for the Internet as routes change (for phone you get a disconnect when a route changes due to a fiber cut or some other such event. For the Internet, where a sender could just start spewing packets to a million destinations, and possibly from a million sources, flow-based routing does not work, take a small guess why. Also, this is a POLICY list, not a TECHNICAL PROPOSAL list, for the latter there is the IRTF, note the R for Research, as the IETF is not even ready for these kind of changes (rrg WG comes in mind though). Greets, Jeroen
Stream Service || Mark Scholten wrote:
Hello Jeroen,
It was a reaction based on the message Per did write. If you compare IP addresses to phone numbers: compare everything and not just the part you like.
I indeed suggest you do that. Greets, Jeroen
On Sat, 25 Jul 2009 23:25:07 +0200 "Stream Service || Mark Scholten" <mark@streamservice.nl> wrote:
Hello Per,
That would mean that ALL Ip addresses could be taken to another provider/network and that it works. For example if a client has a /24 PA and they go to another network they need the option to take it with them. At least if you compare it to phone number portability in the Netherlands.
Phone numbers compare better to DNS A-records than IP-addresses. I didn't in any way suggest that addresses should transfer between providers. My point is that there are technical solutions and operational practises available that greatly simplify renumbering, and I'd prefer to see those being refined (and enforced) over changes to RIR policies. This is thus an issue that is better addressed by a combination of standards bodies (IETF), tech communities and market regulators. I'm aware of complexities such as crypto certificates, but that's only a symptom of bad solutions which lack dynamic mechanisms to deal with necessary changes. I see the need for some very limited use of PI, but I don't feel the need for more permissive policies than we already have. //per
On 25/07/2009 20:29, Per Heldal wrote:
RIR policies is not the right tool to regulate ISP behaviour.
I'm not attempting to cast judgement on this either way. All I'm saying is that because internet businesses recognise that PI addresses provide tangible business advantages, they will attempt to obtain them by any reasonable means at their disposal. If this means lying on an application form, then they will do this. I believe this to be harmful to the RIPE community. To get a handle on the problem, here are the PI assignment stats for the past couple of years:
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2009/msg00267....
Since 2005-01-01, 128 assignments were made of less than /24 and 3934 of exactly /24. These figures do not look to me like the results of 3934 honest assignment application forms. Turning this around, if the minimum PI assignment size were increased from /32 to /24, there would have been 23k extra PI addresses out of 5493760 total PI addresses assigned between 2005-01-01 and 2009-05. That's about 0.4%. Nick
Nick, On 25/07/2009 2:57, "Nick Hilliard" <nick@inex.ie> wrote: [...]
Turning this around, if the minimum PI assignment size were increased from /32 to /24, there would have been 23k extra PI addresses out of 5493760 total PI addresses assigned between 2005-01-01 and 2009-05. That's about 0.4%.
I wonder if you are right. Right now, the policies for PA and PI are the same: if you qualify for a /28 of PA then you qualify for a /28 of PI. But if you change the policy so that when you qualify for a /28 of PA then you qualify for a /24 of PI then PI space becomes much more attractive because you get more space and it is independent of your ISP. Any time an ISP had a customer who wants more space than they qualify for under the PA policy they have an opportunity to upsell them a /24 of PI. I suspect that a policy along these lines could end up as a cash generator for ISPs. I don't know how to quantify this and maybe I'm wrong anyway. Nonetheless, I think this should be considered as a potential risk for a policy that allows /24 PI assignments based solely on a phrase as vague as "when routing is a major issue". Regards, Leo Vegoda
On 27/07/2009 17:07, Leo Vegoda wrote:
Right now, the policies for PA and PI are the same: if you qualify for a /28 of PA then you qualify for a /28 of PI. But if you change the policy so that when you qualify for a /28 of PA then you qualify for a /24 of PI then PI space becomes much more attractive because you get more space and it is independent of your ISP.
I deliberately left this out of the calculation, and perhaps phrased things slightly sloppily. It's a know unknown, or perhaps an unknown unknown, to borrow a cliche. Besides the two issues are still separate. Qualifying for /28 PA is a matter of just having 8 internet-connected machines within 1 year and the ability to configure a default route on each machine. Qualifying for /24 PI would be a matter of having 8 internet connected machines, a router, an ASN, more than one upstream transit partner or a bunch of peering partners and enough in-house or consultancy clue to make this all work. It's not rocket science, of course. But it does have a cost and it would be interesting to compare the cost of this scenario to the cost associated with becoming a LIR and requesting a minimum allocation (if all you're looking for is routable address space).
I don't know how to quantify this and maybe I'm wrong anyway. Nonetheless, I think this should be considered as a potential risk for a policy that allows /24 PI assignments based solely on a phrase as vague as "when routing is a major issue".
Yes, it's a risk, and should be noted explicitly in any proposal. I don't doubt that it would cause greater uptake of PI address assignment requests - and this is one of the reasons that this is not a pretty solution to the problem. On a side note, I wonder whether the lower number of requests for the year until may was due to the new contractual requirements. Nick
Hi Nick, On 27/07/2009 9:38, "Nick Hilliard" <nick@inex.ie> wrote:
On 27/07/2009 17:07, Leo Vegoda wrote:
Right now, the policies for PA and PI are the same: if you qualify for a /28 of PA then you qualify for a /28 of PI. But if you change the policy so that when you qualify for a /28 of PA then you qualify for a /24 of PI then PI space becomes much more attractive because you get more space and it is independent of your ISP.
I deliberately left this out of the calculation, and perhaps phrased things slightly sloppily. It's a know unknown, or perhaps an unknown unknown, to borrow a cliche.
Besides the two issues are still separate. Qualifying for /28 PA is a matter of just having 8 internet-connected machines within 1 year and the ability to configure a default route on each machine. Qualifying for /24 PI would be a matter of having 8 internet connected machines, a router, an ASN, more than one upstream transit partner or a bunch of peering partners and enough in-house or consultancy clue to make this all work.
Ah... That was the other piece of vague language. The proposed text says "demonstrate a plan to multihome". The word "plan" has been interpreted as a *very* low bar in the IPv6 policy and I suspect that it would be unreasonable to have the word interpreted very differently in this policy. So, my interpretation of the requirement as written in the proposal is that it requires "a plan". Not a set of contracts. Not proof that there is equipment. Not proof that there are people with the required skills. The way I read the text, a requester would need a network design and maybe a generic "fill in the blanks" implementation plan. That is all. So, while I can see that there is an unmet need, I also think that the text in this current proposal is sufficiently loose to allow the creation of a "pay for PI" industry. I make no comment on whether that is a desirable outcome. [...]
On a side note, I wonder whether the lower number of requests for the year until may was due to the new contractual requirements.
An excellent question. I would also like to know this. Regards, Leo Vegoda
On 27/07/2009 17:07, Leo Vegoda wrote:
Right now, the policies for PA and PI are the same: if you qualify for a /28 of PA then you qualify for a /28 of PI. But if you change the policy so
when you qualify for a /28 of PA then you qualify for a /24 of PI then PI space becomes much more attractive because you get more space and it is independent of your ISP.
I deliberately left this out of the calculation, and perhaps phrased
Hello Nick and Leo, There is a lower request for IPv4 PI and it is very likely that the requests are lower because of this contract. I know multiple LIRs that don't have the contracts ready and don't process PI requests anymore (they don't have the contracts ready or don't want to offer the contracts). Regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Leo Vegoda Sent: maandag 27 juli 2009 18:59 To: Nick Hilliard Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Hi Nick, On 27/07/2009 9:38, "Nick Hilliard" <nick@inex.ie> wrote: that things
slightly sloppily. It's a know unknown, or perhaps an unknown unknown, to borrow a cliche.
Besides the two issues are still separate. Qualifying for /28 PA is a matter of just having 8 internet-connected machines within 1 year and the ability to configure a default route on each machine. Qualifying for /24 PI would be a matter of having 8 internet connected machines, a router, an ASN, more than one upstream transit partner or a bunch of peering partners and enough in-house or consultancy clue to make this all work.
Ah... That was the other piece of vague language. The proposed text says "demonstrate a plan to multihome". The word "plan" has been interpreted as a *very* low bar in the IPv6 policy and I suspect that it would be unreasonable to have the word interpreted very differently in this policy. So, my interpretation of the requirement as written in the proposal is that it requires "a plan". Not a set of contracts. Not proof that there is equipment. Not proof that there are people with the required skills. The way I read the text, a requester would need a network design and maybe a generic "fill in the blanks" implementation plan. That is all. So, while I can see that there is an unmet need, I also think that the text in this current proposal is sufficiently loose to allow the creation of a "pay for PI" industry. I make no comment on whether that is a desirable outcome. [...]
On a side note, I wonder whether the lower number of requests for the year until may was due to the new contractual requirements.
An excellent question. I would also like to know this. Regards, Leo Vegoda
On 25 Jul 2009, at 22:57, Nick Hilliard wrote:
Since 2005-01-01, 128 assignments were made of less than /24 and 3934 of exactly /24. These figures do not look to me like the results of 3934 honest assignment application forms.
Turning this around, if the minimum PI assignment size were increased from /32 to /24, there would have been 23k extra PI addresses out of 5493760 total PI addresses assigned between 2005-01-01 and 2009-05. That's about 0.4%.
I agree that the amounts in question are trivial and the benefits to the community (at least for the ten minutes or so that there is unallocated ipv4 left...) will be appreciated by small orgs looking for the benefits of multihoming - Nick's words are right as usual. However, I don't think we should mandate that /24 be the minimum assignment size - the rule should allow requests for a /24 to be the minimum size for announcement on the Internet, but if networks are not planning to announce the prefix via bgp (e.g. non-announced loopback ranges), then they should be allowed to request a smaller range. But as you say if we do mandate this the effect is trivial. -- 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 */
On 29 jul 2009, at 21:22, Andy Davidson wrote:
On 25 Jul 2009, at 22:57, Nick Hilliard wrote:
Since 2005-01-01, 128 assignments were made of less than /24 and 3934 of exactly /24. These figures do not look to me like the results of 3934 honest assignment application forms.
Turning this around, if the minimum PI assignment size were increased from /32 to /24, there would have been 23k extra PI addresses out of 5493760 total PI addresses assigned between 2005-01-01 and 2009-05. That's about 0.4%.
I agree that the amounts in question are trivial and the benefits to the community (at least for the ten minutes or so that there is unallocated ipv4 left...) will be appreciated by small orgs looking for the benefits of multihoming - Nick's words are right as usual.
However, I don't think we should mandate that /24 be the minimum assignment size - the rule should allow requests for a /24 to be the minimum size for announcement on the Internet, but if networks are not planning to announce the prefix via bgp (e.g. non-announced loopback ranges), then they should be allowed to request a smaller range. But as you say if we do mandate this the effect is trivial.
The question remains what to do when "the internet" - or some part of it - decide to filter on /23. Do we modify the policy again to make / 23 the minimum ? Are we going to allow people to hand in their original /24 assignment and grow it to /23 ? Groet, MarcoH
On Aug 18, 2009, at 5:50 AM, Marco Hogewoning wrote:
On 29 jul 2009, at 21:22, Andy Davidson wrote:
On 25 Jul 2009, at 22:57, Nick Hilliard wrote:
Since 2005-01-01, 128 assignments were made of less than /24 and 3934 of exactly /24. These figures do not look to me like the results of 3934 honest assignment application forms.
Turning this around, if the minimum PI assignment size were increased from /32 to /24, there would have been 23k extra PI addresses out of 5493760 total PI addresses assigned between 2005-01-01 and 2009-05. That's about 0.4%.
I agree that the amounts in question are trivial and the benefits to the community (at least for the ten minutes or so that there is unallocated ipv4 left...) will be appreciated by small orgs looking for the benefits of multihoming - Nick's words are right as usual.
However, I don't think we should mandate that /24 be the minimum assignment size - the rule should allow requests for a /24 to be the minimum size for announcement on the Internet, but if networks are not planning to announce the prefix via bgp (e.g. non-announced loopback ranges), then they should be allowed to request a smaller range. But as you say if we do mandate this the effect is trivial.
The question remains what to do when "the internet" - or some part of it - decide to filter on /23. Do we modify the policy again to make /23 the minimum ? Are we going to allow people to hand in their original /24 assignment and grow it to /23 ?
If you want my opinion, no. There is never a guarantee that any assignment will be routable anywhere and there is no way to make such guarantees. Some time ago, IPv4 filtering blocks longer than /20 was fairly common. In fact, when ARIN passed 2002-3 (its micro-assignment policy for multi-homed networks), that was still the case. While there was not a land-rush to claim smaller blocks, there was adoption even though the recipients had to deal with this, and over time it all seems to have sorted itself out adequately. Regards Marshall
Groet,
MarcoH
On Tue, 18 Aug 2009, Marshall Eubanks wrote:
Some time ago, IPv4 filtering blocks longer than /20 was fairly common. In fact, when ARIN passed 2002-3 (its micro-assignment policy for multi-homed networks), that was still the case. While there was not a land-rush to claim smaller blocks, there was adoption even though the recipients had to deal with this, and over time it all seems to have sorted itself out adequately.
The /20 filtering mentioned was probably for ARIN blocks then, because it wasn't a general practice as I've experience with /24 in RIPE space since 1995-1996 or so and it wasn't a problem back then and is not now. -- Mikael Abrahamsson email: swmike@swm.pp.se
Marshall Eubanks wrote:
On Aug 18, 2009, at 5:50 AM, Marco Hogewoning wrote:
On 29 jul 2009, at 21:22, Andy Davidson wrote:
On 25 Jul 2009, at 22:57, Nick Hilliard wrote:
[...]
... - the rule should allow requests for a /24 to be the minimum size for announcement on the Internet, but if networks are not planning to announce the prefix via bgp (e.g. non-announced loopback ranges), then they should be allowed to request a smaller range.[...]
Why would anyone opt for the possibility to get *less* address space? Essentially, in my personal opinion, supporting this proposal is like suggesting to go back to the classful, pre-CIDR times through the backdoor. How would a LIR argue opposite a customer asking for a /24 from PA space when the need is only good for a, say, /26 PA, when the customer can get a /24 PI for (the proposed, flat) € 50,- per year? Probably for much less, if the customer's negotiation skills are just a tad above minimum ;-) Wilfried. PS: one group in my Org has been in this problem space just recently, and still I do NOT support the proposal, as the manager for our LIR ;-)
On 20/08/2009 10:17, Wilfried Woeber, UniVie/ACOnet wrote:
How would a LIR argue opposite a customer asking for a /24 from PA space when the need is only good for a, say, /26 PA, when the customer can get a /24 PI for (the proposed, flat) € 50,- per year? Probably for much less, if the customer's negotiation skills are just a tad above minimum ;-)
Wilfried, I'm not proposing that minimum blocks of /24 be handed out like interior extras by a car salesman, but rather that there should be some mechanism where they can be assigned in the specific case where the customer has a demonstrable requirement to multi-home their network, and where becoming a LIR is too heavyweight for their requirements, and/or would waste 7 x /24 from a /21 allocation. There is a significant and clear-cut difference between the two situations here: the one is a grossly irresponsible and cavalier attitude to dealing with addressing requirements; the other is a sensible method of dealing responsibly with a legitimate end-user need.
PS: one group in my Org has been in this problem space just recently, and still I do NOT support the proposal, as the manager for our LIR
Good for you. Have you looked at the problem from the end-user viewpoint? I find it to be rather murkier than the LIR outlook. Nick
On Aug 18, 2009, at 2:50 AM, Marco Hogewoning <marcoh@marcoh.net> wrote:
On 29 jul 2009, at 21:22, Andy Davidson wrote:
On 25 Jul 2009, at 22:57, Nick Hilliard wrote:
However, I don't think we should mandate that /24 be the minimum assignment size - the rule should allow requests for a /24 to be the minimum size for announcement on the Internet, but if networks are not planning to announce the prefix via bgp (e.g. non-announced loopback ranges), then they should be allowed to request a smaller range. But as you say if we do mandate this the effect is trivial.
The question remains what to do when "the internet" - or some part of it - decide to filter on /23. Do we modify the policy again to make /23 the minimum ? Are we going to allow people to hand in their original /24 assignment and grow it to /23 ?
FWIW, the trend seems to be in the other direction. /25 looks a lot more likely than /23.
-Scott
On Sat, Jul 25, 2009 at 09:29:19PM +0200, Per Heldal wrote:
On Sat, 25 Jul 2009 17:12:45 +0100 Nick Hilliard <nick@inex.ie> wrote:
Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy.
RIR policies is not the right tool to regulate ISP behaviour.
right or wrong, its a fact of life. most ISPs set their filters based on the RIR min-allocation.
Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets.
//per
Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy.
RIR policies is not the right tool to regulate ISP behaviour.
And RIR policies do NOT regulate anything. Your comment is not relevant to the suggestion (above) that RIPE needs to meet the needs of that segment of the IP address user community that needs to have IP addressing independent of their ISP.
Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets.
There is no point in discussing such things here since RIPE has nothing to do with regulators. --Michael Dillon
On Mon, 27 Jul 2009 10:54:35 +0100 <michael.dillon@bt.com> wrote:
Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy.
RIR policies is not the right tool to regulate ISP behaviour.
And RIR policies do NOT regulate anything.
They shouldn't. I did however misinterpret a previous comment in the thread to be about liberalisation of PI-policy. I don't want RIPE to hand out smaller blocks, which was the basis for my arguments. I've re-read the proposal, and I do agree that RIPE should not hand out blocks smaller than what is defined as the minimum assignment. Handing out blocks smaller than what is permitted through general filtering recommendations makes no sense. Sorry for the confusion. //per
Hi, On Mon, Jul 27, 2009 at 12:56:14PM +0200, Per Heldal wrote:
I've re-read the proposal, and I do agree that RIPE should not hand out blocks smaller than what is defined as the minimum assignment.
They don't. The defined minimum assignment size for IPv4 PI is a /32.
Handing out blocks smaller than what is permitted through general filtering recommendations makes no sense. Sorry for the confusion.
Now there's the catch: who defines what is "permitted" on the Internet? If we could get a clear document from the Internet Routing Police, we could tie the policy to that... 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
Gert Doering wrote:
Hi,
On Mon, Jul 27, 2009 at 12:56:14PM +0200, Per Heldal wrote:
I've re-read the proposal, and I do agree that RIPE should not hand out blocks smaller than what is defined as the minimum assignment.
They don't. The defined minimum assignment size for IPv4 PI is a /32.
Handing out blocks smaller than what is permitted through general filtering recommendations makes no sense. Sorry for the confusion.
Now there's the catch: who defines what is "permitted" on the Internet?
If we could get a clear document from the Internet Routing Police, we could tie the policy to that...
The trick here though is that IP addresses are not only used on the Internet. Especially in the case of PI it is perfectly useful and IMHO a valid request case to request address space for interconnecting non-Internet connected resources. As such, a request that does not match to those IRP rules (aka the perceived current of a minimum of a /24) are definitely valid and should be accepted by RIPE. Then again, there is always the assumption that something will at one point appear on the Internets... Greets, Jeroen -- Btw: $ whois routingpolice.net No match for "ROUTINGPOLICE.NET". For all those domain-grabbers :)
On Tue, 28 Jul 2009 10:36:21 +0200 Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Jul 27, 2009 at 12:56:14PM +0200, Per Heldal wrote:
I've re-read the proposal, and I do agree that RIPE should not hand out blocks smaller than what is defined as the minimum assignment.
They don't. The defined minimum assignment size for IPv4 PI is a /32.
Handing out blocks smaller than what is permitted through general filtering recommendations makes no sense. Sorry for the confusion.
Now there's the catch: who defines what is "permitted" on the Internet?
You know, as well as I, that no-one does, but that common operational practises puts a practical limit at /24. I would not work with anything smaller, or recommend anyone else to do so. I'd take PA over PI</24 any day. That there is no formal "routing police" doesn't prevent a lot of people from making their own rules. That is a natural consequence of the fact that the internet is a collection of interconnected private networks, which owners have sovereign rights to decide how their resources is used. The "public" internet is an illusion. Wrt the policy in question, I support the view that handing out blocks < /24 is in fact waste of addresses, as the usability of such block is questionable. At the same time, I do not want to make it easier to get a /24 than it already is. That is if the intent is to make anyone who "qualify" for example for a /28 eligible for a /24. This is as I've stated multiple times before a problem that should be solved elsewhere. //per
Hi, On Sat, Jul 25, 2009 at 09:29:19PM +0200, Per Heldal wrote:
Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets.
Be careful with your wishes. "IP number portability", prescribed by the regulation authorities, would be the end of the Internet routing as we know it. Gert Doering -- APWG -- 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
Be careful with your wishes. "IP number portability", prescribed by the regulation authorities, would be the end of the Internet routing as we know it.
It's ok, we can just do this all in the LISP-ALT! ;)
On Tue, Jul 28, 2009 at 10:30:41AM +0200, Gert Doering wrote:
Hi,
On Sat, Jul 25, 2009 at 09:29:19PM +0200, Per Heldal wrote:
Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets.
Be careful with your wishes. "IP number portability", prescribed by the regulation authorities, would be the end of the Internet routing as we know it.
Gert Doering -- APWG
of course internet routing as we know it is doomed anyway, so why not do number portability? --bill
On Tue, 28 Jul 2009 10:30:41 +0200 Gert Doering <gert@space.net> wrote:
Hi,
Be careful with your wishes. "IP number portability", prescribed by the regulation authorities, would be the end of the Internet routing as we know it.
Once again: I've been been around more than long enough to know that "IP number portability" is rubbish, and I apologise if my statement was interpreted that way. I was however hinting towards a comparison of DNS-records and phone-numbers wrt portability. Hence my suggestion that market regulators may want to look at the ways in which ISP's and others hijack DNS records, and otherwise makes it much harder than it has to be to move from one IP-block to another. Micro PI blocks should really have been a no-issue by now. Note also that ARIN limits PI to /22, although it's recently been discussed to liberalise to /24. //per
participants (22)
-
Andy Davidson -
bmanning＠vacation.karoshi.com -
David Freedman -
Gert Doering -
Greg -
Jeffrey A. Williams -
Jeroen Massar -
Jeroen Wunnink -
Jim Reid -
Leo Vegoda -
Marco Hogewoning -
Marshall Eubanks -
Masataka Ohta -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Nick Hilliard -
niels=apwg＠bakker.net -
Nolan, Keith -
Per Heldal -
Scott Leibrand -
Stream Service || Mark Scholten -
Wilfried Woeber, UniVie/ACOnet