Re: how 200 /48's fails the job
Pekka Savola <pekkas@netcore.fi> writes:
On Tue, 5 Apr 2005 Michael.Dillon@radianz.com wrote: ...
The 200 new customer limit was meant to be a measure of largeness and seriousness. I think that in today's world, that measure fails to do the job.
Could you clarify, why do you think "200 customers" fails as a meter for largeness ?
There are some odder cases like transit only ISPs (which technically could only have very few direct organizational customers -- let's assume that those would get the IP space using some other provisions or as a matter of interpretation), but apart from that, why exactly is requiring 200 customers unreasonable?
I think Mr. Bartels already made some of these points, but I'll still add my two (euro)cents to this discussion. I would think that the concept of lumping all "customers" into a single class is flawed. I work for a managed hosting provider, and we currently have POPs in three countries with multiple transit providers and peerings. Obviously we have our own IPv4 allocation. However, our focus is on medium-size and large customers, which are quite unlike residential end-user customers where 200 would be next to nothing. I doubt we'll have 200 such customers (without creative accounting, that is) in a while yet, but we are still doing active business. The current rule effectively prevents us from deploying IPv6 to our customers. In the long run, I believe that as long as the current policy prevents hosting companies who serve content to end-users from deploying IPv6, it removes motivation from the end-user ISPs (who would have no problem getting the allocation) to actually deploy it to their users. While routing table growth is a concern, not having (v6) routing table growth is in my opinion an even larger concern. Therefore my view is that the arbitrary fixed criterion of having to be "large" (for whatever value of large) for a v6 allocation should be dispensed with. -- Valtteri Vuorikoski <vuori@magenta.net> MagentaSites Oy
However, our focus is on medium-size and large customers, which are quite unlike residential end-user customers where 200 would be next to nothing. I doubt we'll have 200 such customers (without creative accounting, that is) in a while yet, but we are still doing active business. The current rule effectively prevents us from deploying IPv6 to our customers.
I think that the current rule puts RIPE in violation of the EU guidelines on horizontal cooperation agreements. http://europa.eu.int/scadplus/leg/en/lvb/l26062.htm In particular, I believe that it is an unfair limitation of ouput. Of course, I am not a lawyer, but nevertheless, the 200 limitation seems rather dodgy and artificial. I realize that RIPE serves more than just the EU but I think that even in Russia, central Asia and the middle East, there are similar competition laws. As policymakers, we have to be concerned with the legal environment around us, and therefore this limit must be removed. From an engineering viewpoint there is no clear justification for this limit. In all the discussion to date the only thing that seems to have solid engineering justification is that IPv6 /32 addresses cannot be handed out to everyone who wants one. There must be some technical justification for the request, such as the plan to run an IPv6 network that internetworks at least two IPv6 networks. In most cases these two or more networks can be distinguished by being physically disjoint, i.e. two separate buildings or cities. But Internet exchanges and large hosting facilities are in a single location but they are clearly internetworks from the engineering point of view. So if we want a policy that includes a limitation based on real engineering, how do we word it? And how do we ensure that the terms we use are clearly defined. In the past, many such policies have use very ill-defined and vague terminology that often conflicts with the normal English usage of words. Is there a way to define an IPv6 internetwork so that the policy gives clear guidance to RIPE hostmasters but does not fall afoul of EU competition rules?
While routing table growth is a concern, not having (v6) routing table growth is in my opinion an even larger concern. Therefore my view is that the arbitrary fixed criterion of having to be "large" (for whatever value of large) for a v6 allocation should be dispensed with.
I really think that the original makers of the policy were not trying to define "large" but were trying to find a way to define an internetwork as distinct from an end site. If we look at the IPv6 Internet as a hierarchy with large high-bandwidth international networks near the root and individual offices at the leaves, then we can see that leaves have a single connection but all other nodes in the hierarchy have two or three or more connections. All the non-leaf nodes are internetworks. The natural processes of corporate growth and consolidation will limit the number of non-leaf nodes in this hierarchy so that it will form some type of flat pyramid. These same mechanisms limit the growth of the global routing table and therefore I feel confident that giving out a /32 to any internetwork with plans to deploy IPv6 will not create a routing table crisis. It would be nice if RIPE could find some university to do a study of the network economy to understand this hierarchy better and give us the information to predict the future number of nodes in the hierarchy. I will note that Merit in the USA recently got a graduate student to do an analysis of questionnaires from several years of NANOG meetings. It's not network engineering but this kind of research is still very useful to policymakers. --Michael Dillon
On 7-apr-05, at 15:29, Michael.Dillon@radianz.com wrote:
I am not a lawyer
[...]
As policymakers, we have to be concerned with the legal environment around us, and therefore this limit must be removed.
This policy has been in use around the world for years and apparently nobody bothered to challenge it in court. So either nobody cares or the legality is just fine.
There must be some technical justification for the request, such as the plan to run an IPv6 network that internetworks at least two IPv6 networks.
[...]
I feel confident that giving out a /32 to any internetwork with plans to deploy IPv6 will not create a routing table crisis.
So being an internetwork gets you a /32, and you're an internetwork if you (inter)connect at least two "IPv6 networks". Care to define "IPv6 network"? Would that be another organization (so 200 becomes 2)? Or just a subnet (so 200 becomes 0)? The trouble with all of this is that if we lower the bar so entities that we all feel should be able to have their own prefix can get one, this immediately opens the door for a whole bunch of other people who shouldn't. For instance, we've seen some messages from different LINX people. Apparently they have a number of projects (the number being smaller than 200) that require IPv6 addresses and they would like to assign those addresses from a prefix of their own. Since internet exchanges already get a prefix for the exchange fabric it seems reasonable to give them a larger prefix than just one for the exchange fabric so they can accommodate these other assignments as well as their own stuff from this same prefix. But what qualifies as an "internet exchange"? There are already many "internet exchanges" with members that can be comfortably counted on the fingers of one hand. So rather than just remove the 200 limit and brag that we're so good at predicting the future that this will NEVER pose a problem, it would be good to come up with something that's actually BETTER than the current policy. I'm still waiting for examples of PA requests that were turned down but, in our collective opinion, shouldn't have, BTW. I was thinking about simply reusing the IPv6 policies and requiring applicants to show the need for a certain number of addresses. But the problem is that with IPv6 you can renumber thousands of hosts with a couple of lines of router configuration. What is exactly the circumstance that makes the difference between getting PA space from an ISP being just inconvenient, and being too problematic to reasonably ask people to do so?
--On 07 April 2005 15:59 +0200 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
I'm still waiting for examples of PA requests that were turned down but, in our collective opinion, shouldn't have, BTW.
For what reason? If we dive into specifics, all we will end up doing is "legislating" for (and wasting time over) corner cases. Maybe there aren't any requests which have been rejected, because most people who would be at risk of being turned down either, read the initial allocation criteria, and either: a) Realise they won't make the "200 number", don't bother applying, or, b) Realise they won't make the "200 number", fabricate/lie/whatever on their application and get the /32. Can the NCC help by supplying some general statistics on IPv6 allocations (such as number rejected, and for what reason)? I seem to recall that we only seem to hear about successful allocations made in the NCC reports. The number of rejections would probably make far more interesting reading/viewing. I think we had a show of hands in Manchester along similar lines, showing that there was some frustrated demand from networks which clearly weren't end sites but were also not prepared to fabricate their v6 requests. Maybe this will help us better understand the scale of the "problem". Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"
Hi Mike, On Apr 7, 2005, at 11:35 am, Mike Hughes wrote: [...]
Can the NCC help by supplying some general statistics on IPv6 allocations (such as number rejected, and for what reason)?
I seem to recall that we only seem to hear about successful allocations made in the NCC reports. The number of rejections would probably make far more interesting reading/viewing.
We are working on producing some statistics along these lines. If you'd like, I can prepare a presentation for RIPE 50 in May. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC
This policy has been in use around the world for years and apparently nobody bothered to challenge it in court. So either nobody cares or the legality is just fine.
Perhaps it means that nobody cares yet. On the other hand, we have a proposed change to the policy and two people on the list today have mentioned that they know cases in which this policy has actually created a commercial problem. So perhaps it means that the people who care are willing to work within the RIPE policy process first. Also, I believe that it puts them in a stronger position to win a lawsuit if they can show that they did try to resolve the problem outside the courts first.
So being an internetwork gets you a /32, and you're an internetwork if you (inter)connect at least two "IPv6 networks".
Care to define "IPv6 network"?
I think we can leverage the existing rules for allocating a /48 and say that a /48 allocation is an IPv6 network. Or, more precisely, an IPv6 network is a network which meets the requirements for a /48 allocation. Those requirements are defined elsewhere.
The trouble with all of this is that if we lower the bar so entities that we all feel should be able to have their own prefix can get one, this immediately opens the door for a whole bunch of other people who shouldn't.
Policies are rarely 100% perfect. If we can make this one better than it was, then we have succeeded. If future experience shows that there are a whole bunch of /32 allocations going to people who shouldn't get them, then we can change the policy at that time, when we have the benefit of greater knowledge.
Since internet exchanges already get a prefix for the exchange fabric it seems reasonable to give them a larger prefix than just one for the exchange fabric so they can accommodate these other assignments as well as their own stuff from this same prefix.
It does not seem reasonable to me. I don't like to see the policy behaviour dependent on business models. If a company has a business model that includes internet exchange and something else, then I think we should be prepared to deal with both aspects of the business seperately. We treat internet exchanges as special cases so if the same company wants to do other business then they really should not use the same allocation for the other business.
But what qualifies as an "internet exchange"? There are already many "internet exchanges" with members that can be comfortably counted on the fingers of one hand.
So rather than just remove the 200 limit and brag that we're so good at predicting the future that this will NEVER pose a problem, it would be good to come up with something that's actually BETTER than the current policy.
If we can come up with something a LOT better, that is good. But if we cannot come up with something a lot better then we should make things a little bit better by removing the 200 limit. Internet exchanges are IPv6 interconnection points that allow companies to exchange traffic locally to avoid tromboning it out of the local area and back again. If an exchange has 4 members but achieves this "path shortening" then it is an exchange.
I was thinking about simply reusing the IPv6 policies and requiring applicants to show the need for a certain number of addresses. But the problem is that with IPv6 you can renumber thousands of hosts with a couple of lines of router configuration.
You make a good case here for removing the 200 limit. If, at a future time, we find that there are too many /32s and we need to de-list some of the allocations, then the affected operators can easily renumber as you have pointed out. --Michael Dillon
participants (5)
-
Iljitsch van Beijnum -
leo vegoda -
Michael.Dillon＠radianz.com -
Mike Hughes -
Valtteri Vuorikoski