IPv6 PI resource question - Not for ISP but hosting
Hi All, I've been following the previous thread concerning IPv6 PI assignment but I'm running into a special case and need your input. As a LIR, I did send an IPv6 PI request for one of our customers few days ago and the hostmaster did point me to this previous thread saying that we are in the same case and that he may reject this request. The company requesting the IPv6 PI is a hosting company providing software as a service solution for its customers. All the infrastructure (servers, routers...) is owned by them. For security reasons, they chose to isolate each of their customers on a separate VLAN. Their customer don't have administrative access to the servers and just uses the software hosted on them for their CRM, extranet or other corporate applications. Would you consider this to be the exact same case as an ISP assigning an IP to a customer's CPE? I really don't see the point for such a company to become a LIR as they will only use those IPs for them. They also don't need more than a /48 as they are currently having about 50 customers. Regards, Mathieu Paonessa
Hi,
The company requesting the IPv6 PI is a hosting company providing software as a service solution for its customers. All the infrastructure (servers, routers...) is owned by them. For security reasons, they chose to isolate each of their customers on a separate VLAN. Their customer don't have administrative access to the servers and just uses the software hosted on them for their CRM, extranet or other corporate applications.
Would you consider this to be the exact same case as an ISP assigning an IP to a customer's CPE?
No. This all sounds like their own infrastructure/network/equipment. That they run software for customers, and that they choose a certain numbering plan shouldn't make a difference here. When they provide network services to their customer it starts to become more complicated, but this doesn't sound like a problem for IPv6 PI space to me. (based on the given information of course. I'm not trying to tell an IPRA what to do... They might have based their evaluation on different information) But the way you describe it it does not sound like they assign address space to other organizations. It sounds like they assign address space to parts of their own server farm. But this is my personal interpretation of the current policy. If someone disagrees with this, please speak up! Sander
Sander, I agree with you on the interpretation. We are facing a similar situation where our customer is in the security business. They host several hundred alarm receivers currently on ipv4 pi space. This is all their own infrastructure and the reason for pi space is the requirement for global unique addressing on the alarm receivers since they are connected to both the Internet and many vpns. Being provider independent brings them the ability to dual home in the future without renumbering as well as switch ISP all together. However since they do not dual home at the moment under the current policy they cannot get ipv6 pi space. Pa space is not an option since over 120000 alarm senders deployed at their end customers nationally would have to be reprogrammed in case of a change in connectivity. Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy? Jasper ________________________________________ From: address-policy-wg-admin@ripe.net [address-policy-wg-admin@ripe.net] On Behalf Of Sander Steffann [sander@steffann.nl] Sent: Tuesday, February 15, 2011 6:04 PM To: Mathieu Paonessa Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting Hi,
The company requesting the IPv6 PI is a hosting company providing software as a service solution for its customers. All the infrastructure (servers, routers...) is owned by them. For security reasons, they chose to isolate each of their customers on a separate VLAN. Their customer don't have administrative access to the servers and just uses the software hosted on them for their CRM, extranet or other corporate applications.
Would you consider this to be the exact same case as an ISP assigning an IP to a customer's CPE?
No. This all sounds like their own infrastructure/network/equipment. That they run software for customers, and that they choose a certain numbering plan shouldn't make a difference here. When they provide network services to their customer it starts to become more complicated, but this doesn't sound like a problem for IPv6 PI space to me. (based on the given information of course. I'm not trying to tell an IPRA what to do... They might have based their evaluation on different information) But the way you describe it it does not sound like they assign address space to other organizations. It sounds like they assign address space to parts of their own server farm. But this is my personal interpretation of the current policy. If someone disagrees with this, please speak up! Sander Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
Hi,
Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy?
I don't know if this is a waranted use of PI space. The problem here is that the extra route has a global cost for everyone. This would not be neccesary if you make sure that you can easilly renumber in the future. Playing devil's advocate: why should everyone pay so that you don't have to invest in better device management? So I do understand your problem, but I don't know what the best sollution is... Sander
On Tue, Feb 15, 2011 at 08:34:47PM +0100, Sander Steffann wrote:
The problem here is that the extra route has a global cost for everyone.
Just as every LIR PA block is at the global cost of everyone. <rant mode="sarcasm"> But of course, LIRs are "special" so that cost isn't questioned as long as they pay their share to run the RIRs - /32, no questions asked (single homed? no problem. polluting the DFZ with a lot of deaggs - hey, not a biggie - connecting customers? sure, just throw them a /48). It's just those pesky customers who insubordinately ask for their independence and operational sanity just like the LIRs enjoy every day. We should really search for more artificial reasons to deny them PI space. We could e.g. ask for especially expensive routers deployed (and certificate of first ownership incl. invoice!) - that will make them shy away even more! Or we could ask for certified BGP engineers, just to save the DFZ from more deaggregate pollution. At least they shelled out money to buy themselves "in". </rant> No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take. SCNR, Daniel (having a bad day, tired of all the hypocrisy in that PI debate) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
The problem here is that the extra route has a global cost for everyone.
Just as every LIR PA block is at the global cost of everyone.
Correct. The idea is that one LIR PA block covers lots of customers. It's a matter of scalability... I would love to give every organization it's own block of addresses. If someone finds a way to make that scale please let us know.
No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take.
It certainly is not. A few years ago the was no IPv6 PI policy, and now we have one. It's not perfect, but it provides addresses for those that need them for multi-homing. At that point in time that was seen as the only valid reason for IPv6 PI. In this whole discussion about PI space I have seen several other reasons why people want PI space: - They already provide access services with IPv4 PI space According to the current policy they should become an LIR and get PA space. When we last discussed this here the conclusion was that this was intentional. The cost for setting up an LIR seem to be a problem for some here. - They want to avoid renumbering Preventing possible renumbering in the future has (until now at least) not been seen as a good enough reason to get PI addresses. IPv6 does make renumbering already a bit easier than it was with IPv6, and I really hope that more effort will be put into making it even easier. If we (=working group) decide that there should be IPv6 PI for these or other purposes, let's discuss that. This is a working group. If you want to see something changed: write a proposal and it will be discussed! Thanks, Sander
On Tue, Feb 15, 2011 at 09:42:04PM +0100, Sander Steffann wrote:
The problem here is that the extra route has a global cost for everyone.
Just as every LIR PA block is at the global cost of everyone.
Correct. The idea is that one LIR PA block covers lots of customers. It's a matter of scalability...
An "enterprise" becoming LIR to get their /32-no-questions-asked as effective PI doesn't aggregate any customers as well. With that argument, you have to avoid non-ISPs becoming LIRs as well.
No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take.
It certainly is not. A few years ago the was no IPv6 PI policy, and now we have one.
Yes, but why? Not to do customers a favour, but the LIRs realized that IPv6 migration won't really happen unless they give the relevant content players PI for their operations. Which induces a lot of operational headache and cost primarily on the ISP side. "Enterprises" are already used to NATting their day away - ISPs not. What I see coming is that ULA + NAT will be vast IPv6 reality. Thanks that the IPv6 end-to-end promise is killed off again via restrictive policies made by ISPs for ISPs.
- They already provide access services with IPv4 PI space According to the current policy they should become an LIR and get PA space.
So just "make them pay a penalty". They are not aggregating customers, so no good reason for PA other than artificial hurdle.
If we (=working group) decide that there should be IPv6 PI for these or other purposes, let's discuss that. This is a working group.
A working group with almost zero lobby for non-LIRs. Don't start fights you cannot win.
If you want to see something changed: write a proposal and it will be discussed!
Yes, between folks who have zero business interest for such a proposal to pass. See above - a fight you cannot win. Non-LIRs aren't organized enough to have any effective influence on RIR policy development process. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
What I see coming is that ULA + NAT will be vast IPv6 reality. Thanks that the IPv6 end-to-end promise is killed off again via restrictive policies made by ISPs for ISPs.
I'm sorry, but this working group is not restricted to ISPs. It's open for *everyone*.
- They already provide access services with IPv4 PI space According to the current policy they should become an LIR and get PA space.
So just "make them pay a penalty". They are not aggregating customers, so no good reason for PA other than artificial hurdle.
??? This situation is _all_ about aggregating customers...
If we (=working group) decide that there should be IPv6 PI for these or other purposes, let's discuss that. This is a working group.
A working group with almost zero lobby for non-LIRs. Don't start fights you cannot win.
The is no lobby. There is no such thing here as 'a fight you cannot win'. The only reason that a proposal doesn't reach consensus is when not enough people care, or if there are good arguments against the proposal. Please get non-LIRs to participate here to form a workable solution. You seem to propose PI space as a solution, someone suggested LISP as a solution, let's see what is a workable solution for everybody involved. (Yes: everybody, both ISPs and Enterprises)
If you want to see something changed: write a proposal and it will be discussed!
Yes, between folks who have zero business interest for such a proposal to pass. See above - a fight you cannot win.
Non-LIRs aren't organized enough to have any effective influence on RIR policy development process.
Nobody here is 'organized'. Everybody speaks for him/herself here. This working group consists of people, not organizations... Sander
* Sander Steffann:
I don't know if this is a waranted use of PI space. The problem here is that the extra route has a global cost for everyone.
This is an extremely short-sighted viewpoint. More routing table entries enable finer-grained routing decisions. In many cases, this leads to improvements according to some cost metric. There are isolated inefficiencies, but you cannot remove them without decreasing overall performance. Isn't BGP UPDATE rate more of an issue than the table size these days, anyway? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Hi Florian,
I don't know if this is a waranted use of PI space. The problem here is that the extra route has a global cost for everyone.
This is an extremely short-sighted viewpoint.
More routing table entries enable finer-grained routing decisions. In many cases, this leads to improvements according to some cost metric. There are isolated inefficiencies, but you cannot remove them without decreasing overall performance.
Isn't BGP UPDATE rate more of an issue than the table size these days, anyway?
If the people in the working group feel that routing table size is not as important anymore as it was a few years ago it might be possible to relax the policy about IPv6 PI space. It doesn't solve the problem that access providers that run on IPv4 PI space can't run on IPv6 PI space. These seem to be two separate issues. Thanks, Sander
* Sander Steffann:
If the people in the working group feel that routing table size is not as important anymore as it was a few years ago it might be possible to relax the policy about IPv6 PI space.
As one data point, it is a total non-issue for the technology we use. We probably can't process an IPv6 routing table which carries as much information as the IPv4 routing table today, but we are ready to adopt. (We're certainly not representative, but you've got to start somewhere.)
It doesn't solve the problem that access providers that run on IPv4 PI space can't run on IPv6 PI space. These seem to be two separate issues.
Not really. If LIRs could hand out independently routable /48 chunks of their PA space, then those folks wouldn't need PI space at all. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
It doesn't solve the problem that access providers that run on IPv4 PI space can't run on IPv6 PI space. These seem to be two separate issues.
Not really. If LIRs could hand out independently routable /48 chunks of their PA space, then those folks wouldn't need PI space at all.
So that hits the nail right on the head. We're trying to change address policy because we don't like accepted routing policy. This is what RFC1925 says about a construct like this: (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. So I'm not sure that's the right idea. If you don't like routing policy, change routing policy. (On a semi-related note, nobody likes paying money. If for some reason policy is adopted where some ISPs can get "low cost" address space for whatever reason, that means other people end up paying more for theirs. Previous experience learns us that more policy means executing policy gets more expensive. ) Remco, no hats. 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, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
Hi Jasper,
I agree with you on the interpretation. We are facing a similar situation where our customer is in the security business. They host several hundred alarm receivers currently on ipv4 pi space. This is all their own infrastructure and the reason for pi space is the requirement for global unique addressing on the alarm receivers since they are connected to both the Internet and many vpns. Being provider independent brings them the ability to dual home in the future without renumbering as well as switch ISP all together. However since they do not dual home at the moment under the current policy they cannot get ipv6 pi space. Pa space is not an option since over 120000 alarm senders deployed at their end customers nationally would have to be reprogrammed in case of a change in connectivity.
Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy?
Your case is not really like ours. Even if for your customer it would make sense to have IPv6 PI space (IMHO), the current policy doesn't allow it since he is not currently multihomed. It's up to this working group to make it evolve or not. In our case, the customer is already multihomed on his IPv4 space and they will also be dual homed for their IPv6 space. It's just a question of interpretation of who is the ultimate owner of the IPs. Regards, Mathieu
Hi jasper,
I agree with you on the interpretation. We are facing a similar situation where our customer is in the security business. They host several hundred alarm receivers currently on ipv4 pi space. This is all their own infrastructure and the reason for pi space is the requirement for global unique addressing on the alarm receivers since they are connected to both the Internet and many vpns. Being provider independent brings them the ability to dual home in the future without renumbering as well as switch ISP all together. However since they do not dual home at the moment under the current policy they cannot get ipv6 pi space. Pa space is not an option since over 120000 alarm senders deployed at their end customers nationally would have to be reprogrammed in case of a change in connectivity.
Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy?
Your case is not really like ours. Even if for your customer it would make sense to have IPv6 PI space (IMHO), the current policy doesn't allow it since he is not currently multihomed. It's up to this working group to make it evolve or not. In our case, the customer is already multihomed on his IPv4 space and they will also be dual homed for their IPv6 space. It's just a question of interpretation of who is the ultimate owner of the IPs. Regards, Mathieu
On 2/15/11 6:04 PM, Sander Steffann wrote:
No. This all sounds like their own infrastructure/network/equipment. That they run software for customers, and that they choose a certain numbering plan shouldn't make a difference here. When they provide network services to their customer it starts to become more complicated, but this doesn't sound like a problem for IPv6 PI space to me. (based on the given information of course. I'm not trying to tell an IPRA what to do... They might have based their evaluation on different information)
But the way you describe it it does not sound like they assign address space to other organizations. It sounds like they assign address space to parts of their own server farm.
But this is my personal interpretation of the current policy. If someone disagrees with this, please speak up!
The request finally got rejected because the IPRA considered that this was a sub-allocation. They encouraged our customer to become a LIR (which they clearly don't want to) or get a PA from us and then deaggregate it over BGP (which we clearly don't want to). If this community wants IPv6 to be more deployed, we really need to have this policy evolved. Mathieu
On Thu, Feb 17, 2011 at 4:09 AM, Mathieu Paonessa <matoa-ml@vayu.net> wrote:
If this community wants IPv6 to be more deployed, we really need to have this policy evolved.
Mathieu
Write a proposal :) Regards, Martin
participants (8)
-
Daniel Roesen -
Florian Weimer -
Jasper Jans -
Martin Millnert -
Mathieu Paonessa -
Mathieu Paonessa -
Remco Van Mook -
Sander Steffann