From memsvcs at arin.net Thu Feb 5 17:05:54 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 5 Feb 2004 17:05:54 -0500 (EST) Subject: [ppml] Deadline for Policy Proposals Message-ID: <200402052205.RAA20876@ops.arin.net> The next ARIN Public Policy Meeting will occur on April 19-20 in Vancouver, Canada. New policy proposals must be submitted on or before February 19th in order to be considered for the April meeting. This is in accordance with ARIN's Internet Resource Policy Evaluation Process which indicates that policy proposals must be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN Internet resource policies or modifications to existing ARIN Internet resource policies must submit a completed Policy Proposal Template. The template must be submitted via email to policy at arin.net. The following is a link to the ARIN Internet Resource Policy Evaluation Process: http://www.arin.net/policy/ipep.html And here is a link directly to the Policy Proposal Template: http://www.arin.net/policy/irpep_template.html Member Services American Registry for Internet Numbers (ARIN) From Michael.Dillon at radianz.com Fri Feb 6 09:36:48 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 6 Feb 2004 14:36:48 +0000 Subject: [ppml] Host-Density Ratio Message-ID: In a few days I will be submitting a formal proposal for a policy which adopts the host-density ratio for IPv4 allocations to replace the current fixed 80% utilization rate. At the last meeting, there was a lot of confusion over the meaning and complexity of the H-D ratio and I hope to clarify things much more this time, both before and during the meeting. In any case, I welcome comments on my proposed wording for the policy which is slightly changed from last time. 1. All requests for additional IPv4 address space shall require the efficient utilization of the sum total of all existing allocations including all space reassigned to customers, if any. 2. The HD(Host Density) ratio of the sum total of all previous allocations shall be greater than or equal to .966 and the HD ratio of the most recent allocation shall be greater than or equal to .930 in order to receive additional space. 3. The HD ratio is calculated as log10(utilized IPv4 addresses)/log10(total addresses in all previous allocations). In this formula, log10 refers to the base 10 logarithm. Rather than go into detailed explanations at this point, I will just give you three URLs that explain the concepts in a lot more detail Original IPv6 idea http://www.faqs.org/rfcs/rfc3194.html Paul Wilson's APNIC proposal http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and his APNIC 16 presentation http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf At the APNIC policy meeting there was a consensus in favor of the HD ratio but people felt it should be discussed more broadly, both in other RIR regions and within the APNIC countries. In particular, I am considering dropping point number 1 since it is supposed to be already part of the IPv4 policy. Personally, I think that adding in "the sum total" makes the statement more explicit than the existing one, but I could be convinced that it is unnecessary. Point 3 seems to be rather straightforward and uncontroversial That leaves point number 2. Does anyone see any flaws in this? --Michael Dillon ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Scott.Shackelford at cox.com Fri Feb 6 10:03:34 2004 From: Scott.Shackelford at cox.com (Scott.Shackelford at cox.com) Date: Fri, 6 Feb 2004 10:03:34 -0500 Subject: [ppml] Host-Density Ratio Message-ID: I think that it's a good idea inherently, however there's an element of caution that arises within me in that it seems the HD ratio could potentially allow for larger ISP/GSP, etc. to be more lax in their IP management. Any thoughts around this aspect? Regards, Scott Shackelford IP Engineer/IP Administrator Cox Communications 404-269-7312 Office -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Michael.Dillon at radianz.com Sent: Friday, February 06, 2004 9:37 AM To: ppml at arin.net Subject: [ppml] Host-Density Ratio In a few days I will be submitting a formal proposal for a policy which adopts the host-density ratio for IPv4 allocations to replace the current fixed 80% utilization rate. At the last meeting, there was a lot of confusion over the meaning and complexity of the H-D ratio and I hope to clarify things much more this time, both before and during the meeting. In any case, I welcome comments on my proposed wording for the policy which is slightly changed from last time. 1. All requests for additional IPv4 address space shall require the efficient utilization of the sum total of all existing allocations including all space reassigned to customers, if any. 2. The HD(Host Density) ratio of the sum total of all previous allocations shall be greater than or equal to .966 and the HD ratio of the most recent allocation shall be greater than or equal to .930 in order to receive additional space. 3. The HD ratio is calculated as log10(utilized IPv4 addresses)/log10(total addresses in all previous allocations). In this formula, log10 refers to the base 10 logarithm. Rather than go into detailed explanations at this point, I will just give you three URLs that explain the concepts in a lot more detail Original IPv6 idea http://www.faqs.org/rfcs/rfc3194.html Paul Wilson's APNIC proposal http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and his APNIC 16 presentation http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf At the APNIC policy meeting there was a consensus in favor of the HD ratio but people felt it should be discussed more broadly, both in other RIR regions and within the APNIC countries. In particular, I am considering dropping point number 1 since it is supposed to be already part of the IPv4 policy. Personally, I think that adding in "the sum total" makes the statement more explicit than the existing one, but I could be convinced that it is unnecessary. Point 3 seems to be rather straightforward and uncontroversial That leaves point number 2. Does anyone see any flaws in this? --Michael Dillon ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From Michael.Dillon at radianz.com Tue Feb 10 07:05:00 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 10 Feb 2004 12:05:00 +0000 Subject: [ppml] HD Ratio changes Message-ID: I've made some changes to the wording of the policy. First of all I've made the use of the HD Ratio optional. Secondly, I've decided to use the natural logarithm in the calculation because PERL has this and not the base 10 logarithm. The end result of the ratio calculation is identical, but now people will see that is clearly is easy to add the calculation to PERL IP address management systems. The Excel function LN(x) is the same as PERL's log(x). And lastly, I've pulled out the mention of reassignments since any definition of utilization belongs elsewhere and this was getting too close. 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. 2. All requests for additional IPv4 address space subject to the HD Ratio shall require the efficient utilization of the sum total of all existing allocations. The HD Ratio on the sum total of all existing allocations must be greater than or equal to .966. 3. In addition, the HD ratio of the most recent allocation must be greater than or equal to .930. 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From ibaker at codecutters.org Tue Feb 10 08:06:23 2004 From: ibaker at codecutters.org (Ian Baker) Date: Tue, 10 Feb 2004 13:06:23 -0000 Subject: [ppml] HD Ratio changes References: Message-ID: <02e701c3efd6$af314f30$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Tuesday, February 10, 2004 12:05 PM Subject: [ppml] HD Ratio changes > I've made some changes to the wording of the policy. First of all > I've made the use of the HD Ratio optional. Secondly, I've decided > to use the natural logarithm in the calculation because PERL has > this and not the base 10 logarithm. The end result of the ratio > calculation is identical, but now people will see that is clearly > is easy to add the calculation to PERL IP address management > systems. The Excel function LN(x) is the same as PERL's log(x). log10(x) = ln(x) / ln(10) The ratio will, of course, cancel-out the conversion factor. Incidentally, how were the ratio values derived? 31% utilization[1] before a /8 reallocation seems a bit low to me (just a gut feeling, you understand..!) Regards, Ian Baker Webmaster, codecutters.org 1. http://www.codecutters.org/temp/HD-Ratio.xls From cscott at gaslightmedia.com Tue Feb 10 08:38:01 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Tue, 10 Feb 2004 08:38:01 -0500 (EST) Subject: [ppml] HD Ratio changes In-Reply-To: Message-ID: Michael: When this last came up I questioned why HD Ratio should be applied to ISP allocations/assignments and received no responses. In fact, I even challenged the application of HD Ratio to end-user address space on the premise that the argument for HD Radio is based on the need to implement a strict hierarchical numbering scheme. With dynamic routing protocols it is not necessary to have a network hierarchically arranged strictly by numeric address--subnets can appear in networks to which they are not numerically related. The arguments for HD Ratio have used telephone number distribution as an example, but that is not a comparative model today (although number portability may convolute that). Frankly I see this as being parallel to encouraging end-users to use NAT in that the more they use it, the more they conserve address space. In that respect, the more people rely on dynamic routing to permit more flexible distribution of address space, the easier it is to manage address space and the more they can conserve (and the more they avoid the concerns driving HD Ratio). Regardless of the above, all of the references about the need for HD Ratio relate to end-user address assignment issues and don't seem to be relevant to allocating, or re-allocating (here we go with terminology again) blocks of addresses by ISP's. Frankly, I can't see how it would be relevant to that. I might be inclined to agree with the use of HD Ratio if it only applies to end user implementation of address space and not to address block assignment/allocation, and if I was convinced that the mitigating issues addressed above do not relieve the concerns. Otherwise, I'm, once again, concerned that this approach unnecessarily increases waste and complexity and in doing so provides questionable relief. Chuck Scott cscott at gaslightmedia.com On Tue, 10 Feb 2004 Michael.Dillon at radianz.com wrote: > I've made some changes to the wording of the policy. First of all > I've made the use of the HD Ratio optional. Secondly, I've decided > to use the natural logarithm in the calculation because PERL has > this and not the base 10 logarithm. The end result of the ratio > calculation is identical, but now people will see that is clearly > is easy to add the calculation to PERL IP address management > systems. The Excel function LN(x) is the same as PERL's log(x). > And lastly, I've pulled out the mention of reassignments since > any definition of utilization belongs elsewhere and this was > getting too close. > > 1. Anyone who has already been allocated 4096 IPv4 addresses or > more may choose to have additional requests for IPv4 addresses > evaluated using an HD (Host Density) Ratio calculation to determine > sufficient utilization instead of a fixed percentage threshold. > > 2. All requests for additional IPv4 address space subject to the HD > Ratio shall require the efficient utilization of the sum total of > all existing allocations. The HD Ratio on the sum total of all > existing allocations must be greater than or equal to .966. > > 3. In addition, the HD ratio of the most recent allocation must be > greater than or equal to .930. > > 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided > by log(total addresses in all previous allocations). In this formula, > log refers to the natural logarithm. > > ------------------------------------------------------- > Michael Dillon > Capacity Planning, Prescot St., London, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > From Michael.Dillon at radianz.com Tue Feb 10 09:23:04 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 10 Feb 2004 14:23:04 +0000 Subject: [ppml] HD Ratio changes Message-ID: > When this last came up I questioned why HD Ratio should be applied to >ISP allocations/assignments and received no responses. With respect, I did say then, and I say again, this is all detailed in the RFC for applying the HD Ratio to IPv6 and in Paul Wilson's discussion paper of last year. I admit that I made some mistakes and posted the wrong URL for one of those documents, but that has now been rectified. > In fact, I even >challenged the application of HD Ratio to end-user address space on the >premise that the argument for HD Radio is based on the need to implement a >strict hierarchical numbering scheme. With dynamic routing protocols it >is not necessary to have a network hierarchically arranged strictly by >numeric address--subnets can appear in networks to which they are not >numerically related. Not everyone can afford the routing table overhead that this entails. In fact, evading the use of hierarchy makes this non-scalable and therefore non-usable for larger networks. Hierarchy is the primary tool that we have for making complex networks scalable. This is a basic principle of physics that we cannot discard and that we ignore at our peril. The larger your network becomes the more important hierarchy becomes and the more overhead is consumed because of hierarchy. >In >that respect, the more people rely on dynamic routing to permit more >flexible distribution of address space, the easier it is to manage address >space and the more they can conserve (and the more they avoid the concerns >driving HD Ratio). We really cannot impose specific technical solutions as a matter of policy when there is no overriding policy goal to justify it. In this case, the overriding policy goal which justified the 80% utilization rate is gone. We no longer have a looming shortage of IPv4 addresses because our existing stock will last 20 years. We have a fully functional replacement for IPv4 which does not have the same addressing constraints. And the large population asian nations have shown that they will move towards the IPv6 solution rather than increasing pressure on the IPv4 address space. Since the overriding policy goals have now shifted, it is time to rationalize the policy to fit. > Regardless of the above, all of the references about the need for HD >Ratio relate to end-user address assignment issues and don't seem to be >relevant to allocating, or re-allocating (here we go with terminology >again) blocks of addresses by ISP's. Frankly, I can't see how it would be >relevant to that. The process of allocation, reallocation, and assignment divides a large address block into a larger number of smaller blocks. While it might be easy to get to 80% utilization of 1 large block, as we divide into smaller blocks we lose the effect of the law of large numbers. This means that some of the small blocks will reach 80% before others and we must start shifting addresses around robbing peter to pay paul. If there are several levels to this hierarcy of dividing, sub-dividing and sub-sub-diving, then we reach a point at which the time period represented by 20% (100%-80%) of an address pool is very short. That means that we could use up the 20% in a very short time because it is a fairly small amount. In order to maintain a reasonable time buffer we need to reserve more than 20% unused addresses from a /23 even though 20% might be sufficient from a /17. The cumulative impact of all these buffers adds up to more than 20% overall when you add up all the /23s in a /17. That's the hierarchical overhead. >I'm, once again, concerned that this approach unnecessarily increases waste >and complexity and in doing so provides questionable relief. This approach does not unnecessarily increase complexity because it is opt-in. If an organization is satisfied with the status quo they can continue as before. However, those organizations who need change can opt for the slightly more complex calculation if the benefits outweigh the added complexity. As for waste, I do not consider hierarchical overhead to be waste. This overhead is part of the structure of VLSM (Variable Length Subnet Masking) which is a fundamental part of any modern IPv4 network. If you have a subnet with 5 interfaces on it and you assign 8 addresses to that subnet then you are *NOT* wasting 3 addresses. Those 3 addresses are part of the inevitable overhead of VLSM (and CIDR). RFC 3194 http://www.faqs.org/rfcs/rfc3194.html Paul Wilson's discussion paper http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html Paul Wilson's slides http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf --Michael Dillon From cscott at gaslightmedia.com Tue Feb 10 15:59:40 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Tue, 10 Feb 2004 15:59:40 -0500 (EST) Subject: [ppml] HD Ratio changes In-Reply-To: Message-ID: Michael: Brief response to your comments... OK, not so brief. On Tue, 10 Feb 2004 Michael.Dillon at radianz.com wrote: > With respect, I did say then, and I say again, > this is all detailed in the RFC for applying > the HD Ratio to IPv6 and in Paul Wilson's > discussion paper of last year. I admit that I > made some mistakes and posted the wrong URL for > one of those documents, but that has now been > rectified. IPv6 provides opportunities that we can't necessarily afford with IPv4, which is perhaps why his paper relates to IPv6. > Not everyone can afford the routing table overhead that > this entails. In fact, evading the use of hierarchy > makes this non-scalable and therefore non-usable for > larger networks. Hierarchy is the primary tool that > we have for making complex networks scalable. This is > a basic principle of physics that we cannot discard and > that we ignore at our peril. The larger your network becomes > the more important hierarchy becomes and the more overhead > is consumed because of hierarchy. I did not mean to imply that people should intentionally design totally amorphous networks that have no rhyme or reason to the layout of IP addresses. However, it's my understanding that the HD ratio approach attempts to accommodate the added waste of having to set aside address space for exclusive numerically hierarchical deployment. If you start with a rational plan that accommodates the bulk of your network and achieves good internal routing aggregation, and then permit the use of other address space to be overlaid as necessary it would seem that the impact on your internal routing tables would be limited but you would not suffer from the issues that HD radio intend to address. > We really cannot impose specific technical solutions > as a matter of policy when there is no overriding policy > goal to justify it. In this case, the overriding policy > goal which justified the 80% utilization rate is gone. > We no longer have a looming shortage of IPv4 addresses > because our existing stock will last 20 years. We have > a fully functional replacement for IPv4 which does not > have the same addressing constraints. And the large population > asian nations have shown that they will move towards the > IPv6 solution rather than increasing pressure on the IPv4 > address space. Since the overriding policy goals have > now shifted, it is time to rationalize the policy to > fit. It should hardly be an imposition at this time to ask network managers to employ network routing such that it permits efficient deployment of IP space. Certainly we would not consider a network that does not support VLSM at this time as a valid excuse to deploy IP space in a wasteful manner. Since we're not talking about huge increases in router memory to accommodate another 10-20 percent address efficiency I don't think we're really talking about imposing much of a technical solution, particularly considering that it's the larger, likely better funded networks, that would most benefit from HD ratio anyway. If it is true that there is not now any concern for IPv4 address space then perhaps we should just relax the 80% to say 60% and make it easier for everyone. > The process of allocation, reallocation, and assignment > divides a large address block into a larger number of smaller > blocks. While it might be easy to get to 80% utilization > of 1 large block, as we divide into smaller blocks we > lose the effect of the law of large numbers. This means > that some of the small blocks will reach 80% before others > and we must start shifting addresses around robbing peter > to pay paul. If there are several levels to this hierarcy > of dividing, sub-dividing and sub-sub-diving, then we reach > a point at which the time period represented by 20% (100%-80%) > of an address pool is very short. That means that we could > use up the 20% in a very short time because it is a fairly > small amount. In order to maintain a reasonable time buffer > we need to reserve more than 20% unused addresses from a > /23 even though 20% might be sufficient from a /17. The > cumulative impact of all these buffers adds up to more than > 20% overall when you add up all the /23s in a /17. That's > the hierarchical overhead. I don't necessarily agree that your premise is appropriate for address allocation as opposed to address utilization. Regardless, the larger providers already receive larger chunks of address space and therefore their 20% is bigger. Also keep in mind this policy needs to be applied to those who manage address space for assignment to end users, not to end user space. End user space currently has considerably more relaxed standards of efficient utilization (50%). This is why I've said in the past that ISP's who both utilize as well as assign space should take the logical step of assigning the space they will internally utilize to themselves and show that as consumed from the total they have available for assignment. > This approach does not unnecessarily increase > complexity because it is opt-in. If an organization is > satisfied with the status quo they can continue as before. > However, those organizations who need change can opt for > the slightly more complex calculation if the benefits outweigh > the added complexity. > > As for waste, I do not consider hierarchical overhead > to be waste. This overhead is part of the structure of > VLSM (Variable Length Subnet Masking) which is a fundamental > part of any modern IPv4 network. If you have a subnet with 5 > interfaces on it and you assign 8 addresses to that subnet > then you are *NOT* wasting 3 addresses. Those 3 addresses > are part of the inevitable overhead of VLSM (and CIDR). Yes, but VLSM in itself does not relate to the efficiency of each subnet. VLSM simply means that each subnet can be sized according to the needs associated with it. Also, the subnets only need to comply with the 25%/50% utilization guidelines, so you could really make a subnet that has 5 active interfaces a /28 if you expect that you will be adding hosts to it in the future. You do know that the total sum of host interfaces on all networks of an assignment do not need to equal 80% of that assignment, right? Chuck Scott From owen at delong.com Tue Feb 10 17:15:04 2004 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Feb 2004 14:15:04 -0800 Subject: [ppml] HD Ratio changes In-Reply-To: References: Message-ID: <2147483647.1076422504@dhcp157-233.corp.tellme.com> OK... I took your mail, and tried to make this simple... I wrote the the attached PERL script to compute the number of hosts needed for a .996 HD ratio and the number of hosts needed for 80% utilization and came up with the following table. Either HD doesn't do what you claim, or, it isn't simple enough for me and my math didn't work right. The table here shows that in all cases, a .996 HD ratio is a larger number than the 80% requirement, and, that the more space you have, the worse it gets. I'm guessing I've got an error in my code, but, this is as easy as I thought it could be to compute the HD ratio needed for a given block size. If you have an easier way, please post code. +--------+-----------+-----------+-----------+---------------+ | Prefix | N Hosts | .996 HD | 80% HD | .996 HD - 80% | +--------+-----------+-----------+-----------+---------------+ | /3 | 536870912 | 495393603 | 429496729 | 65896873 | | /4 | 268435456 | 248384517 | 214748364 | 33636152 | | /5 | 134217728 | 124537069 | 107374182 | 17162886 | | /6 | 67108864 | 62441419 | 53687091 | 8754327 | | /7 | 33554432 | 31307393 | 26843545 | 4463847 | | /8 | 16777216 | 15697157 | 13421772 | 2275384 | | /9 | 8388608 | 7870369 | 6710886 | 1159482 | | /10 | 4194304 | 3946111 | 3355443 | 590667 | | /11 | 2097152 | 1978533 | 1677721 | 300811 | | /12 | 1048576 | 992013 | 838860 | 153152 | | /13 | 524288 | 497383 | 419430 | 77952 | | /14 | 262144 | 249383 | 209715 | 39667 | | /15 | 131072 | 125037 | 104857 | 20179 | | /16 | 65536 | 62693 | 52428 | 10264 | | /17 | 32768 | 31433 | 26214 | 5218 | | /18 | 16384 | 15761 | 13107 | 2653 | | /19 | 8192 | 7901 | 6553 | 1347 | | /20 | 4096 | 3961 | 3276 | 684 | | /21 | 2048 | 1987 | 1638 | 348 | | /22 | 1024 | 995 | 819 | 175 | | /23 | 512 | 499 | 409 | 89 | | /24 | 256 | 251 | 204 | 46 | | /25 | 128 | 125 | 102 | 22 | | /26 | 64 | 63 | 51 | 11 | | /27 | 32 | 31 | 25 | 5 | | /28 | 16 | 15 | 12 | 2 | | /29 | 8 | 7 | 6 | 0 | | /30 | 4 | 3 | 3 | 0 | | /31 | 2 | 1 | 1 | 0 | +--------+-----------+-----------+-----------+---------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: hdinfo.pl Type: application/perl-script Size: 885 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From arin at patrickgrosso.com Tue Feb 10 18:38:30 2004 From: arin at patrickgrosso.com (Patrick Grosso) Date: Tue, 10 Feb 2004 18:38:30 -0500 Subject: [ppml] HD Ratio changes In-Reply-To: Message-ID: <000e01c3f02f$0063de60$3e93a4ac@ws01> All, This is not a proposed addition to the policy, but rather a commentary on the issue. Please excuse me if I do not understand all of the intricacies. The HD Ratio Policy seems to be getting complicated. We should keep things SIMPLE. Especially since there will be newcomers to the ARIN policies that will need to learn how to adopt our practices in a short period of time. I prefer % utilization over a log function, because a log function will be prejudicially favorable to either the "small provider" or the "large provider" which ever way the function works. An IP address is an IP address, no matter who is allocating or assigning it. When I was requesting address space from ARIN under the web hosting policy, we only had to prove 80% utilization for our previous allocation. Efficient utilization of prior allocations was preferred but not necessary (and was not checked). Although we efficiently utilized that space, it is possible that other providers did not. Given that possibility, I pose these questions: Can it be said that the rediscovery and repair of previous allocations inefficiencies (or rather their inclusion towards current utilization rates) could prove more fruitful in the quest for IPv4 address space? If a new policy is ratified, will it only apply to new allocations? If so then we are only talking about a small scope of addresses (those that are "saved" from the remaining allocations to come (although I am not discounting this issue, because it is important as well). Conclusion Where I can see some technical limitations on reassigning past customer (churned) address space due to the way a network has be subnetted, I see no problem in efficiently reassigning those subnets under the web hosting policy (or dial, dsl, etc). I believe that better practices (of both ARIN and ISP) during the additional request process will provide a far greater gain. Practices that would include the (true) inclusion of previously allocated address space, and the more meticulous weeding out of 'ghost' reassignments (SWIP's of customers that are no longer there). Rather than rehash an existing policy, I think we should look elsewhere for NEW ways to extend the life of our IPv4 address space, both old and new. (And enforce those measures). Regards, Patrick Grosso -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Michael.Dillon at radianz.com Sent: Tuesday, February 10, 2004 7:05 AM To: ppml at arin.net Subject: [ppml] HD Ratio changes I've made some changes to the wording of the policy. First of all I've made the use of the HD Ratio optional. Secondly, I've decided to use the natural logarithm in the calculation because PERL has this and not the base 10 logarithm. The end result of the ratio calculation is identical, but now people will see that is clearly is easy to add the calculation to PERL IP address management systems. The Excel function LN(x) is the same as PERL's log(x). And lastly, I've pulled out the mention of reassignments since any definition of utilization belongs elsewhere and this was getting too close. 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. 2. All requests for additional IPv4 address space subject to the HD Ratio shall require the efficient utilization of the sum total of all existing allocations. The HD Ratio on the sum total of all existing allocations must be greater than or equal to .966. 3. In addition, the HD ratio of the most recent allocation must be greater than or equal to .930. 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From William at zanet.co.za Tue Feb 10 19:17:07 2004 From: William at zanet.co.za (William Stucke) Date: Wed, 11 Feb 2004 02:17:07 +0200 Subject: [ppml] HD Ratio changes In-Reply-To: <2147483647.1076422504@dhcp157-233.corp.tellme.com> Message-ID: Hi Owen, > or, it isn't simple enough for me and my math didn't work right It didn't work quite right ;-) All the numbers in your last (difference) column, except for the last two, are off by one, for example. In Owen's table, ignoring the last two values (/30 & /31), the .966 HD Ratio figure gives a number of hosts required on average 15.47% higher than the 80% figure, with a range from 12.27% (/3) to 18.75% (/28) However, see below. The Excel spreadsheet quoted by Ian Baker at http://www.codecutters.org/temp/HD-Ratio.xls makes the erroneous assumption that 254 out of every 256 addresses are available for any size block, when in fact it's 2 addresses (first and last) out of any size block that are unavailable. (His spreadsheet has a "*254/256" factor in the number of IP addresses column). He calculates it as: - (2^(32-CIDR))*254/256, whereas I believe if should simply be: - (2^(32-CIDR))-2, where CIDR is the number of bits in the prefix. Unless I misunderstand what's meant by what one author calls "N Hosts" and the other calls "IP Addresses", both are incorrect as they have used them - and are not equivalent. If the prefix length = CIDR is "n", then: - Number of IP addresses = 2^(32-n) [Which Owen called "Hosts"] Number of "useful" IP addresses = maximum possible Number of Hosts = 2^(32-n)-2 [Which Ian called "IP Addresses!] After that, the PERL script figures differ widely from the Excel numbers ... Here's a new table for you: (I didn't bother to round correctly, so figures might be off by 1) +------+-----------+-----------+-----------+-------------+---------+ |Prefix| N Hosts | .996 HD | 80% HD | .996 HD - 80| Percent | +------+-----------+-----------+-----------+-------------+---------+ | /3 |536,870,910|271,053,050|429,496,728| -158,443,678| -58.45%| | /4 |268,435,454|138,758,412|214,748,363| -75,989,951| -54.76%| | /5 |134,217,726| 71,033,685|107,374,181| -36,340,496| -51.16%| | /6 | 67,108,862| 36,363,809| 53,687,090| -17,323,281| -47.64%| | /7 | 33,554,430| 18,615,486| 26,843,544| -8,228,058| -44.20%| | /8 | 16,777,214| 9,529,704| 13,421,771| -3,892,067| -40.84%| | /9 | 8,388,606| 4,878,478| 6,710,885| -1,832,407| -37.56%| |/10 | 4,194,302| 2,497,407| 3,355,442| -858,035| -34.36%| |/11 | 2,097,150| 1,278,481| 1,677,720| -399,239| -31.23%| |/12 | 1,048,574| 654,484| 838,859| -184,375| -28.17%| |/13 | 524,286| 335,045| 419,429| -84,384| -25.19%| |/14 | 262,142| 171,517| 209,714| -38,197| -22.27%| |/15 | 131,070| 87,803| 104,856| -17,053| -19.42%| |/16 | 65,534| 44,948| 52,427| -7,479| -16.64%| |/17 | 32,766| 23,010| 26,213| -3,203| -13.92%| |/18 | 16,382| 11,779| 13,106| -1,327| -11.26%| |/19 | 8,190| 6,029| 6,552| -523| -8.67%| |/20 | 4,094| 3,086| 3,275| -189| -6.13%| |/21 | 2,046| 1,579| 1,637| -58| -3.66%| |/22 | 1,022| 808| 818| -10| -1.19%| |/23 | 510| 413| 408| 5| 1.21%| |/24 | 254| 211| 203| 8| 3.70%| |/25 | 126| 107| 101| 6| 5.79%| |/26 | 62| 54| 50| 4| 8.15%| |/27 | 30| 27| 24| 3| 11.11%| |/28 | 14| 13| 11| 2| 13.85%| |/29 | 6| 6| 5| 1| 20.00%| |/30 | 2| 2| 2| 0| 20.00%| +------+-----------+-----------+-----------+-------------+---------+ > The table here shows that in all cases, a .996 HD ratio is a larger number than the 80% requirement, and, that the more space you have, the worse it gets. Different numbers allow one to draw very different conclusions! The HD method requires far FEWER hosts for larger networks, as expected, but more hosts for networks smaller than a /23 - up to 20% more. I'm going to bed, it's after 2 am here! Regards, William Stucke ZAnet Internet Services (Pty) Ltd +27 11 465 0700 William at zanet.co.za From adb at onramp.ca Tue Feb 10 19:58:29 2004 From: adb at onramp.ca (Anthony DeBoer) Date: Tue, 10 Feb 2004 19:58:29 -0500 Subject: [ppml] HD Ratio changes In-Reply-To: ; from William@zanet.co.za on Wed, Feb 11, 2004 at 02:17:07AM +0200 References: <2147483647.1076422504@dhcp157-233.corp.tellme.com> Message-ID: <20040210195829.H32741@onramp.ca> William Stucke wrote: > The Excel spreadsheet quoted by Ian Baker at > http://www.codecutters.org/temp/HD-Ratio.xls > makes the erroneous assumption that 254 out of every 256 addresses are > available for any size block, when in fact it's 2 addresses (first and last) > out of any size block that are unavailable. On the other hand, if you take a big block and carve it into /29s for customer subnets, then a quarter of a huge allocation can disappear into subnet broadcast addresses. You can't count the number of possible hosts in a block unless you know how it's subnetted. And, if you're assigning /32s to customer endpoints, you could use *every* IP address in a block, so it's possible to beat the single-big-ethernet limit by two hosts. :-) -- Anthony DeBoer Onramp Technical Support From owen at delong.com Tue Feb 10 22:48:45 2004 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Feb 2004 19:48:45 -0800 Subject: [ppml] HD Ratio changes In-Reply-To: <20040210195829.H32741@onramp.ca> References: <2147483647.1076422504@dhcp157-233.corp.tellme.com> <20040210195829.H32741@onramp.ca> Message-ID: <2147483647.1076442525@dhcp157-233.corp.tellme.com> So... To further simplify (sarcasm intended) this policy, I guess we'd need to specify or find out how ARIN would go about determining available hosts within a topology to compare against utilized hosts. Michael, care to elaborate on this? Owen --On Tuesday, February 10, 2004 19:58 -0500 Anthony DeBoer wrote: > William Stucke wrote: >> The Excel spreadsheet quoted by Ian Baker at >> http://www.codecutters.org/temp/HD-Ratio.xls >> makes the erroneous assumption that 254 out of every 256 addresses are >> available for any size block, when in fact it's 2 addresses (first and >> last) out of any size block that are unavailable. > > On the other hand, if you take a big block and carve it into /29s for > customer subnets, then a quarter of a huge allocation can disappear > into subnet broadcast addresses. You can't count the number of possible > hosts in a block unless you know how it's subnetted. > > And, if you're assigning /32s to customer endpoints, you could use *every* > IP address in a block, so it's possible to beat the single-big-ethernet > limit by two hosts. :-) -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Wed Feb 11 06:24:44 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 Feb 2004 11:24:44 +0000 Subject: [ppml] HD Ratio changes Message-ID: >The HD Ratio Policy seems to be getting complicated. We should keep >things SIMPLE. 4 sentences... >Especially since there will be newcomers to the ARIN >policies that will need to learn how to adopt our practices in a short >period of time. The solution to that problem is better education. That's why I have posted links to other documents and why I am preparing some more detailed examples including charts and tables that will be posted to the web once this policy proposal has been formally submitted. >Can it be said that the rediscovery and repair of previous allocations >inefficiencies (or rather their inclusion towards current utilization >rates) could prove more fruitful in the quest for IPv4 address space? Every network is different. But under the current policy it would be very unwise for an ISP to fix previous inefficiencies. Instead, they should only use addresses from their most recent allocation and only resort to older addresses if they run into shortages after having exhausted the last allocation and before getting a new allocation approved. The current policy discourages ISPs from recovering and reusing address space. Those older addresses represent flexibility while the 80% threshold represents rigidity. >If a new policy is ratified, will it only apply to new allocations? That's what it says. And it is optional too. If you can't figure it out, then stick with 80%. If your tool vendor hasn't implemented the HD Ratio then stick with 80%. If you do complex analyses and comparisons of the HD Ratio and it works out worse than 80% then stick with 80%. > Practices that would include the (true) inclusion of > previously allocated address space, and the more meticulous weeding out > of 'ghost' reassignments (SWIP's of customers that are no longer there). This new policy encourages this to happen because it no longer forces larger networks to do the impossible and because it accomodates the need for longer lead times that are common in larger organizations. Today people have to hide a stash of ghost reassignments to use as a buffer against the uncertainty of the ARIN allocation process and the rigidity of the 80% threshhold. >Rather than rehash an existing policy, I think we should look elsewhere >for NEW ways to extend the life of our IPv4 address space, both old and >new. (And enforce those measures). I'm not interested in extending the life of our IPv4 address space. We have twenty years supply left and if the HD ratio cuts that down to 18 years, then I'm still happy. In about 10 years I expect that IPv6 deployment will be so widespread that people will start returning IPv4 space. In other words I believe the IPv4 address space will never run out. --Michael Dillon From Michael.Dillon at radianz.com Wed Feb 11 06:38:25 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 Feb 2004 11:38:25 +0000 Subject: [ppml] Defining Utilization of IPv4 addresses Message-ID: Yet another policy proposal that will be submitted to ARIN in the next few days. Comments? 1. When an ISP applies for IPv4 address space, ARIN analyzes the utilization rate of any existing IPv4 address blocks allocated to the ISP. 2. For the purposes of calculating the utilization rate, any IPv4 address range that is assigned or allocated to another organization will be counted as utilized if it meets the following two conditions. 3. The assigned or allocated address range must be of a size that is justified by ARIN policy. 4. The ISP must require the other organization to use their addresses efficiently using VLSM and CIDR technologies. 5. The utilization rate of an address block is calculated as the number of utilized addresses divided by the total number of addresses in the block. Rationale: Currently, there is no clear definition of utilization in ARIN's IPv4 policy. The result is that different organizations interpret this in different ways. This policy change is an attempt to level the playing field so that noone has an unfair competitive advantage due to the vagueness of the policy. This policy change only provides a clear definition for the utilization rate of address blocks allocated by ARIN to ISPs. It does not address the utilization rate of address blocks assigned to end users which would presumably be calculated differently by counting end devices, network and broadcast addresses. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 From cscott at gaslightmedia.com Wed Feb 11 10:12:01 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Wed, 11 Feb 2004 10:12:01 -0500 (EST) Subject: [ppml] HD Ratio changes In-Reply-To: <2147483647.1076422504@dhcp157-233.corp.tellme.com> Message-ID: Michael: I believe the simplified formula for calculating the number of hosts for ".996 HD" in Perl is. exp(log($total_hosts)*.996) In any case it gives the same numbers your code does. From this it appears that if some HD ratio is adopted that the .996 number may not be appropriate. Also, since we're talking about an allocation/assignment policy, shouldn't the HD ratio be applied to the total volume of addresses that have been so assigned rather than the count of hosts deployed in that address space? I wonder how that would affects the results. Chuck Scott On Tue, 10 Feb 2004, Owen DeLong wrote: > OK... I took your mail, and tried to make this simple... > > I wrote the the attached PERL script to compute the number of hosts needed > for > a .996 HD ratio and the number of hosts needed for 80% utilization and came > up with the following table. Either HD doesn't do what you claim, or, it > isn't simple enough for me and my math didn't work right. The table here > shows that in all cases, a .996 HD ratio is a larger number than the > 80% requirement, and, that the more space you have, the worse it gets. I'm > guessing I've got an error in my code, but, this is as easy as I thought it > could be to compute the HD ratio needed for a given block size. If you have > an easier way, please post code. > > > +--------+-----------+-----------+-----------+---------------+ > | Prefix | N Hosts | .996 HD | 80% HD | .996 HD - 80% | > +--------+-----------+-----------+-----------+---------------+ > | /3 | 536870912 | 495393603 | 429496729 | 65896873 | > | /4 | 268435456 | 248384517 | 214748364 | 33636152 | > | /5 | 134217728 | 124537069 | 107374182 | 17162886 | > | /6 | 67108864 | 62441419 | 53687091 | 8754327 | > | /7 | 33554432 | 31307393 | 26843545 | 4463847 | > | /8 | 16777216 | 15697157 | 13421772 | 2275384 | > | /9 | 8388608 | 7870369 | 6710886 | 1159482 | > | /10 | 4194304 | 3946111 | 3355443 | 590667 | > | /11 | 2097152 | 1978533 | 1677721 | 300811 | > | /12 | 1048576 | 992013 | 838860 | 153152 | > | /13 | 524288 | 497383 | 419430 | 77952 | > | /14 | 262144 | 249383 | 209715 | 39667 | > | /15 | 131072 | 125037 | 104857 | 20179 | > | /16 | 65536 | 62693 | 52428 | 10264 | > | /17 | 32768 | 31433 | 26214 | 5218 | > | /18 | 16384 | 15761 | 13107 | 2653 | > | /19 | 8192 | 7901 | 6553 | 1347 | > | /20 | 4096 | 3961 | 3276 | 684 | > | /21 | 2048 | 1987 | 1638 | 348 | > | /22 | 1024 | 995 | 819 | 175 | > | /23 | 512 | 499 | 409 | 89 | > | /24 | 256 | 251 | 204 | 46 | > | /25 | 128 | 125 | 102 | 22 | > | /26 | 64 | 63 | 51 | 11 | > | /27 | 32 | 31 | 25 | 5 | > | /28 | 16 | 15 | 12 | 2 | > | /29 | 8 | 7 | 6 | 0 | > | /30 | 4 | 3 | 3 | 0 | > | /31 | 2 | 1 | 1 | 0 | > +--------+-----------+-----------+-----------+---------------+ > From Michael.Dillon at radianz.com Wed Feb 11 10:49:08 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 Feb 2004 15:49:08 +0000 Subject: [ppml] HD Ratio changes Message-ID: > Also, since we're talking about an allocation/assignment policy, >shouldn't the HD ratio be applied to the total volume of addresses that >have been so assigned rather than the count of hosts deployed in that >address space? I wonder how that would affects the results. I've been following the various calculation attempts and I will be providing some tables along with an explanation of how I reached those numbers. I'm still working on this to make it as understandable as possible so I probably won't release it until the proposal has been formally submitted to ARIN. I plan to provide both an Excel spreadsheet and a PERL script that do the exact same calculations and produce the same tables of comparison. --Michael Dillon From tme at multicasttech.com Wed Feb 11 11:57:05 2004 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 11 Feb 2004 11:57:05 -0500 Subject: [ppml] Defining Utilization of IPv4 addresses In-Reply-To: Message-ID: <5243F83D-5CB3-11D8-8B36-003065FC3726@multicasttech.com> How does this mesh with Policy Proposal 2002-3 ? Especially question 3 ? BTW - What is the status of 2002-3 - was this ever put into practice ? On Wednesday, February 11, 2004, at 06:38 AM, Michael.Dillon at radianz.com wrote: > Yet another policy proposal that will be submitted to ARIN > in the next few days. Comments? > > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > utilization rate of any existing IPv4 address blocks allocated > to the ISP. > > 2. For the purposes of calculating the utilization rate, any IPv4 > address range that is assigned or allocated to another organization > will be counted as utilized if it meets the following two > conditions. > > 3. The assigned or allocated address range must be of a size that is > justified by ARIN policy. > > 4. The ISP must require the other organization to use their addresses > efficiently using VLSM and CIDR technologies. > > 5. The utilization rate of an address block is calculated as the > number of utilized addresses divided by the total number of > addresses in the block. > > Rationale: > > Currently, there is no clear definition of utilization in ARIN's IPv4 > policy. The result is that different organizations interpret this in > different ways. This policy change is an attempt to level the playing > field so that noone has an unfair competitive advantage due to the > vagueness of the policy. > > This policy change only provides a clear definition for the utilization > rate of address blocks allocated by ARIN to ISPs. It does not address > the > utilization rate of address blocks assigned to end users which would > presumably be calculated differently by counting end devices, network > and broadcast addresses. > > ------------------------------------------------------- > Michael Dillon > Capacity Planning, Prescot St., London, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > > Regards Marshall Eubanks T.M. Eubanks e-mail : marshall.eubanks at telesuite.com http://www.telesuite.com From Michael.Dillon at radianz.com Wed Feb 11 12:01:44 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 11 Feb 2004 17:01:44 +0000 Subject: [ppml] Defining Utilization of IPv4 addresses Message-ID: >How does this mesh with Policy Proposal 2002-3 ? Especially >question 3 ? 2002-3 was adopted and it says nothing about utilization. This is the text of 2002-3: Multi-homed organizations may justify and obtain a block of address space with prefix length extending to /22 directly from ARIN. When prefixes are longer than /20, these micro-allocations or micro-assignments will be from a reserved block for that purpose. Nevertheless, we still need a publicly agreed definition of "utilized" and an agreed way to calculate utilization rates. --Michael Dillon From tme at multicasttech.com Wed Feb 11 12:24:33 2004 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 11 Feb 2004 12:24:33 -0500 Subject: [ppml] Defining Utilization of IPv4 addresses In-Reply-To: Message-ID: <28A323DB-5CB7-11D8-8B36-003065FC3726@multicasttech.com> That is my point : On Wednesday, February 11, 2004, at 12:01 PM, Michael.Dillon at radianz.com wrote: >> How does this mesh with Policy Proposal 2002-3 ? Especially >> question 3 ? > > 2002-3 was adopted and it says nothing about utilization. > This is the text of 2002-3: > Multi-homed organizations may justify and obtain a block > of address space with prefix length extending to /22 > directly from ARIN. When prefixes are longer than /20, > these micro-allocations or micro-assignments will be from > a reserved block for that purpose. > The whole point of this was that it was _not_ justified by utilization, but by "multi-homed-ness". I do not regard 2002-3 as compatible with > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > utilization rate of any existing IPv4 address blocks allocated > to the ISP. > > 2. For the purposes of calculating the utilization rate, any IPv4 > address range that is assigned or allocated to another organization > will be counted as utilized if it meets the following two > conditions. > > 3. The assigned or allocated address range must be of a size that is > justified by ARIN policy. > Nevertheless, we still need a publicly agreed definition > of "utilized" and an agreed way to calculate utilization > rates. > > --Michael Dillon > > > > Regards Marshall Eubanks T.M. Eubanks e-mail : marshall.eubanks at telesuite.com http://www.telesuite.com From owen at delong.com Wed Feb 11 17:05:32 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Feb 2004 14:05:32 -0800 Subject: [ppml] HD Ratio changes In-Reply-To: References: Message-ID: <2147483647.1076508332@dhcp157-233.corp.tellme.com> Being as not all the world runs Micr0$0ft products, could you consider publishing the spreadsheet in a more open format, such as SXC or XML? Thanks, Owen --On Wednesday, February 11, 2004 15:49 +0000 Michael.Dillon at radianz.com wrote: >> Also, since we're talking about an allocation/assignment policy, >> shouldn't the HD ratio be applied to the total volume of addresses that >> have been so assigned rather than the count of hosts deployed in that >> address space? I wonder how that would affects the results. > > I've been following the various calculation attempts > and I will be providing some tables along with an > explanation of how I reached those numbers. I'm still > working on this to make it as understandable as possible > so I probably won't release it until the proposal has > been formally submitted to ARIN. I plan to provide > both an Excel spreadsheet and a PERL script that do > the exact same calculations and produce the same > tables of comparison. > > --Michael Dillon > > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Feb 11 17:10:27 2004 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Feb 2004 14:10:27 -0800 Subject: [ppml] Defining Utilization of IPv4 addresses In-Reply-To: <28A323DB-5CB7-11D8-8B36-003065FC3726@multicasttech.com> References: <28A323DB-5CB7-11D8-8B36-003065FC3726@multicasttech.com> Message-ID: <2147483647.1076508627@dhcp157-233.corp.tellme.com> I view them as compatible because they are unrelated. Nothing in the proposal to define utilization affects 2002-3 because 2002-3 does not depend on utilization as a criteria. However, in other policies where utilization is a criteria, the definition below is a proposal which could normalize how that is applied. I am not sure if it is the correct proposal, but, I agree that it is a good idea for there to be a consistent definition of utilization. I am not sure if that definition should be a policy proposal or if it should be something set by the AC and ARIN Staff and documented as an adjunct to the policy. However, I don't think 2002-3 is a reason not to proceed on this. I consider them completely separate and unrelated issues. Owen --On Wednesday, February 11, 2004 12:24 -0500 Marshall Eubanks wrote: > That is my point : > > On Wednesday, February 11, 2004, at 12:01 PM, Michael.Dillon at radianz.com > wrote: > >>> How does this mesh with Policy Proposal 2002-3 ? Especially >>> question 3 ? >> >> 2002-3 was adopted and it says nothing about utilization. >> This is the text of 2002-3: >> Multi-homed organizations may justify and obtain a block >> of address space with prefix length extending to /22 >> directly from ARIN. When prefixes are longer than /20, >> these micro-allocations or micro-assignments will be from >> a reserved block for that purpose. >> > > The whole point of this was that it was _not_ justified by > utilization, but by "multi-homed-ness". I do not regard 2002-3 as > compatible with > >> 1. When an ISP applies for IPv4 address space, ARIN analyzes the >> utilization rate of any existing IPv4 address blocks allocated >> to the ISP. >> >> 2. For the purposes of calculating the utilization rate, any IPv4 >> address range that is assigned or allocated to another organization >> will be counted as utilized if it meets the following two >> conditions. >> >> 3. The assigned or allocated address range must be of a size that is >> justified by ARIN policy. > > >> Nevertheless, we still need a publicly agreed definition >> of "utilized" and an agreed way to calculate utilization >> rates. >> >> --Michael Dillon >> >> >> >> > Regards > Marshall Eubanks > > T.M. Eubanks > e-mail : marshall.eubanks at telesuite.com > http://www.telesuite.com > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Thu Feb 12 10:11:59 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 12 Feb 2004 15:11:59 +0000 Subject: [ppml] Nasty business with 2003-3 Message-ID: There is a policy proposal that, on the face of it, is about improving the privacy of residential customers. It allows an ISP to remove a customer's name and street address from a whois entry. But it says nothing about zip codes. And that is the root of the problem... Here are some references that show how a Zip+4 code or a Postal Code can be used to narrow down the physical location of a person to a small enough area to make it easy to stalk someone or burn down their house in the middle of the night. USA http://www.usps.com/zip4/zipfaq.htm http://www.usps.com/history/history/his3_5.htm Canada http://www.infinitegravity.ca/postalcodeformat.htm http://www.canadapost.ca/personal/tools/pg/preparation/mpp6-02-e.asp Now the board of trustees did note this as an issue and referred the policy proposal back to the AC. But the AC did not address the privacy issue at all. They simply bounced it back to the BoT with a note that they had "discussed" the issue. This is a flawed policy proposal. It claims to improve residential privacy and yet it does not remove all the data which identifies the residential user. --Michael Dillon From william at elan.net Thu Feb 12 11:52:47 2004 From: william at elan.net (williamelan.net) Date: Thu, 12 Feb 2004 08:52:47 -0800 (PST) Subject: [ppml] Nasty business with 2003-3 In-Reply-To: Message-ID: USPS codes can only narrow down the search to very small area if the last 4 digits are includes (i.e. ZIP+4 as you indicate), but last 4 digits are not considered to be required part of zip or postal code - it is optional and used and added primarily by postal carriers to help in mail routing, most people omit it when just casually writing the address and I would suspect ISPs and customers that care about privacy will omit this last 4 digits. Just zip code itself (5 digits) is usually wide enough (size of small city) and is not a violation of prvicay - while at the other hand it comes very usefull in identifying statistical distribution of assignments, particulary by automated means (its a lot easier to automate system to obtain and use database ofall zip codes then for all cities and villages, large and small in the US). Now this does not mean I agree with the policy - I'm opposed to it as I do not believe the kind of privacy requirements that are being asked are necessary and their presense causes problems for those investigating incidents of abuse and allow for much more abuse directly from ISPs. However not passing policy just because of presence of zip code is just complete nonsence. If city name is there, the address might as well include zip and make statistic analysis easier. On Thu, 12 Feb 2004 Michael.Dillon at radianz.com wrote: > There is a policy proposal that, on the face of it, is about improving the > privacy of residential customers. It allows an ISP to remove a customer's > name and street address from a whois entry. But it says nothing about zip > codes. And that is the root of the problem... > > Here are some references that show how a Zip+4 code or a Postal Code can > be used to narrow down the physical location of a person to a small enough > area to make it easy to stalk someone or burn down their house in the > middle of the night. > > USA > http://www.usps.com/zip4/zipfaq.htm > http://www.usps.com/history/history/his3_5.htm > > Canada > http://www.infinitegravity.ca/postalcodeformat.htm > http://www.canadapost.ca/personal/tools/pg/preparation/mpp6-02-e.asp > > Now the board of trustees did note this as an issue and referred the > policy proposal back to the AC. But the AC did not address the privacy > issue at all. They simply bounced it back to the BoT with a note that they > had "discussed" the issue. > > This is a flawed policy proposal. It claims to improve residential privacy > and yet it does not remove all the data which identifies the residential > user. > > --Michael Dillon From ahp at hilander.com Thu Feb 12 10:57:55 2004 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 12 Feb 2004 08:57:55 -0700 Subject: [ppml] Nasty business with 2003-3 In-Reply-To: References: Message-ID: <2147483647.1076576275@[192.168.0.100]> --On Thursday, February 12, 2004 15:11 +0000 Michael.Dillon at radianz.com wrote: > > Now the board of trustees did note this as an issue and referred the > policy proposal back to the AC. But the AC did not address the privacy > issue at all. They simply bounced it back to the BoT with a note that > they had "discussed" the issue. That is correct Michael. The fact of the matter is that privacy concerns notwithstanding there was consensus at the public policy meeting for the policy as written. I will note that the public policy meeting minutes mention nothing about this issue[1], and I note that you were at the meeting and you generally are not shy about airing your concerns at these meetings. For further context with respect to the AC discussion, there was a lot of dialogue about the fact that 'street address' could be defined as either the actual number, street name and unit number. Or it could be defined as the entire set of coordinates that identify a location. There was discussion about whether or not policies that refer to database content should reference specific field names (which got us back on the topic of re-crafting all policy that exists to make it more consistent, which is a laudable goal but was beyond the context of the agenda item). I personally voted in favor of returning the policy to the BoT because: 1) There was consensus for the text as written at the public policy meeting 2) The definition of 'street address' (IMO) is sufficiently ambiguous to allow an ISP to not provide any localizing information. 3) The change proposed (changing 'street address' to something like 'street address, city, state, zip and country') would require the policy to go through another cycle, and there was an immediate need for a change in the existing policy. Clearly there were four AC members at the meeting who did not agree with me, and for all I know the other five who voted in favor did so for entirely different reasons. However, I wanted to give you the reasoning behind my vote. Now, I also agree that the AC did miss the boat by not airing the issue you raised during our initial review of the final call, it took the BoT returning it to us for that to happen. This was not in the minutes, but I requested that for future last call reviews those AC members responsible for watching a last call itemize each e-mail (or each thread if there are too many e-mails) for the AC to ensure that such issues do not fall through the cracks in the future. Alec [1] From DeftLee at netscape.net Thu Feb 12 11:13:37 2004 From: DeftLee at netscape.net (Lee Howard) Date: Thu, 12 Feb 2004 11:13:37 -0500 Subject: [ppml] Defining Utilization of IPv4 addresses Message-ID: <346695DC.465F53CD.001642C1@netscape.net> I'm neither for nor against this proposal, but I'd like to understand better how this contrasts with existing policy. Michael.Dillon at radianz.com wrote: >Yet another policy proposal that will be submitted to ARIN >in the next few days. Comments? > >1. When an ISP applies for IPv4 address space, ARIN analyzes the > utilization rate of any existing IPv4 address blocks allocated > to the ISP. This is consistent with current policy. http://www.arin.net/policy/ipv4.html#ispinitial http://www.arin.net/policy/ipv4.html#additional >2. For the purposes of calculating the utilization rate, any IPv4 > address range that is assigned or allocated to another organization > will be counted as utilized if it meets the following two conditions. Definition of terms: ISPs are allocated IP space, which they re-assign to other organizations. You could say: . . . any reassignments will be considered utilized under the following conditions: A. B. >3. The assigned or allocated address range must be of a size that is > justified by ARIN policy. I'm not sure what this means. Current policy says: ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. http://www.arin.net/policy/ipv4.html#reassign >4. The ISP must require the other organization to use their addresses > efficiently using VLSM and CIDR technologies. Right, as under current policy continued from above: ISPs reassigning IP address space to their customers should require their customers to use variable length subnet mask (VLSM) and classless technologies (CIDR) within their networks. http://www.arin.net/policy/ipv4.html#reassign >5. The utilization rate of an address block is calculated as the > number of utilized addresses divided by the total number of > addresses in the block. I find this confusing. #5 refers to #2, essentially saying: The utilization rate of an address block is calculated as any IPv4 address range that is reassigned to another organization divided by the total number of addresses in the block. So it looks to me like all the words you're using already exist in current policy, except that you want to change this sentence: http://www.arin.net/policy/ipv4.html#additional ISPs must have efficiently utilized all previous allocations, and at least 80% of their most recent allocation in order to receive additional space. This includes all space reassigned to their customers. To read: ISPs must have efficiently utilized (by assignment or reassignment) all previous allocations, and have assigned or reassigned at least 80% of their most recent allocation in order to receive additional space. Do you think there's confusion over the divisor and dividend? It may not be explicit, but for this policy and the HD Ratio proposal, the network number and broadcast address are automatically "assigned" or "utilized" when the block is reassigned. A /30 is not less efficient than four /32s for the purposes of utilization review. I'm sure staff will be happy to upbraid me if I have misstated current policy or practice. Thanks for clarifying. Lee >Rationale: > >Currently, there is no clear definition of utilization in ARIN's IPv4 >policy. The result is that different organizations interpret this in >different ways. This policy change is an attempt to level the playing >field so that noone has an unfair competitive advantage due to the >vagueness of the policy. > >This policy change only provides a clear definition for the utilization >rate of address blocks allocated by ARIN to ISPs. It does not address the >utilization rate of address blocks assigned to end users which would >presumably be calculated differently by counting end devices, network >and broadcast addresses. > >------------------------------------------------------- >Michael Dillon >Capacity Planning, Prescot St., London, UK >Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com >Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > > __________________________________________________________________ New! Unlimited Netscape Internet Service. Only $9.95 a month -- Sign up today at http://isp.netscape.com/register Act now to get a personalized email address! Netscape. Just the Net You Need. From Michael.Dillon at radianz.com Thu Feb 12 11:17:12 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 12 Feb 2004 16:17:12 +0000 Subject: [ppml] Nasty business with 2003-3 Message-ID: >I will >note that the public policy meeting minutes mention nothing about this >issue[1], and I note that you were at the meeting and you generally are not >shy about airing your concerns at these meetings. I didn't think about this until the last call on the mailing list. And now, I'm not sure whether there will be another last call so I wanted to air the matter before the BoT looks at it again. >(which got us back on the topic of >re-crafting all policy that exists to make it more consistent, which is a >laudable goal but was beyond the context of the agenda item). Let's hope that the agenda manages to get back to that one someday. >2) The definition of 'street address' (IMO) is sufficiently ambiguous to >allow an ISP to not provide any localizing information. I believe that many telco and cableco ISPs view ARIN's policies as a form of regulation and would be as hesitant to violate the letter of an ARIN policy as they are hestiant to violate the law. >3) The change proposed (changing 'street address' to something like 'street >address, city, state, zip and country') would require the policy to go >through another cycle, and there was an immediate need for a change in the >existing policy. I know. The process stinks. The BoT should have fixed this issue by directing ARIN staff to remove all location identifying fields from the database until such time as a policy could specifically address what information was to be made public and what information was to be made private, particularly with regard to the Gramm-Leach-Bliley Safeguards Rule. A letter could have gone to all registered rwhois server operators suggesting that they do likewise until the matter is resolved. In fact, it is not too late for the BoT to convene an extraordinary meeting and do just that. We've got to realize when we are dealing with issues that affect the larger society and step aside from the political infighting between our industry interest groups. --Michael Dillon From William at zanet.co.za Thu Feb 12 11:25:52 2004 From: William at zanet.co.za (William Stucke) Date: Thu, 12 Feb 2004 18:25:52 +0200 Subject: [ppml] Defining Utilization of IPv4 addresses In-Reply-To: <346695DC.465F53CD.001642C1@netscape.net> Message-ID: Lee Howard said: - > It may not be explicit, but for this policy and the HD Ratio > proposal, the network number and broadcast address are automatically > "assigned" or "utilized" when the block is reassigned. A /30 is not > less efficient than four /32s for the purposes of utilization review. Thank you for that clarification. I at least found it missing from the previous discussion. Regards, William Stucke ZAnet Internet Services (Pty) Ltd +27 11 465 0700 William at zanet.co.za From bicknell at ufp.org Thu Feb 12 11:33:47 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 12 Feb 2004 11:33:47 -0500 Subject: [ppml] Nasty business with 2003-3 In-Reply-To: <2147483647.1076576275@[192.168.0.100]> References: <2147483647.1076576275@[192.168.0.100]> Message-ID: <20040212163347.GA16562@ussenterprise.ufp.org> In a message written on Thu, Feb 12, 2004 at 08:57:55AM -0700, Alec H. Peterson wrote: > 2) The definition of 'street address' (IMO) is sufficiently ambiguous to > allow an ISP to not provide any localizing information. There is evidence that it was not intended to be ambiguous: http://www.arin.net/mailing_lists/ppml/1800.html However, it's all a bit of a moot point now. There are two things that need to be take-aways from this exercise: * If you specifiy what should, or should not be in databases like whois use the field names that already exist in the database, exactly. That is: OrgName: OrgID: Address: City: StateProv: PostalCode: Country: Comment: RegDate: Updated: "Street Address" is not a field. Please say "Address:" field, or "Address:" + "City:" + "StateProv:" + "PostalCode:" + "Country:" fields. * If you don't like it, take the existing 2003-3, change it to specify fields, and reintroduce it. Slightly annoying, but it's how our process works. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Michael.Dillon at radianz.com Thu Feb 12 11:38:00 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 12 Feb 2004 16:38:00 +0000 Subject: [ppml] Utilization Message-ID: In response to Lee: I agree that this proposal is more complex than it should be. I wish that the current policy had numbered paragraphs so that I could clearly and concisely refer to it rather than trying to restate it. Let me start again by posting the current wording (slightly changed) and then list a number of explanatory points. 1. When an ISP applies for IPv4 address space, ARIN analyzes the utilization rate of any existing IPv4 address blocks allocated to the ISP. 2. For the purposes of calculating the utilization rate of ARIN allocations, any IPv4 address range that is assigned or allocated by the ISP to another organization will be counted as utilized if it meets the following two conditions. 3. The assigned or allocated address range must be of a size that is justified by ARIN policy. 4. The ISP must require the other organization to use their addresses efficiently, in particular by using VLSM and CIDR technologies. 5. The utilization rate of an address block is calculated as the number of utilized addresses divided by the total number of addresses in the block. Note the following points: a) This policy is for ISPs, i.e. organizations who receive an allocation from ARIN and then transfer chunks of the allocation to other parties. b) The utilization that we are measuring refers to the allocation received from ARIN. c) We don't care whether a subset of the allocation is assigned or allocated to another party. For the purposes of calculating utilization they are equivalent. d) We don't want to supersede other restrictions on allocations and assignments so we impose two conditions which attempt to echo the existing policy. e) Point d above would be unnecessary if we could simply refer to numbered paragraphs. f) The first condition says that we are not usurping the existing requirement to justify an allocation or an assignment. g) The second conditon says that we are not usurping the existing requirement for a transitive technical AUP. h) The final clause could be considered redundant because once we have defined "utilized" the rate calculation should be obvious. However I believe that there is value in making the calculation explicit so that tool implementors have a reference that maps easily into programming languages. i) I don't want to incorporate a few wording changes into existing policy. I want to explicitly say what we mean by utilization and how we measure it in an unambiguous way because the existing policy is interpreted differently by different ISPs. j) I also want a clear definition for IP address management tool vendors who may have incporporated different calculations in their tools. I could probably deal with references to the existing policy in a better way. I'll think about that. And I didn't mention broadcast and network addresses because those are used in calculating utilization of an assigment by end users, i.e. leaf nodes in the hierarchy. --Michael Dillon From andrew.dul at quark.net Thu Feb 12 12:49:46 2004 From: andrew.dul at quark.net (andrew.dul at quark.net) Date: 12 Feb 2004 09:49:46 -0800 Subject: [ppml] Nasty business with 2003-3 In-Reply-To: References: Message-ID: <1076608186.402bbcba09b37@secure.zipcon.net> Quoting Michael.Dillon at radianz.com: > > Now the board of trustees did note this as an issue and referred the > policy proposal back to the AC. But the AC did not address the privacy > issue at all. They simply bounced it back to the BoT with a note that > they > had "discussed" the issue. > > This is a flawed policy proposal. It claims to improve residential > privacy > and yet it does not remove all the data which identifies the residential > > user. > We did discuss the issue and I personally believed that there was not a substantial issue here to consider. I agree that the text of the policy probably could have been written better to be clearer. I do not understand how you feel that the following showing up in whois is a privacy concern. Private Customer Private Address Seattle, WA 98102 I believe this was the intent of the policy. If you and/or others feel that this was not the intent then we need a new policy to clarify this by using the exact fields and the exact text that should appear for residential customers. Andrew Dul ARIN AC From william at elan.net Thu Feb 12 15:09:01 2004 From: william at elan.net (williamelan.net) Date: Thu, 12 Feb 2004 12:09:01 -0800 (PST) Subject: [ppml] On subject of 2003-3 and 2003-5 and whois data availability In-Reply-To: <2147483647.1076576275@[192.168.0.100]> Message-ID: The subject of 2003-3 and what needs to be reported in whois reminded of something I wanted to be clarified. It appears several companies (L3 for example) are of the opinion that they do not need to report customer announcements in whois and they are only required to report them to ARIN Before they partly justified this by saying they have internal rwhois server that they make available to ARIN which complies with ARIN polices. I'd like to know ARIN's and others opinion on this and if they believe the current policies require companies to make all reassignments to customers (reassignments of /28 or larger I think) be available in public whois or publicly available through ISP maintained rwhois server. And does this issue with requirement for public access to rwhois properly addresses by 2003-5 policy proposal (i.e. would I be able to tell them that they must make access to rwhois server publicly available after this policy is adapted by BOT). Also when 2003-5 is adapted what kind of time-frame does ARIN estimate it needs to provide to its ISP members to make any necessary improvements in service to properly comply with this policy. Here I have a suggest that after policy is adapted that ARIN send notice to tech and admin contacts for all organizations that use rwhois server to inform that they of the adaption of this policy and that they have such and such fixed timeframe to make necesary changes and that after that time ARIN will check on the rwhois server to make sure its properly configured and returns proper information (ok, maybe asking ARIN to do check on every rwhois server is too much of resource drain but it can probably do some random checks and act on reports). -- William Leibzon Elan Networks william at elan.net From leslien at arin.net Thu Feb 12 16:45:15 2004 From: leslien at arin.net (Leslie Nobile) Date: Thu, 12 Feb 2004 16:45:15 -0500 Subject: [ppml] Utilization In-Reply-To: Message-ID: <00c501c3f1b1$8012b180$538888c0@arin.net> Hello- We have been following this discussion and thought that it might be useful to the community if we clarified several points as they relate to current ARIN practice and policy. (ARIN comments begin with ***) -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Michael.Dillon at radianz.com Sent: Thursday, February 12, 2004 11:38 AM To: ppml at arin.net Subject: [ppml] Utilization In response to Lee: I agree that this proposal is more complex than it should be. I wish that the current policy had numbered paragraphs so that I could clearly and concisely refer to it rather than trying to restate it. Let me start again by posting the current wording (slightly changed) and then list a number of explanatory points. 1. When an ISP applies for IPv4 address space, ARIN analyzes the utilization rate of any existing IPv4 address blocks allocated to the ISP. *** Utilization rate is not entirely correct terminology as it actually refers to how fast IP address space is used over time. In its analysis of how an IPv4 address block is used, ARIN looks at overall utilization, including the percentage of space used, and the amount of time it took to use that space (the utilization rate). 2. For the purposes of calculating the utilization rate of ARIN allocations, any IPv4 address range that is assigned or allocated by the ISP to another organization will be counted as utilized if it meets the following two conditions. *** Under current policy, when reviewing overall utilization, ARIN looks at sub-delegations made to the ISP's services (i.e. DSL, dial-up.), web-hosting, and infrastructure, in addition to reassignments and reallocations made to other organizations. 3. The assigned or allocated address range must be of a size that is justified by ARIN policy. 4. The ISP must require the other organization to use their addresses efficiently, in particular by using VLSM and CIDR technologies. 5. The utilization rate of an address block is calculated as the number of utilized addresses divided by the total number of addresses in the block. *** The total utilization percentage is currently calculated this way. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) Note the following points: a) This policy is for ISPs, i.e. organizations who receive an allocation from ARIN and then transfer chunks of the allocation to other parties. b) The utilization that we are measuring refers to the allocation received from ARIN. c) We don't care whether a subset of the allocation is assigned or allocated to another party. For the purposes of calculating utilization they are equivalent. d) We don't want to supersede other restrictions on allocations and assignments so we impose two conditions which attempt to echo the existing policy. e) Point d above would be unnecessary if we could simply refer to numbered paragraphs. f) The first condition says that we are not usurping the existing requirement to justify an allocation or an assignment. g) The second conditon says that we are not usurping the existing requirement for a transitive technical AUP. h) The final clause could be considered redundant because once we have defined "utilized" the rate calculation should be obvious. However I believe that there is value in making the calculation explicit so that tool implementors have a reference that maps easily into programming languages. i) I don't want to incorporate a few wording changes into existing policy. I want to explicitly say what we mean by utilization and how we measure it in an unambiguous way because the existing policy is interpreted differently by different ISPs. j) I also want a clear definition for IP address management tool vendors who may have incporporated different calculations in their tools. I could probably deal with references to the existing policy in a better way. I'll think about that. And I didn't mention broadcast and network addresses because those are used in calculating utilization of an assigment by end users, i.e. leaf nodes in the hierarchy. --Michael Dillon From owen at delong.com Thu Feb 12 21:21:55 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Feb 2004 18:21:55 -0800 Subject: [ppml] Nasty business with 2003-3 In-Reply-To: References: Message-ID: <2147483647.1076610115@dhcp157-233.corp.tellme.com> You also fail to address that the 6 character Canadian Postal codes are equivalent to ZIP+4 and are considered required for Canada. Owen --On Thursday, February 12, 2004 8:52 -0800 "williamelan.net" wrote: > > USPS codes can only narrow down the search to very small area if the last > 4 digits are includes (i.e. ZIP+4 as you indicate), but last 4 digits are > not considered to be required part of zip or postal code - it is optional > and used and added primarily by postal carriers to help in mail routing, > most people omit it when just casually writing the address and I would > suspect ISPs and customers that care about privacy will omit this last 4 > digits. > > Just zip code itself (5 digits) is usually wide enough (size of small > city) and is not a violation of prvicay - while at the other hand it > comes very useful in identifying statistical distribution of > assignments, particulary by automated means (its a lot easier to automate > system to obtain and use database ofall zip codes then for all cities > and villages, large and small in the US). > > Now this does not mean I agree with the policy - I'm opposed to it as I > do not believe the kind of privacy requirements that are being asked are > necessary and their ppresencecauses problems for those investigating > incidents of abuse and allow for much more abuse directly from ISPs. > However not passing policy just because of presence of zip code is just > complete nonsence. If city name is there, the address might as well > include zip and make statistic analysis easier. > > On Thu, 12 Feb 2004 Michael.Dillon at radianz.com wrote: > >> There is a policy proposal that, on the face of it, is about improving >> the privacy of residential customers. It allows an ISP to remove a >> customer's name and street address from a whois entry. But it says >> nothing about zip codes. And that is the root of the problem... >> >> Here are some references that show how a Zip+4 code or a Postal Code can >> be used to narrow down the physical location of a person to a small >> enough area to make it easy to stalk someone or burn down their house >> in the middle of the night. >> >> USA >> http://www.usps.com/zip4/zipfaq.htm >> http://www.usps.com/history/history/his3_5.htm >> >> Canada >> http://www.infinitegravity.ca/postalcodeformat.htm >> http://www.canadapost.ca/personal/tools/pg/preparation/mpp6-02-e.asp >> >> Now the board of trustees did note this as an issue and referred the >> policy proposal back to the AC. But the AC did not address the privacy >> issue at all. They simply bounced it back to the BoT with a note that >> they had "discussed" the issue. >> >> This is a flawed policy proposal. It claims to improve residential >> privacy and yet it does not remove all the data which identifies the >> residential user. >> >> --Michael Dillon > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Feb 12 21:29:26 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Feb 2004 18:29:26 -0800 Subject: [ppml] Nasty business with 2003-3 In-Reply-To: References: Message-ID: <2147483647.1076610566@dhcp157-233.corp.tellme.com> >> 2) The definition of 'street address' (IMO) is sufficiently ambiguous to >> allow an ISP to not provide any localizing information. > > I believe that many telco and cableco ISPs view ARIN's policies > as a form of regulation and would be as hesitant to violate the > letter of an ARIN policy as they are hestiant to violate the law. > Michael, I'm not sure whether you intended sarcasm here or not, but, I can assure you that in my experience, most Telco and Cableco iSPs are only unwilling to violate the law if they expect to get caught and there is significant accountability or cost to doing so. Otherwise, they seem to regard the letter of the law as a minor irritant at best. > In fact, it is not too late for the BoT to convene an extraordinary > meeting and do just that. We've got to realize when we are dealing > with issues that affect the larger society and step aside from the > political infighting between our industry interest groups. I think this is an unfair characterization of the debate on this issue. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Feb 12 21:36:01 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Feb 2004 18:36:01 -0800 Subject: [ppml] Nasty business with 2003-3 In-Reply-To: <1076608186.402bbcba09b37@secure.zipcon.net> References: <1076608186.402bbcba09b37@secure.zipcon.net> Message-ID: <2147483647.1076610961@dhcp157-233.corp.tellme.com> His point, and I have to agree _IF_ you think privacy is a concern here (I don't happen to agree) is that: Private Customer Private Address San Jose, CA 95121-1520 or Private Customer Private Address Toronto, ON V5K3W1 _IS_ a privacy concern. Both of those locations actually narrow things down to a small enough search area that you have a decent chance of finding someone through relatively simple methods. (Check the links Michael posted for one set of possible examples.). I'll refrain from posting a tutorial on any of the simpler techniques I know here. Owen --On Thursday, February 12, 2004 9:49 -0800 andrew.dul at quark.net wrote: > Quoting Michael.Dillon at radianz.com: >> >> Now the board of trustees did note this as an issue and referred the >> policy proposal back to the AC. But the AC did not address the privacy >> issue at all. They simply bounced it back to the BoT with a note that >> they >> had "discussed" the issue. >> >> This is a flawed policy proposal. It claims to improve residential >> privacy >> and yet it does not remove all the data which identifies the residential >> >> user. >> > > We did discuss the issue and I personally believed that there was not a > substantial issue here to consider. I agree that the text of the policy > probably could have been written better to be clearer. > > I do not understand how you feel that the following showing up in whois > is a privacy concern. > > Private Customer > Private Address > Seattle, WA 98102 > > I believe this was the intent of the policy. If you and/or others feel > that this was not the intent then we need a new policy to clarify this > by using the exact fields and the exact text that should appear for > residential customers. > > Andrew Dul > ARIN AC > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Fri Feb 13 06:16:53 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Fri, 13 Feb 2004 11:16:53 +0000 Subject: [ppml] Utilization Message-ID: >*** Utilization rate is not entirely correct terminology as it actually >refers to how fast IP address space is used over time. You're right, however the current policy uses the term "utilization rate" in contexts that clearly are talking about utilization percentage, e.g. cable address space policy. Since I don't want to rewrite the whole policy set at this time, I'm sticking with the word "rate" for consistency. >*** Under current policy, when reviewing overall utilization, ARIN looks at >sub-delegations made to the ISP's services (i.e. DSL, dial-up.), >web-hosting, and infrastructure, in addition to reassignments and >reallocations made to other organizations. It sounds like your working definition of utilization is, in fact, the same as the explicit definition I am proposing for the policy. >*** The total utilization percentage is currently calculated this way. Thank you, Leslie. Hopefully we can now get this down in black and white so that everyone understands this in the same way. --Michael Dillon From memsvcs at arin.net Thu Feb 19 08:59:44 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 19 Feb 2004 08:59:44 -0500 (EST) Subject: [ppml] Proposed policy - Defining Utilization of IPv4 addresses Message-ID: <200402191359.IAA10010@ops.arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If this proposal is accepted by the Advisory Council or successfully petitioned it will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the proposal is not supported by the AC and the author elects not to petition or the petition fails, then the policy proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Defining Utilization of IPv4 addresses Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. When an ISP applies for IPv4 address space, ARIN analyzes the utilization rate of any existing IPv4 address blocks allocated to the ISP. 2. For the purposes of calculating the utilization rate of ARIN allocations, any IPv4 address range that is assigned or allocated by the ISP to another organization will be counted as utilized if it meets the following two conditions. 3. The assigned or allocated address range must be of a size that is justified by ARIN policy. 4. The ISP must require the other organization to use their addresses efficiently, in particular by using VLSM and CIDR technologies. 5. The utilization rate of an address block is calculated as the number of utilized addresses divided by the total number of addresses in the block. Rationale: Currently, there is no clear definition of utilization in ARIN's IPv4 policy. The result is that different organizations interpret this in different ways. This policy change is an attempt to level the playing field so that noone has an unfair competitive advantage due to the vagueness of the policy. This policy change only provides a clear definition for the utilization rate of address blocks allocated by ARIN to ISPs. It does not address the utilization rate of address blocks assigned to end users which would presumably be calculated differently by counting end devices, network and broadcast addresses. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Thu Feb 19 09:32:52 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 19 Feb 2004 09:32:52 -0500 (EST) Subject: [ppml] Proposed policy - Use of HD-Ratio for IPv4 Allocations Message-ID: <200402191432.JAA17294@ops.arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If this proposal is accepted by the Advisory Council or successfully petitioned it will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the proposal is not supported by the AC and the author elects not to petition or the petition fails, then the policy proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Use of HD-Ratio for IPv4 Allocations Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. Anyone who has already been allocated 4096 IPv4 addresses or more may choose to have additional requests for IPv4 addresses evaluated using an HD (Host Density) Ratio calculation to determine sufficient utilization instead of a fixed percentage threshold. 2. All requests for additional IPv4 address space subject to the HD Ratio shall require the efficient utilization of the sum total of all existing allocations. The HD Ratio on the sum total of all existing allocations must be greater than or equal to .966. 3. In addition, the HD ratio of the most recent allocation must be greater than or equal to .930. 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. Rationale: The HD ratio was proposed as a way to determine allocation usage thresholds for IPv6 address allocations. For more details on this, please refer to RFC 3194 . There is some detailed background discussion about applying the HD ratio to IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing list on Aug 7, 2003 http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and he presented the it to the annual APNIC policy meeting using these slides http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf I am not suggesting that ARIN should adopt the APNIC proposal and although Paul invents a new name for the HD ratio, I prefer to keep the original term. The basic thrust of this proposal is to replace the rigid 80% usage criterion by the more flexible HD ratio and to shift the emphasis away from the last allocated block to include the total allocated address space. To that end, the .930 criterion for the last block is a lot looser than the existing requirements for the last block. This is because the utilization threshold establishes a time buffer between the beginning of an ARIN application for additional addresses and the final deployment of new addresses in the operational network. By using a looser criterion as network size grows, we are also expanding this time buffer. This recognizes that the economy is more dependent than ever on the smooth running of our networks and we should not artificially force larger members to operate with virtually no safety buffers for implementing new addresses. This safety buffer size is important because larger networks have more involved processes for changes to their network and these processes take time. Paul Wilson's paper contains ample discussions of the technical justification for using the HD ratio. I have proposed that we use the .966 number that he suggests, I believe there may be valid arguments for reducing this slightly, perhaps to .960. It would be good for ARIN to have more detailed discussion of the HD ratio on file however I don't believe that needs to be in the policy itself. However, I would suggest that the ARIN website should contain a copy of RFC 3194, a copy of Paul Wilson's paper, and a summary of any ARIN member discussions regarding application of the HD ratio to IPv4 addresses. I will also be preparing some slides with graphs and tables that can be displayed on the ARIN website prior to the policy meeting. Please note the following points. a) This policy only applies to organizations that already have IP space equivalent to a /20 block or larger. b) The policy does not specify the source of the 4096 or more addresses therefore it could apply to an ISP who comes to ARIN for the very first time and exchanges an upstream allocation for their own PI space. c) The policy does not use the term "ISP" therefore it can also apply to any other organization with a large network which is growing larger and therefore needs another allocation. d) The policy only applies to organizations who opt-in. This means that if your IP address management tools can't handle the HD ratio you can ignore it. If you find the HD ratio confusing or complex then you can ignore it. If you are crafty and fund a study which finds that your organization would benefit in some way from the old rules about an 80% threshhold then you can ignore this new policy. The new policy provides a benefit to those organizations which need it without penalizing those which do not. e) This policy proposal cannot be understood in isolation. You do need to read the RFC and Paul Wilson's discussion paper. f) The .966 calculation in point 2 covers the entire aggregate of address space including the block covered by the .930 calculation in point 3. You have to meet both targets to pass this policy's test. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Thu Feb 19 09:34:13 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 19 Feb 2004 09:34:13 -0500 (EST) Subject: [ppml] Proposed policy - Purpose and scope of ARIN Whois directory Message-ID: <200402191434.JAA17473@ops.arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If this proposal is accepted by the Advisory Council or successfully petitioned it will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the proposal is not supported by the AC and the author elects not to petition or the petition fails, then the policy proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Purpose and scope of ARIN Whois directory Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of interconnected IP networks. 2. This directory will contain contact information for all organizations and individuals within the ARIN region who have received IP allocations or AS numbers directly from ARIN or its predecessors. 3. Organizations and individuals must guarantee to ARIN that contact addresses published in the whois directory will reach a person who is ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. 4. Any other organizations may elect to be listed in the whois directory as long as they make the guarantee detailed in item 3. 5. All contacts listed in the whois directory will be contacted periodically and the directory will indicate information which may be stale if contact cannot be made promptly. 6. Additionally, the whois directory will contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by the entities mentioned in item 3. 7. The records mentioned in item 7 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. Rationale: ARIN doesn't really have a policy regarding whois. Most of what we have today is adopted based on a long tradition that nobody understands anymore. In looking back at historical sources it appears that whois was originally set up so that ARPANET site managers could justify their ARPANET connectivity funding by enumerating the people/projects that were making use of the ARPANET. Times have changed and tradition is no longer sufficient reason for doing things. This proposal attempts to put in place a simple statement of the purpose and scope of a whois directory. It is my opinion that if we cannot all agree on some sort of simple policy similar to what I am proposing, then we probably should scrap the whois directory entirely. Nothing in this policy should be construed to restrain ARIN staff's ability to maintain and use whatever databases they may need in the performance of their duties including IP address allocation. This policy only refers to the data which is made freely available to the public. If this policy is adopted it will also alleviate concerns from the cable and DSL industry in regard to residential user privacy. a) ARIN policy doesn't currently state that ARIN will maintain or publish a whois directory. This policy fixes that. b) This proposal also explicitly states the purpose of the whois directory as being targeted at internetworking and operational issues. It is not intended to help anti-spamming collectives bypass the ISPs who are responsible for operating a network. In fact one of the goals is to make it harder for anti-spamming groups to attack end users. This whois policy would force them to report network abuse to the ISP employees who are responsible for finding and fixing network abuse issues. c) The proposal does not recognize research as part of the scope of the whois directory, however items 6 and 7 do provide for data which allows some mapping and analysis of address usage and therefore the research community will not be left out in the cold. d) This policy only directly puts a mandate on those organizations who have, or should have, an ARIN relationship to supply data. e) The policy also allows any responsible party to add their contact data to the ARIN database. However, this is done with their consent and by binding them to act responsibly, i.e. you can't list your organization and then ignore all abuse reports. The words "Ready, willing and able to communicate" are important here. f) The ARIN staff are charged to keep the directory up to date and to give us some indication when the contact process seems to be going awry. However, it refrains from giving detailed directions to the staff and relies on their prudence in setting out the timing and the process of this verification. g) I interpret "facilitating the operation of interconnected IP networks" to include the provision of data that allows some mapping and statistical analysis of the address space. For that reason, some small amount of data is required to enumerate and distinguish sub-allocations and assignments. h) This policy covers rwhois as well. ARIN is charged to maintain the whois directory but can certainly delegate some of this task to rwhois users. And when the policy specifies that all address blocks must be represented in the directory it also allows for this information to be published indirectly, for instance, through rhwois. However the policy does not require rwhois technology since it is in such a sad state of repair. It also refrains from prescribing LDAP at this time ;-) i) The classification system for organization types has been intentionally left unspecified. Obviously, it needs to include "individual" as a type but it could include NAICS sector codes, e.g. "NAICS 25" is the construction industry. It could also include NTEE codes for non-profits e.g. "NTEE H" is Medical research. And it could include some simple codes like "Company", "Non-Profit", "Education", "Government" for users who don't know about the various classification systems. j) End users are truly anonymous, no name, no address, no zip/postal code. In other words, people who are not involved in network operations are not identified in any way by the whois directory. Timetable for implementation: 30 days after ratification From memsvcs at arin.net Thu Feb 19 09:35:10 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 19 Feb 2004 09:35:10 -0500 (EST) Subject: [ppml] Proposed policy - Connective Private Network Allocations Message-ID: <200402191435.JAA17639@ops.arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If this proposal is accepted by the Advisory Council or successfully petitioned it will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the proposal is not supported by the AC and the author elects not to petition or the petition fails, then the policy proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Connective Private Network Allocations Author: Marla Azinger Author's Organization: Electric Lightwave Policy term: Permanent Policy statement: Provide separate private networks a means of privately networking with each other when the use of private IPs have been deemed inappropriate for this connectivity. Rationale: There are currently a couple different situations in which it seems public IPs are needed to support a widely used private network. For simplicity the E-911 situation is used as the primary example in this policy proposal discussion. The E-911 networks are comprised of all the confidential communication among Police Stations, Fire Stations, Sheriff Stations, State Troop Stations and various other Emergency Response Programs. Background: Every city and state deploys E-911 services separately. This has created multiple private networks within every County in the United States. There is now an increasing effort to make these separate entities communicate with each other. This is achieved by putting these individual E-911 networks onto one larger connected private network while at the same time leaving each individual network with its own autonomy to do as it will. Since every separate private network is maintaining it's very own private network and utilizing the private IP blocks within it's own network...there are no private IPs easily identified for use in this connected private network. Also, due to the delicate nature of this E-911 network it is imperative that no IP range "accidentally" gets utilized more than once. This leaves us with only one option. This option is to use public IPs on the E-911 Connective Networks. How this has been handled for the past few years: Either knowingly or not by the upstream provider, public IPs are already being used for these private networks. There is currently one specific company working with ELI for creating several of these "E-911 connected private networks." This company has already attained several different blocks from multiple large telecom companies. Why bring this above the table now: Several reasons. One, to make the entire community aware of this situation. Two, to provide them with a clearly documented answer that is supported by ARIN and the internet community. 9. Timetable for implementation: Apr 2004 1st Day of Conference: Vote on yes or no to implement use of Public IPs for Private use when requirements are met. Apr 2004 2nd Day of Conference: Vote on requirements and supporting questions detailed below in *proposal step 2. *Policy proposal step 2 Supporting questions in need of answers and votes after this proposal has been voted in to new ARIN Policy. These questions exist in order to clarify what public IPs should be used, who should be assigning them, and state what the qualifying requirements should be. 1. Should a special block of IPs be set aside for this type of use? a. Pro: b. Con: There are already networks using IPs for this purpose and they will not want to renumber. A grandfather clause would be needed to protect those that are already using IPs in this manner. 2. Who should assign these IPs? Upstream or ARIN? a. Upstream Pro: b. Upstream Con: c. ARIN Pro: d. ARIN Con: 3. What are the qualifying requirements for someone to be allocated IPs for this type of use? a. Emergency Use (Police enforcement organizations, Fire departments, 911 dispatch units) b. Life support line (ie. suicide hot lines, hospitals) c. 4. What are the qualifying factors that deem the use of Private IP blocks for connectivity inappropriate? a. When the quantity of private networks being combined makes it numerically unsupportable. From memsvcs at arin.net Thu Feb 19 09:36:06 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 19 Feb 2004 09:36:06 -0500 (EST) Subject: [ppml] Proposed policy - Unique Addresses for Private Interconnections Message-ID: <200402191436.JAA17783@ops.arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If this proposal is accepted by the Advisory Council or successfully petitioned it will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the proposal is not supported by the AC and the author elects not to petition or the petition fails, then the policy proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Unique Addresses for Private Interconnections Author: Bill Copeland Author's Organization: MCI Policy statement: Interfaces that connect private networks may be assigned globally unique address space. Hosts within the administrative control of a single organization should still use private addressing in accordance with RFC1918 and RFC2050. This policy is not intended to override other policies with regard to justification, minimum size, fees, or any other standard procedure. Rationale: HISTORY RFC1918 and RFC2050 make some mention of networks that are not routable on the public Internet. An internet-draft, internet-draft-guichard-pe-ce, proposing a large block (/8 or /12) reserved for this purpose, failed to achieve consensus support to move forward. Private interconnections between large organizations are becoming more and more common. In some cases these are private networks, and in other cases they are Virtual Private Networks (VPN) using a common layer 3 transport. When these networks connect, there is the possibility that addresses assigned in good faith on one network may overlap addresses assigned in good faith on the other. This will cause routing instability and reachability problems. Some of these networks are offered by service providers who create a network, and establish multiple VPNs to use that network. For RFC2547 VPNs, the address space used by any single VPN will not conflict with another, since a separate routing table is used for each network. However, the routing tables still need reachability information provided based on the IP address of the links between the provider's edge (PE) and the customer's edge (CE). RFC CONSIDERATIONS RFC2050 says: In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. Based on experience, ARIN has interpreted the RFC consistently to mean that organizations not connected to the global, public Internet do not need globally unique IP address space. However, there is not specific policy for the situation described here. In attention to similar situations, RFC1918 says: Hosts within enterprises that use IP can be partitioned into three categories: Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. It is clear that routers need access to each other, and in a layer 3 VPN that requires non-conflicting addresses between routers (to be specific and conservative, non-conflicting addresses between PE-CE links). So while it is true that one VPN customer organization's router (host) may not need to be able to reach another VPN customer organization's router (host), the VPN provider needs to reach both routers. In some cases, VPN customer organizations do need to be able to reach each other, as in the case of industry interconnects or extranets. It should be noted that the authors of RFC1918 made some consideration of this scenario, and the RFC seems to suggest that the private space it reserves should not be used for interconnected enterprises. However, there is no ARIN policy to allow for allocation for these enterprises. An Internet Draft was prepared to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, the latest version of which is available at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr-03.txt The draft failed to reach consensus support to move forward. This draft described some of the alternatives to using public address space, and some of the cases where they won't work. Finally, it should be noted that even if another addressing scheme is used, a router used to connect to a VPN may also legitmately be connected to the Internet. Network Address Translation (NAT) cannot be used in two instances on a single router under current technology. Any address space outside of RFC1918-reserved addresses must be considered routable. Therefore, if the network local to the router uses RFC1918 space and NAT to translate addresses back to the Internet, it cannot use another instance of NAT back to the VPN. REFERENCES internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for PE-CE links within a Provider Provisioned VPN Network," Jim Guichard, et al. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr-03.txt RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. http://www.arin.net/library/rfc/rfc2050.txt RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. http://www.ietf.org/rfc/rfc2547.txt RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. http://www.arin.net/library/rfc/rfc1918.txt Timetable for implementation: The policy should be applied immediately, contingent upon final approval by the Board and agreement that if the policy does not pass the organization will renumber. From billd at cait.wustl.edu Thu Feb 19 11:00:07 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 19 Feb 2004 10:00:07 -0600 Subject: [ppml] Proposed policy - Purpose and scope of ARIN Whois dire ctory Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD029EBC@kronos.cait.wustl.edu> I presume that policy item #7 which references policy "item #7" really refers to item #6. May we please verify this and make a correction? Thanks, Bill Darte ARIN AC 314 935-7575 -----Original Message----- From: Member Services [mailto:memsvcs at arin.net] Sent: Thursday, February 19, 2004 8:34 AM To: ppml at arin.net Subject: [ppml] Proposed policy - Purpose and scope of ARIN Whois directory ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process the proposal is being posted to the ARIN Public Policy Mailing List and being placed on ARIN's website. The ARIN Advisory Council will review the proposal and within ten working days may decide to: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If this proposal is accepted by the Advisory Council or successfully petitioned it will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the proposal is not supported by the AC and the author elects not to petition or the petition fails, then the policy proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process is available at: http://www.arin.net/policy/ipep.html Mailing list subscription information is available at: http://www.arin.net/mailing_lists/index.html Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal Name: Purpose and scope of ARIN Whois directory Author: Michael Dillon Author's Organization: Radianz, Inc. Policy term: permanent Policy statement: 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of interconnected IP networks. 2. This directory will contain contact information for all organizations and individuals within the ARIN region who have received IP allocations or AS numbers directly from ARIN or its predecessors. 3. Organizations and individuals must guarantee to ARIN that contact addresses published in the whois directory will reach a person who is ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. 4. Any other organizations may elect to be listed in the whois directory as long as they make the guarantee detailed in item 3. 5. All contacts listed in the whois directory will be contacted periodically and the directory will indicate information which may be stale if contact cannot be made promptly. 6. Additionally, the whois directory will contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by the entities mentioned in item 3. 7. The records mentioned in item 7 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. Rationale: ARIN doesn't really have a policy regarding whois. Most of what we have today is adopted based on a long tradition that nobody understands anymore. In looking back at historical sources it appears that whois was originally set up so that ARPANET site managers could justify their ARPANET connectivity funding by enumerating the people/projects that were making use of the ARPANET. Times have changed and tradition is no longer sufficient reason for doing things. This proposal attempts to put in place a simple statement of the purpose and scope of a whois directory. It is my opinion that if we cannot all agree on some sort of simple policy similar to what I am proposing, then we probably should scrap the whois directory entirely. Nothing in this policy should be construed to restrain ARIN staff's ability to maintain and use whatever databases they may need in the performance of their duties including IP address allocation. This policy only refers to the data which is made freely available to the public. If this policy is adopted it will also alleviate concerns from the cable and DSL industry in regard to residential user privacy. a) ARIN policy doesn't currently state that ARIN will maintain or publish a whois directory. This policy fixes that. b) This proposal also explicitly states the purpose of the whois directory as being targeted at internetworking and operational issues. It is not intended to help anti-spamming collectives bypass the ISPs who are responsible for operating a network. In fact one of the goals is to make it harder for anti-spamming groups to attack end users. This whois policy would force them to report network abuse to the ISP employees who are responsible for finding and fixing network abuse issues. c) The proposal does not recognize research as part of the scope of the whois directory, however items 6 and 7 do provide for data which allows some mapping and analysis of address usage and therefore the research community will not be left out in the cold. d) This policy only directly puts a mandate on those organizations who have, or should have, an ARIN relationship to supply data. e) The policy also allows any responsible party to add their contact data to the ARIN database. However, this is done with their consent and by binding them to act responsibly, i.e. you can't list your organization and then ignore all abuse reports. The words "Ready, willing and able to communicate" are important here. f) The ARIN staff are charged to keep the directory up to date and to give us some indication when the contact process seems to be going awry. However, it refrains from giving detailed directions to the staff and relies on their prudence in setting out the timing and the process of this verification. g) I interpret "facilitating the operation of interconnected IP networks" to include the provision of data that allows some mapping and statistical analysis of the address space. For that reason, some small amount of data is required to enumerate and distinguish sub-allocations and assignments. h) This policy covers rwhois as well. ARIN is charged to maintain the whois directory but can certainly delegate some of this task to rwhois users. And when the policy specifies that all address blocks must be represented in the directory it also allows for this information to be published indirectly, for instance, through rhwois. However the policy does not require rwhois technology since it is in such a sad state of repair. It also refrains from prescribing LDAP at this time ;-) i) The classification system for organization types has been intentionally left unspecified. Obviously, it needs to include "individual" as a type but it could include NAICS sector codes, e.g. "NAICS 25" is the construction industry. It could also include NTEE codes for non-profits e.g. "NTEE H" is Medical research. And it could include some simple codes like "Company", "Non-Profit", "Education", "Government" for users who don't know about the various classification systems. j) End users are truly anonymous, no name, no address, no zip/postal code. In other words, people who are not involved in network operations are not identified in any way by the whois directory. Timetable for implementation: 30 days after ratification From Michael.Dillon at radianz.com Thu Feb 19 12:06:25 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 19 Feb 2004 17:06:25 +0000 Subject: [ppml] Proposed policy - Purpose and scope of ARIN Whois dire ctory Message-ID: >I presume that policy item #7 which references policy "item #7" really >refers to item #6. Yes, you are right. >May we please verify this and make a correction? Since this is still the 19th, can ARIN please make this correction to the policy proposal posted on the website? Corrected text... 6. Additionally, the whois directory will contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by the entities mentioned in item 3. 7. The records mentioned in item 6 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. --Michael Dillon From cscott at gaslightmedia.com Thu Feb 19 12:50:46 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Thu, 19 Feb 2004 12:50:46 -0500 (EST) Subject: [ppml] Proposed policy - Defining Utilization of IPv4 addresses In-Reply-To: <200402191359.IAA10010@ops.arin.net> Message-ID: PPML: This would seem to be a necessary and well constructed policy. The only glitch I see in it is the use of "utilized addresses" in "5". Since we're talkng about addresses that are assigned or allocated to a customer as fully utilized for the purpose of this policy, "5" could be changed to say it more clearly. 5. The utilization rate of an address block is calculated as the number of addresses assigned or allocated out of that address block divided by the total number of addresses in the block. Other than that, I think I like it. Chuck Scott On Thu, 19 Feb 2004, Member Services wrote: > Policy Proposal Name: Defining Utilization of IPv4 addresses > > Author: Michael Dillon > > Author's Organization: Radianz, Inc. > > Policy term: permanent > > Policy statement: > > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > utilization rate of any existing IPv4 address blocks allocated > to the ISP. > > 2. For the purposes of calculating the utilization rate of ARIN > allocations, any IPv4 address range that is assigned or allocated > by the ISP to another organization will be counted as utilized if > it meets the following two conditions. > > 3. The assigned or allocated address range must be of a size that is > justified by ARIN policy. > > 4. The ISP must require the other organization to use their addresses > efficiently, in particular by using VLSM and CIDR technologies. > > 5. The utilization rate of an address block is calculated as the > number of utilized addresses divided by the total number of > addresses in the block. > > Rationale: > > Currently, there is no clear definition of utilization in ARIN's IPv4 > policy. The result is that different organizations interpret this in > different ways. This policy change is an attempt to level the playing > field so that noone has an unfair competitive advantage due to the > vagueness of the policy. > > This policy change only provides a clear definition for the utilization > rate of address blocks allocated by ARIN to ISPs. It does not address the > utilization rate of address blocks assigned to end users which would > presumably be calculated differently by counting end devices, network > and broadcast addresses. > > Timetable for implementation: 30 days after ratification > From cscott at gaslightmedia.com Thu Feb 19 13:23:29 2004 From: cscott at gaslightmedia.com (Charles Scott) Date: Thu, 19 Feb 2004 13:23:29 -0500 (EST) Subject: [ppml] Proposed policy - Use of HD-Ratio for IPv4 Allocations In-Reply-To: <200402191432.JAA17294@ops.arin.net> Message-ID: PPML: I would prefer to see this proposal apply exclusively to end-user assignments. Having read the rationale for HD ratio, I am unable to see how HD applies to an address block that is consumed by assignment of blocks to end-users. The rationale for HD is based on the complexities and practicalities of deploying resources in a numerically hierarchical manner, although I believe that those issues are at least somewhat mitigated by the ability to route subnets that are not numerically subordinate to the network in which they exist. Those complexities and practicalities, however, have not been shown to relate to the allocation of address space in blocks to end users. If an ISP both consumes and assigns address space, it would seem that those two functions should be separated to enable the ISP to opt into HD for the address space it assigns to itself for it's own consumption, while still using the existing policy to dictate the manner in which they receive block assignments from ARIN. I believe that some, if not most, ISP's effectively do this now. I believe that by limiting the following policy to end-user policy only it could offer (possibly) needed relief for the implementation of large networks by end-users without risking significant affects on the overall address pool. Chuck Scott > > Policy Proposal Name: Use of HD-Ratio for IPv4 Allocations > > Author: Michael Dillon > > Author's Organization: Radianz, Inc. > > Policy term: permanent > > Policy statement: > > 1. Anyone who has already been allocated 4096 IPv4 addresses or > more may choose to have additional requests for IPv4 addresses > evaluated using an HD (Host Density) Ratio calculation to determine > sufficient utilization instead of a fixed percentage threshold. > > 2. All requests for additional IPv4 address space subject to the HD > Ratio shall require the efficient utilization of the sum total of > all existing allocations. The HD Ratio on the sum total of all > existing allocations must be greater than or equal to .966. > > 3. In addition, the HD ratio of the most recent allocation must be > greater than or equal to .930. > > 4. The HD ratio is calculated as log(utilized IPv4 addresses) divided > by log(total addresses in all previous allocations). In this formula, > log refers to the natural logarithm. > > Rationale: > > The HD ratio was proposed as a way to determine allocation usage > thresholds for IPv6 address allocations. For more details on this, > please refer to RFC 3194 . There > is some detailed background discussion about applying the HD ratio to > IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing > list on Aug 7, 2003 > http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html > and he presented the it to the annual APNIC policy meeting using these > slides > http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wilson-hd-ratio.pdf > I am not suggesting that ARIN should adopt the APNIC proposal and > although Paul invents a new name for the HD ratio, I prefer to keep the > original term. > > The basic thrust of this proposal is to replace the rigid 80% usage > criterion by the more flexible HD ratio and to shift the emphasis away > from the last allocated block to include the total allocated address > space. To that end, the .930 criterion for the last block is a lot > looser than the existing requirements for the last block. This is > because the utilization threshold establishes a time buffer between > the beginning of an ARIN application for additional addresses and the > final deployment of new addresses in the operational network. By using > a looser criterion as network size grows, we are also expanding this > time buffer. This recognizes that the economy is more dependent than > ever on the smooth running of our networks and we should not artificially > force larger members to operate with virtually no safety buffers for > implementing new addresses. This safety buffer size is important because > larger networks have more involved processes for changes to their network > and these processes take time. > > Paul Wilson's paper contains ample discussions of the technical > justification for using the HD ratio. I have proposed that we use > the .966 number that he suggests, I believe there may be valid arguments > for reducing this slightly, perhaps to .960. > > It would be good for ARIN to have more detailed discussion of the HD > ratio on file however I don't believe that needs to be in the policy > itself. However, I would suggest that the ARIN website should contain a > copy of RFC 3194, a copy of Paul Wilson's paper, and a summary of any > ARIN member discussions regarding application of the HD ratio to IPv4 > addresses. I will also be preparing some slides with graphs and tables > that can be displayed on the ARIN website prior to the policy meeting. > > Please note the following points. > > a) This policy only applies to organizations that already have IP space > equivalent to a /20 block or larger. > > b) The policy does not specify the source of the 4096 or more addresses > therefore it could apply to an ISP who comes to ARIN for the very > first time and exchanges an upstream allocation for their own > PI space. > > c) The policy does not use the term "ISP" therefore it can also > apply to any other organization with a large network which > is growing larger and therefore needs another allocation. > > d) The policy only applies to organizations who opt-in. This means > that if your IP address management tools can't handle the HD ratio > you can ignore it. If you find the HD ratio confusing or complex > then you can ignore it. If you are crafty and fund a study which > finds that your organization would benefit in some way from the > old rules about an 80% threshhold then you can ignore this new > policy. The new policy provides a benefit to those organizations > which need it without penalizing those which do not. > > e) This policy proposal cannot be understood in isolation. You do need > to read the RFC and Paul Wilson's discussion paper. > > f) The .966 calculation in point 2 covers the entire aggregate of > address space including the block covered by the .930 calculation > in point 3. You have to meet both targets to pass this policy's test. > > Timetable for implementation: 30 days after ratification > From mark.huff at integratelecom.com Fri Feb 20 13:37:21 2004 From: mark.huff at integratelecom.com (Huff, Mark) Date: Fri, 20 Feb 2004 10:37:21 -0800 Subject: [ppml] Proposed policy - Defining Utilization of IPv4 address es Message-ID: #4 requires ISP to police there customer base for proper usage of downstream allocations. Other than stating the requirement to customers in a AUP, how effective can a ISP police the use of IP space granted. Once blocks are assigned, inquiries to customers for audit of the space would likely go unanswered. Mark Huff > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Thursday, February 19, 2004 6:00 AM > To: ppml at arin.net > Subject: [ppml] Proposed policy - Defining Utilization of > IPv4 addresses > > > ARIN received the following policy proposal. In accordance > with the ARIN Internet Resource Policy Evaluation Process the > proposal is being posted to the ARIN Public Policy Mailing List > and being placed on ARIN's website. > > The ARIN Advisory Council will review the proposal and within > ten working days may decide to: > 1) support the proposal as is, > 2) work with the author to clarify, divide or combine one or more > policy proposals, or > 3) not support the policy proposal. > > If this proposal is accepted by the Advisory Council or successfully > petitioned it will be posted as a formal policy proposal to the Public > Policy Mailing List and it will be presented at the Public Policy > Meeting. If the proposal is not supported by the AC and the author > elects not to petition or the petition fails, then the policy proposal > will be considered closed. > > The ARIN Internet Resource Policy Evaluation Process is available at: > http://www.arin.net/policy/ipep.html > > Mailing list subscription information is available at: > http://www.arin.net/mailing_lists/index.html > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal Name: Defining Utilization of IPv4 addresses > > Author: Michael Dillon > > Author's Organization: Radianz, Inc. > > Policy term: permanent > > Policy statement: > > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > utilization rate of any existing IPv4 address blocks allocated > to the ISP. > > 2. For the purposes of calculating the utilization rate of ARIN > allocations, any IPv4 address range that is assigned or allocated > by the ISP to another organization will be counted as utilized if > it meets the following two conditions. > > 3. The assigned or allocated address range must be of a size that is > justified by ARIN policy. > > 4. The ISP must require the other organization to use their addresses > efficiently, in particular by using VLSM and CIDR technologies. > > 5. The utilization rate of an address block is calculated as the > number of utilized addresses divided by the total number of > addresses in the block. > > Rationale: > > Currently, there is no clear definition of utilization in ARIN's IPv4 > policy. The result is that different organizations interpret this in > different ways. This policy change is an attempt to level the playing > field so that noone has an unfair competitive advantage due to the > vagueness of the policy. > > This policy change only provides a clear definition for the > utilization > rate of address blocks allocated by ARIN to ISPs. It does not > address the > utilization rate of address blocks assigned to end users which would > presumably be calculated differently by counting end devices, network > and broadcast addresses. > > Timetable for implementation: 30 days after ratification > From william at elan.net Fri Feb 20 14:46:43 2004 From: william at elan.net (william(at)elan.net) Date: Fri, 20 Feb 2004 11:46:43 -0800 (PST) Subject: [ppml] Proposed policy - Defining Utilization of IPv4 address es In-Reply-To: Message-ID: Just about as effective as ARIN itself is. Meaning if your customers ask you for more ip space, you check how effectively they utilized existing allocation. But then again I think everyone is doing this already... On Fri, 20 Feb 2004, Huff, Mark wrote: > #4 requires ISP to police there customer base for proper usage of downstream > allocations. > > Other than stating the requirement to customers in a AUP, how effective can > a ISP police the use of IP space granted. Once blocks are assigned, > inquiries to customers for audit of the space would likely go unanswered. > > Mark Huff > > > > > > -----Original Message----- > > From: Member Services [mailto:memsvcs at arin.net] > > Sent: Thursday, February 19, 2004 6:00 AM > > To: ppml at arin.net > > Subject: [ppml] Proposed policy - Defining Utilization of > > IPv4 addresses > > > > > > ARIN received the following policy proposal. In accordance > > with the ARIN Internet Resource Policy Evaluation Process the > > proposal is being posted to the ARIN Public Policy Mailing List > > and being placed on ARIN's website. > > > > The ARIN Advisory Council will review the proposal and within > > ten working days may decide to: > > 1) support the proposal as is, > > 2) work with the author to clarify, divide or combine one or more > > policy proposals, or > > 3) not support the policy proposal. > > > > If this proposal is accepted by the Advisory Council or successfully > > petitioned it will be posted as a formal policy proposal to the Public > > Policy Mailing List and it will be presented at the Public Policy > > Meeting. If the proposal is not supported by the AC and the author > > elects not to petition or the petition fails, then the policy proposal > > will be considered closed. > > > > The ARIN Internet Resource Policy Evaluation Process is available at: > > http://www.arin.net/policy/ipep.html > > > > Mailing list subscription information is available at: > > http://www.arin.net/mailing_lists/index.html > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ### * ### > > > > > > Policy Proposal Name: Defining Utilization of IPv4 addresses > > > > Author: Michael Dillon > > > > Author's Organization: Radianz, Inc. > > > > Policy term: permanent > > > > Policy statement: > > > > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > > utilization rate of any existing IPv4 address blocks allocated > > to the ISP. > > > > 2. For the purposes of calculating the utilization rate of ARIN > > allocations, any IPv4 address range that is assigned or allocated > > by the ISP to another organization will be counted as utilized if > > it meets the following two conditions. > > > > 3. The assigned or allocated address range must be of a size that is > > justified by ARIN policy. > > > > 4. The ISP must require the other organization to use their addresses > > efficiently, in particular by using VLSM and CIDR technologies. > > > > 5. The utilization rate of an address block is calculated as the > > number of utilized addresses divided by the total number of > > addresses in the block. > > > > Rationale: > > > > Currently, there is no clear definition of utilization in ARIN's IPv4 > > policy. The result is that different organizations interpret this in > > different ways. This policy change is an attempt to level the playing > > field so that noone has an unfair competitive advantage due to the > > vagueness of the policy. > > > > This policy change only provides a clear definition for the > > utilization > > rate of address blocks allocated by ARIN to ISPs. It does not > > address the > > utilization rate of address blocks assigned to end users which would > > presumably be calculated differently by counting end devices, network > > and broadcast addresses. > > > > Timetable for implementation: 30 days after ratification > > > -- William Leibzon Elan Networks william at elan.net From mark.huff at integratelecom.com Fri Feb 20 13:56:35 2004 From: mark.huff at integratelecom.com (Huff, Mark) Date: Fri, 20 Feb 2004 10:56:35 -0800 Subject: [ppml] Proposed policy - Defining Utilization of IPv4 address es Message-ID: Yes, but many customers dont come back asking for more so an audit is not required. To satisfy the policy requirement, I must know that all the assignments made are being used correctly. > -----Original Message----- > From: william(at)elan.net [mailto:william at elan.net] > Sent: Friday, February 20, 2004 11:47 AM > To: Huff, Mark > Cc: 'ppml at arin.net' > Subject: RE: [ppml] Proposed policy - Defining Utilization of IPv4 > address es > > > > Just about as effective as ARIN itself is. Meaning if your > customers ask > you for more ip space, you check how effectively they > utilized existing > allocation. But then again I think everyone is doing this already... > > On Fri, 20 Feb 2004, Huff, Mark wrote: > > > #4 requires ISP to police there customer base for proper > usage of downstream > > allocations. > > > > Other than stating the requirement to customers in a AUP, > how effective can > > a ISP police the use of IP space granted. Once blocks are assigned, > > inquiries to customers for audit of the space would likely > go unanswered. > > > > Mark Huff > > > > > > > > > > > -----Original Message----- > > > From: Member Services [mailto:memsvcs at arin.net] > > > Sent: Thursday, February 19, 2004 6:00 AM > > > To: ppml at arin.net > > > Subject: [ppml] Proposed policy - Defining Utilization of > > > IPv4 addresses > > > > > > > > > ARIN received the following policy proposal. In accordance > > > with the ARIN Internet Resource Policy Evaluation Process the > > > proposal is being posted to the ARIN Public Policy Mailing List > > > and being placed on ARIN's website. > > > > > > The ARIN Advisory Council will review the proposal and within > > > ten working days may decide to: > > > 1) support the proposal as is, > > > 2) work with the author to clarify, divide or combine one or more > > > policy proposals, or > > > 3) not support the policy proposal. > > > > > > If this proposal is accepted by the Advisory Council or > successfully > > > petitioned it will be posted as a formal policy proposal > to the Public > > > Policy Mailing List and it will be presented at the Public Policy > > > Meeting. If the proposal is not supported by the AC and > the author > > > elects not to petition or the petition fails, then the > policy proposal > > > will be considered closed. > > > > > > The ARIN Internet Resource Policy Evaluation Process is > available at: > > > http://www.arin.net/policy/ipep.html > > > > > > Mailing list subscription information is available at: > > > http://www.arin.net/mailing_lists/index.html > > > > > > Member Services > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > ### * ### > > > > > > > > > Policy Proposal Name: Defining Utilization of IPv4 addresses > > > > > > Author: Michael Dillon > > > > > > Author's Organization: Radianz, Inc. > > > > > > Policy term: permanent > > > > > > Policy statement: > > > > > > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > > > utilization rate of any existing IPv4 address blocks allocated > > > to the ISP. > > > > > > 2. For the purposes of calculating the utilization rate of ARIN > > > allocations, any IPv4 address range that is assigned > or allocated > > > by the ISP to another organization will be counted as > utilized if > > > it meets the following two conditions. > > > > > > 3. The assigned or allocated address range must be of a > size that is > > > justified by ARIN policy. > > > > > > 4. The ISP must require the other organization to use > their addresses > > > efficiently, in particular by using VLSM and CIDR technologies. > > > > > > 5. The utilization rate of an address block is calculated as the > > > number of utilized addresses divided by the total number of > > > addresses in the block. > > > > > > Rationale: > > > > > > Currently, there is no clear definition of utilization in > ARIN's IPv4 > > > policy. The result is that different organizations > interpret this in > > > different ways. This policy change is an attempt to level > the playing > > > field so that noone has an unfair competitive advantage due to the > > > vagueness of the policy. > > > > > > This policy change only provides a clear definition for the > > > utilization > > > rate of address blocks allocated by ARIN to ISPs. It does not > > > address the > > > utilization rate of address blocks assigned to end users > which would > > > presumably be calculated differently by counting end > devices, network > > > and broadcast addresses. > > > > > > Timetable for implementation: 30 days after ratification > > > > > > > -- > William Leibzon > Elan Networks > william at elan.net > -------------- next part -------------- A non-text attachment was scrubbed... Name: Huff, Mark.vcf Type: application/octet-stream Size: 505 bytes Desc: not available URL: From william at elan.net Fri Feb 20 15:10:40 2004 From: william at elan.net (william(at)elan.net) Date: Fri, 20 Feb 2004 12:10:40 -0800 (PST) Subject: [ppml] Proposed policy - Defining Utilization of IPv4 address es In-Reply-To: Message-ID: #4 says that "you must require them" that means you inform them of this policy either directly or through your own policies/aup when ips are assigned to organiation. It does not specifically mentions that you must police them or audit the utilization every time you ask for ips from ARIN (in fact this is all part of different policy proposal from Michael), but I would expect that possibility of audit should be mentioned just in case (ARIN does have that somewhere in their policies, but I never heard them do it to anybody unless they apply for more ip space or want to transfer ip block). I really don't see this as being that different then what is already being done and the proposal does not seem to state anything new. I'm not really opposed to it, if others think the existing wording is unsufficient and we better restate it as separate policy, so be it. On Fri, 20 Feb 2004, Huff, Mark wrote: > > Yes, but many customers dont come back asking for more so an audit is not > required. To satisfy the policy requirement, I must know that all the > assignments made are being used correctly. > > > > > -----Original Message----- > > From: william(at)elan.net [mailto:william at elan.net] > > Sent: Friday, February 20, 2004 11:47 AM > > To: Huff, Mark > > Cc: 'ppml at arin.net' > > Subject: RE: [ppml] Proposed policy - Defining Utilization of IPv4 > > address es > > > > > > > > Just about as effective as ARIN itself is. Meaning if your > > customers ask > > you for more ip space, you check how effectively they > > utilized existing > > allocation. But then again I think everyone is doing this already... > > > > On Fri, 20 Feb 2004, Huff, Mark wrote: > > > > > #4 requires ISP to police there customer base for proper > > usage of downstream > > > allocations. > > > > > > Other than stating the requirement to customers in a AUP, > > how effective can > > > a ISP police the use of IP space granted. Once blocks are assigned, > > > inquiries to customers for audit of the space would likely > > go unanswered. > > > > > > Mark Huff > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Member Services [mailto:memsvcs at arin.net] > > > > Sent: Thursday, February 19, 2004 6:00 AM > > > > To: ppml at arin.net > > > > Subject: [ppml] Proposed policy - Defining Utilization of > > > > IPv4 addresses > > > > > > > > > > > > ARIN received the following policy proposal. In accordance > > > > with the ARIN Internet Resource Policy Evaluation Process the > > > > proposal is being posted to the ARIN Public Policy Mailing List > > > > and being placed on ARIN's website. > > > > > > > > The ARIN Advisory Council will review the proposal and within > > > > ten working days may decide to: > > > > 1) support the proposal as is, > > > > 2) work with the author to clarify, divide or combine one or more > > > > policy proposals, or > > > > 3) not support the policy proposal. > > > > > > > > If this proposal is accepted by the Advisory Council or > > successfully > > > > petitioned it will be posted as a formal policy proposal > > to the Public > > > > Policy Mailing List and it will be presented at the Public Policy > > > > Meeting. If the proposal is not supported by the AC and > > the author > > > > elects not to petition or the petition fails, then the > > policy proposal > > > > will be considered closed. > > > > > > > > The ARIN Internet Resource Policy Evaluation Process is > > available at: > > > > http://www.arin.net/policy/ipep.html > > > > > > > > Mailing list subscription information is available at: > > > > http://www.arin.net/mailing_lists/index.html > > > > > > > > Member Services > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > ### * ### > > > > > > > > > > > > Policy Proposal Name: Defining Utilization of IPv4 addresses > > > > > > > > Author: Michael Dillon > > > > > > > > Author's Organization: Radianz, Inc. > > > > > > > > Policy term: permanent > > > > > > > > Policy statement: > > > > > > > > 1. When an ISP applies for IPv4 address space, ARIN analyzes the > > > > utilization rate of any existing IPv4 address blocks allocated > > > > to the ISP. > > > > > > > > 2. For the purposes of calculating the utilization rate of ARIN > > > > allocations, any IPv4 address range that is assigned > > or allocated > > > > by the ISP to another organization will be counted as > > utilized if > > > > it meets the following two conditions. > > > > > > > > 3. The assigned or allocated address range must be of a > > size that is > > > > justified by ARIN policy. > > > > > > > > 4. The ISP must require the other organization to use > > their addresses > > > > efficiently, in particular by using VLSM and CIDR technologies. > > > > > > > > 5. The utilization rate of an address block is calculated as the > > > > number of utilized addresses divided by the total number of > > > > addresses in the block. > > > > > > > > Rationale: > > > > > > > > Currently, there is no clear definition of utilization in > > ARIN's IPv4 > > > > policy. The result is that different organizations > > interpret this in > > > > different ways. This policy change is an attempt to level > > the playing > > > > field so that noone has an unfair competitive advantage due to the > > > > vagueness of the policy. > > > > > > > > This policy change only provides a clear definition for the > > > > utilization > > > > rate of address blocks allocated by ARIN to ISPs. It does not > > > > address the > > > > utilization rate of address blocks assigned to end users > > which would > > > > presumably be calculated differently by counting end > > devices, network > > > > and broadcast addresses. > > > > > > > > Timetable for implementation: 30 days after ratification > > > > > > > > > > > -- > > William Leibzon > > Elan Networks > > william at elan.net