From info at arin.net Mon Aug 3 16:37:15 2009 From: info at arin.net (Member Services) Date: Mon, 03 Aug 2009 16:37:15 -0400 Subject: [arin-ppml] Lower End User IPv4 threshold to /24 In-Reply-To: <98685203-69C4-4409-9A69-7FE956364A22@delong.com> References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com> Message-ID: <4A774A7B.3010109@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Owen DeLong wrote: > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: /24 End User Minimum Allocation Unit > 2. Proposal Originator: Owen DeLong > > > 3. Proposal Version: 0.9 > 4. Date: 8/3/09 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection > > For end-users who demonstrate an intent to announce the requested space in a > multihomed fashion to two or more distinct providers, the minimum block of IP > address space assigned is a /24. If assignments smaller than a /24 are needed, > multihomed end-users should contact their upstream providers. When prefixes are > assigned which are longer than /20, they will be from a block reserved for that > purpose so long as that is feasible. End-users may not receive a block > smaller > than /22 under this policy if they already have resources from ARIN, > except as > specified in section 4.3.6.2. > > Renumber the existing paragraph under the 4.3.6 to > > 4.3.6.1 Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Replacement assignments for small multi-homers > > Any end-user that possesses an assignment smaller than /22 under any > part of > section 4.3 shall not be able to get an additional assignment unless > they agree > to return all existing assignments within 12 months of receiving a new > assignment. > The new assignment shall be sized to accommodate their existing > utilization in > addition to their justified additional growth space under section 4.3.6.1. > The common cases for this are expected to be a /24 returned after > receipt of a /23, > or a /23 returned after receipt of a /22. > > 8. Rationale: > > This policy attempts to incorporate the recent and historical discussions of > policy for multi-home users on PPML. The intent is to provide as fair a process > as possible for multi-homed organizations down to the smallest feasible size > while still preserving some control over growth in the routing table. > > It has been repeatedly noted that /24 multi-homers exist today with PA space > and still occupy a routing table slot, so, it is unlikely that moving this > boundary to /24 would significantly impact the routing table. > > By requiring smaller assignments to renumber and return, rather than add more > small blocks to their assignments, this policy seeks to further reduce the > chances of unnecessary growth in the routing table and encourage good aggregation > where possible. > > 9. Timetable for implementation: Immediate > > END OF TEMPLATE > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From info at arin.net Tue Aug 4 11:02:01 2009 From: info at arin.net (Member Services) Date: Tue, 04 Aug 2009 11:02:01 -0400 Subject: [arin-ppml] Multihomed Microallocations In-Reply-To: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com> References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com> Message-ID: <4A784D69.3060802@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## William Herrin wrote: > 1. Policy Proposal Name: Multihomed Microallocations > 2. Proposal Originator: William Herrin > > 3. Proposal Version: 1.0 > 4. Date: 3 August 2009 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > 4.4 IPv4 Allocations and Assignments to Small Multihomed Organizations > > 4.4.1 Section 4.4 specifies criteria for allocating /23 and /24 IPv4 > address blocks to end users and ISPs where the requesting organization > is multihomed with multiple Internet vendors but does not meet the > minimum usage criteria for address allocation or assignment under > Sections 4.2 and 4.3. > > 4.4.2 Except as specified in section 4.4, the requesting organization > must also meet all criteria for receiving addresses specified in > section 4.2 if an ISP or section 4.3 if an end user. > > 4.4.3 Criteria for allocation or assignment > > 4.4.3.1 The requesting organization must hold exactly one AS number > and must already announce IPv4 addresses to the Internet via BGP using > its AS number. > > 4.4.3.2. The requesting organization must announce IPv4 addresses to > the Internet via at least two distinct Internet vendors. > > 4.4.3.3. The requesting organization must spend at least $8000/year on > the Internet services in 4.4.3.2. > > 4.4.3.4. Upon annual renewal of the allocation or assignment received > under section 4.4, if the requesting organization fails to demonstrate > that it continues to announce IPv4 addresses to the Internet via at > least two distinct Internet vendors the allocation or assignment is > revoked and returned to ARIN. > > 4.4.3.5. The requesting organization must agree to withdraw any other > BGP routes it announces from the BGP table within 6 months of > receiving an allocation or assignment under section 4.4. If the > organization continues to receive IP addresses from its ISPs, those IP > addresses will be single-homed within the ISP's larger aggregate > announcement. > > 4.4.3.6. If the requesting organization fails to announce the > allocation or assignment received under section 4.4 to the Internet > using its AS number for at least 4 months total within a service year, > the allocation or assignment is revoked and returned to ARIN. > > 4.4.3.7. If the requesting organization already holds IPv4 addresses > directly from ARIN, from any other RIR or legacy addresses, the > organization must agree to renumber out of those addresses and > surrender them to the appropriate RIR within 6 months of receiving an > allocation or assignment under section 4.4. > > 4.4.3.8. The requesting organization agrees to return the allocation > or assignment received under section 4.4 to ARIN within 6 months of > receiving another allocation or assignment from any RIR. > > 4.4.3.9. For allocations of /23 and larger, the requesting > organization shall meet the utilization rate criteria described in > section 4.2 for ISPs and section 4.3 for end users. As /24 is the > smallest address block known to be generally routable on the Internet, > no utilization criteria will be applied to requests for a /24. > > > 8. Rationale > > The reason behind a /20 minimum assignment for single-homed orgs is > fairly straightforward: an ARIN allocation adds a route to the BGP > table which wouldn't otherwise be needed. Routes are expensive and the > cost falls into overhead since it isn't recoverable directly from the > org announcing the route. And we're not really certain how many routes > we can handle before the network falls over. So, we restrict the > availability of non-aggregable IP addresses to just very large > organizations. For smaller orgs, renumbering sucks but at least it > only costs the renumbering org, not everyone else. > > The reason behind nothing smaller than a /24 is also straightforward: > many if not most ISPs filter out BGP announcements smaller than /24. > There is tremendous inertia behind /24 as the minimum > backbone-routable quantity going back to the pre-CIDR days of class-C > addresses. So, an ARIN allocation smaller than /24 would generally be > wasted addresses, unusable on the Internet. > > But why peg multihomed orgs at /22 instead of /24? Multivendor > multihomed orgs have to announce a route anyway, regardless of whether > the addresses are from an ISP or directly from ARIN. Their routes are > not aggregable, even if assigned from ISP space. That's the way the > technology works and no new tech in the pipeline is likely to change > it. > > With load balanced server clusters and NAT you can pack a heck of a > lot of punch into a multihomed /24 if you want to. And as a community > it's to our benefit to want registrants to pack the maximum punch into > their address space: IPv4 addresses are becoming scarce. So why > restrict ARIN assignments to folks who can write papers which justify > a /22? > > FAQ > > Q. Why not just use ISP addresses if you're too small? > > A1. ISPs have conflicting requirements placed on their use of IP > addresses. They want, for example, to prevent address spoofing at > their borders by not allowing traffic from their addresses to enter > their network from another ISP. These goals conflict with multivendor > multihoming and generally make a mess when a customer wants to > multihome. > > A2. Renumbering is expensive and painful. We should require it only > when it serves a reasonable public policy goal such as reducing the > consumption of BGP routing slots. > > A3. We've seen common counterproductive situations where multihomed > end users make many discontiguous /24 announcements until they > eventually seek ARIN address space. > > Q. But aren't your routes aggregable with your ISP's routes if you use > your ISP's address space? > > A. No. For routes to be aggregable, two things must be true: > > 1. The routes must be contiguous, sharing a common network/netmask. > 2. The routes must share an identical network topology. > > In the mutlivendor multihomed case addressed by this proposal, the > routes almost never share an identical network topology. As a result > the routes can not be aggregated even if cut from the ISP's address > space. Single-homed networks are excluded from this proposal precisely > because they always share a network topology with the ISP. > > Q. Can't other organizations filter routes at the RIR minimums and > user the ISP's covering route to reach you? > > A. Maybe. With a bunch of ifs. You might not be connected to the ISP > who has the covering route, and what if he doesn't have the more > specific route to you? > > The answer is more decisive on a practical level: The author was > unable to identify any ISPs who presently both filters on RIR minimums > and chooses not to carry a default route to an upstream ISP that > doesn't filter. Hence there is no apparent route filtering value to > the RIR minimums. > > Q. What's so messy about multihoming with a cutout from an ISP's > allocation? > > A. Many things. Here are some of them: > > * As an ISP I want to drop packets from the Internet that purport to > be from my addresses (spoofed packets). I can't do that with packets > from a multihomed network: in the normal course of failure recovery or > traffic engineering, the multihomed user may originate packets to > hosts on my network using the IP addresses I assigned him, but via his > other ISPs. These packets will arrive at my Internet interfaces and if > I drop them as spoofed packets, I've broken my customer's > connectivity. > > * As an ISP I want to reject false route announcements entering my > system which purport to serve my addresses. And I want my pager to go > off and let me know someone is trying to hijack my address space. My > multihomed customer will, in some circumstances, want me to route all > packets to him via his other ISP. That means I have to accept his > route announcement from other ISPs. To do this, I have to write some > tricky filtering rules that accept his routes right smack in the > middle of the address space where I generally want to reject routes. > > * As an ISP, I want to aggregate my contiguous address space into a > single route announcement. It's part of being a good citizen: don't > waste the TCAM slots in everybody else's router. But I have to > carefully exclude my multihomed customer's routes from that > aggregation. Packets follow the more specific route. If he announces > his more specific route to his other ISP but I roll his route up into > my less specific route when I announce it then all his packets will go > to his other ISP instead of to me and I won't get paid. > > * Lots of folks disaggregate their route announcements for the purpose > of traffic engineering. Two or three hops away from their system, > those TE routes are irrelevant. In theory I should be able to filter a > lot of that out by discarding the routes smaller than the RIR minimum > allocation for that /8. That would save me money and make my routing > updates work faster. But if I try it, I end up filtering mutlihomed > customers so that I can only reach them via the ISP that assigned > their addresses. At best that damages the effectiveness of my routing. > At worst it cuts me off from sites my customers want to access when my > competitors who just accept /24 everywhere don't have a problem. Oops. > > Q. Where do the announced addresses in 4.4.3.1 come from? > > A. Most likely from one of the ISPs as described in NRPM section > 4.2.3.6. You go through the process of getting them assigned and > announced to demonstrate that you're not a poser. Then you get > addresses from ARIN under this proposal and return the 4.2.3.6 > addresses to your ISP. > > Q. What does "distinct vendors" mean? > > A. It means two different ISPs like Verizon and Sprint. Two T1s with a > single ISP can be accommodated without announcing a route into the > Internet backbone, so such a connection does not qualify for addresses > under this proposal. > > Q. $8000? What's that all about? > > A. The best available estimate of the systemic cost of carrying a > route in the Internet backbone table is around $8000/year. See > http://bill.herrin.us/network/bgpcost.html for the cost estimate. > If you're going to play in the backbone, you should really be putting > more money into the system than you're taking out. If you have two > $600 T1's then you're spending nearly twice that anyway. This limits > the folks who want to multihome their $50 DSL and cable modems. > > Q. How reliable is that estimate? Does it change? Shouldn't ARIN > routinely update that estimate rather than codifying the specific > number in the policy? > > A. In theory ARIN staff should set the number. In practice, > professional cost analysts are expensive and hard data on things like > router count is almost impossible to get anyway. Even if a more > reliable cost analysis could be produced, we still wouldn't know what > multiple of that cost was "fair" for the pay-in. 1x? 2x? 5x? Let's > just pick a number that's our best guess at fair, and move forward > with it. > > Besides, the $8k rule will probably turn out to be a non-operative > part of the policy. Companies providing $50 DSL service are > disinclined to set up BGP sessions with their customers anyway. I > include it in the name of caution so that we're proof against a deluge > of multihomed cable-modem users but I expect that with some experience > under our belts we'll find that we can safely submit a follow-on > policy proposal that removes the $8k requirement. > > Q. I have to renumber when exactly? > > A. If you have IP addresses under section 4.4, you get to announce > that one allocation or assignment to the Internet via BGP. In fact, > we'd really prefer that you only announce one single route, even if > you get a /23 or larger. You don't get to collect two assignments and > then ten discontiguous assignments and burn up the BGP table. Until > you reach the minimums in sections 4.2 or 4.3, you renumber each time > you grow large enough to justify the next bigger allocation or > assignment. Yes, that's unfortunate and painful. But burning up the > BGP table would be even more unfortunate. > > Practically speaking, you'll renumber zero or one times. Either you'll > never renumber because the /24 was enough to do the job, or when you > run out of space in your original assignment, you'll be big enough to > find a way to meet the minimum size criteria in section 4.2 or 4.3 so > that you don't have to renumber again. > > Q. But renumbering is expensive! What's the difference between having > to renumber under this proposal and having to renumber when I change > ISPs? > > A. You'll have to renumber less often if at all. The big deal is that > you don't have to renumber merely because you changed vendors and you > don't run into a sticky mess of filtering rules as ISPs try to keep > control of their address space. > > Q. Doesn't this discriminate against some kinds of multihoming? > > A. In addition to multihoming with your own AS number, its possible to > have two ISPs separately announce your addresses or announce with a > private AS number that they strip from their peer announcements. This > proposal is more than complex enough. For the sake of making > verification simple, let's just say that tiny registrants will > announce with their own AS number, period. > > Q. Does this proposal affect IPv6 allocations and assignments? > > A. It does not appear to impact ISP allocations whose criteria is > spelled out in NRPM section 6.5.1.1. It does impact end user > assignments under NRPM section 6.5.8.1. End users who qualify for > addresses under this policy will also be qualified for an IPv6 /48. > > Q. Have there been previous policy proposals to extend allocations and > assignments from ARIN to /24? > > A. Yes. See the discussions in March and April of 2007 for proposal > 2007-6. http://lists.arin.net/pipermail/arin-ppml/ > > In proposal 2007-6, the /22 size for multihomers in section 4.3 was > simply changed to /24. It met the following criticisms: > > * Could make it easier for spammers. This seems to reflect some > concern at the time over whether ARIN's policies made things easy for > spammers to hop IP addresses and was probably a red herring. Spammers > aren't interested in registering with anybody. They want address space > as anonymously as possible for as long as possible as cheaply as > possible exerting as little effort as possible. All of these things > make address space under this proposal unattractive to spammers. > > * Could create a land rush. This seems like an unreasonable concern > for the instant proposal: anyone who can justify addresses under this > proposal can justify the same addresses from their ISP already. So why > hassle them with ISP addresses? > > * Could create a new swamp. The renumbering requirements in this > proposal prevent that problem. > > * Unfair to ISPs since it only applies to end users. This proposal > applies to both. > > * Staff worried that it could increase request workload. If it does, > the fees could presumably be set accordingly. > > Proposal 2007-6 also tried to make the following point: Don't penalize > the honest. An org that has ponied up the cash to be multihomed with > multiple vendors can often restructure their network to require a /22 > long enough to get one. Refusing ARIN assignments smaller than /22 > encourages behavior which is contrary to ARIN's general public policy > goal of conservation. We'll be better off as a community if the folks > who are completely honest about their need get the same or better > treatment than the ones who lie. > > > Implementation notes: > > This proposal asks for verification of multihoming somewhat beyond > what the rest of the NRPM requires. It does this in order to prevent a > land rush of cheaters. Not that there's likely to be a land rush of > cheaters (or if there is that they're likely to ask for less than a > /22), but better safe than sorry. > > Verifying that there's a BGP announcement is trivial: go to any of the > hundreds of looking glasses. For the four-month rule, staff may want > to let it be practiced in the breach for now. That is, don't go out > and look unless someone complains. Writing software that actively > checks for it can be part of the address recovery strategy after > depletion. > > Same deal with the route withdrawals: if slot consumption bugs the > ISPs, let them write a script which trolls for cheaters and then > complain. > > To verify multihoming, I would suggest asking the registrant to > provide a letter of service from two ISPs in which they indicate that > they're under contract to announce routes for AS XXX. > > To verify $8k, you might ask for a month's bills and check that 12 > months worth adds up to $8k. > > There's a respectable chance that folks requesting a /23 or larger > will continue to grow. It would be nice if ARIN staff made reasonable > efforts to reserve adjacent space for a year or so they may be able to > get the next larger size without having to renumber. With the scarcity > of IPv4 addresses this won't always be possible, but it would be good > to do as a "best efforts" kind of thing. . > > > 9. Timetable for implementation: immediate > > > From info at arin.net Wed Aug 12 08:18:19 2009 From: info at arin.net (Member Services) Date: Wed, 12 Aug 2009 08:18:19 -0400 Subject: [arin-ppml] New version of Proposal 99 In-Reply-To: <24BFD428-23BC-404C-AC67-7554EFE7D547@delong.com> References: <24BFD428-23BC-404C-AC67-7554EFE7D547@delong.com> Message-ID: <4A82B30B.5050704@arin.net> Policy Proposal 99 /24 End User Minimum Allocation Unit The proposal originator submitted a revised version of the proposal. The AC will review this proposal at their next regularly scheduled meeting and decide how to utilize the proposal. Their decision will be announced to the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) Owen DeLong wrote: > The proposal below is intended to clarify some things and address the > comments and > questions from staff in their clarity and understanding document. > > Comments, suggestions, and feedback are welcome. > > Owen > > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: /24 End User Minimum Allocation Unit 2. > Proposal Originator > a. name: Owen DeLong > b. email: owen at delong.com > c. telephone: 408-890-7992 > d. organization: Hurricane Electric > > 3. Proposal Version: 1.0 > 4. Date: 8/11/09 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection > > For multi-homed end-users who demonstrate an intent to announce the > requested space in a multihomed fashion to two or more distinct ASNs > not owned or controlled by the end-user, the minimum block of IP > address space assigned is a /24. If assignments smaller than a /24 are > needed, multihomed end-users should contact their upstream providers. > When prefixes are assigned which are longer than /20, they will be > from a block reserved for that purpose so long as that is feasible. > End-users may not receive a block smaller than /22 under this policy > if they already have IPv4 resources from ARIN, except as specified in > section 4.3.6.2. > > Renumber the existing paragraph under the 4.3.6 to > > 4.3.6.1 Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Replacement assignments for small multi-homers > > Any end-user that possesses an assignment smaller than /22 under any > part of section 4.3 shall not be able to get an additional assignment > unless they agree to return all existing assignments within 12 months > of receiving a new assignment. The new assignment shall be sized to > accommodate their existing utilization in addition to their justified > additional growth space under section 4.3.6.1. The common cases for > this are expected to be a /24 returned after receipt of a /23, or a > /23 returned after receipt of a /22. > > 8. Rationale: > > This policy attempts to incorporate the recent and historical > discussions of policy for multi-home users on PPML. The intent is to > provide as fair a process as possible for multi-homed organizations > down to the smallest feasible size while still preserving some control > over growth in the routing table. > > It has been repeatedly noted that /24 multi-homers exist today with PA > space and still occupy a routing table slot, so, it is unlikely that > moving this boundary to /24 would significantly impact the routing table. > > By requiring smaller assignments to renumber and return, rather than > add more small blocks to their assignments, this policy seeks to > further reduce the chances of unnecessary growth in the routing table > and encourage good aggregation where possible. > > FAQs and responses to Staff Questions > > Does this apply only to end users? Yes, this policy applies only to > end users. This policy does not represent a good solution for > organizations that are delegating space to other entities. If a case > can be made that such a policy is needed for ISPs, then, the author is > happy to work with interested parties to craft such a policy, but, > this policy would be unnecessarily onerous on ISPs, and, as an ISP > policy could be somewhat onerous to their peers and/or upstream > providers. > > What about resources obtained from policies other than 4.3 or outside > of ARIN? Such resources would not be counted for excluding an > organization from this policy. The intent is to limit IPv4 > micro-allocations for multi-homed end-user organizations under this > policy to a single assignment unless each such assignment is /22 or > larger. This is to prevent unnecessary routing table growth. This is a > tradeoff, and, not the ideal solution for smaller end-user > organizations, however, author believes that this is the best policy > likely to gain consensus at this time and believes that it is > incrementally far better for such organizations than current policy. > > If I grow, I have to renumber? Not necessarily... If you have a /24 > under this policy, and you want to grow that, then, you will likely > need to renumber. Depending on ARIN resource management and timing, > ARIN may simply be able to give you the /23 that includes your /24. > More likely, you will get a new /23, have 1 year to renumber into that > and return your /24. At most, you would be subject to two such > renumbering cycles under this policy (24->23 and 23->22) before you > meet the criteria for other policies which do not require renumbering. > > Other policies don't include renumbering provisions, why this one? The > policy which allows multi-homed organizations to get a /22 was > originally written at /24. That policy was shouted down and /22 was > the compromise achieved to gain community consensus for anything > smaller than /20. Author hopes that this compromise will allow many > organizations to get resources they need with minimal impact while > assuring the community that doing so will not cause an explosion in > the routing table. > > 9. Timetable for implementation: Immediate > > END OF TEMPLATE > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From info at arin.net Wed Aug 26 13:44:30 2009 From: info at arin.net (Member Services) Date: Wed, 26 Aug 2009 13:44:30 -0400 Subject: Advisory Council Meeting Results - August 2009 Message-ID: <4A95747E.1090204@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 20 August 2009 and made decisions about several policy proposals and draft policies. I. The AC selected the following proposals and changed them into draft policies for adoption discussion online and at the upcoming Public Policy Meeting. The draft policies will be posted shortly to the PPML. Policy Proposal 89 (Global): Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Policy Proposal 90: Open Access To IPv6 Policy Proposal 93: Equitable IPv4 Run Out II. The AC selected the following draft policy for adoption discussion online and at the upcoming Public Policy Meeting. It will be posted shortly to the PPML. Draft Policy 2009-3: (Global): Allocation of IPv4 Blocks to Regional Internet Registries III. The AC used portions of ?Policy Proposal 94: Predictable IPv4 Run Out by Allocation Window? to help with the creation of the ?Equitable IPv4 Run Out.? The AC considers proposal 94 to be closed. IV. The AC abandoned ?Policy Proposal 96: Transfer Listing Service.? The AC suggested that the President direct this matter through the ARIN Consultation and Suggestion Process. V. The AC decided to defer discussion of ?Policy Proposal 97: Waiting List for Unmet IPv4 Requests? until after the October Public Policy Meeting. VI. The AC accepted the following proposals on to the AC's docket for development and evaluation. There is not an adequate amount of time to create and publish draft policies in time for the October Public Policy Meeting. Policy Proposal 98: Last Minute Assistance for Small ISPs Policy Proposal 99: /24 End User Minimum Allocation Unit VII. The AC abandoned ?Policy Proposal 100: Multihomed Microallocations.? VIII. The AC sent a revised ?2008-3: Community Networks IPv6 Assignment? to an extended last call. The text will be posted shortly to the PPML. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? Several of the AC?s decisions above resulted in proposals not being selected for adoption discussion. The purpose of a petition would be to change a proposal into a draft policy for discussion on the Public Policy Mailing List and at the October meeting. The deadline to begin a petition is 2 September 2009. The following can be petitioned (status in parens): Policy Proposal 94: Predictable IPv4 Run Out by Allocation Window (merged and closed) Policy Proposal 96: Transfer Listing Service (abandoned) Policy Proposal 97: Waiting List for Unmet IPv4 Requests (delayed) Policy Proposal 98: Last Minute Assistance for Small ISPs (added to AC?s docket) Policy Proposal 99: /24 End User Minimum Allocation Unit (added to AC?s docket) Policy Proposal 100: Multihomed Microallocations (abandoned) For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts under discussion are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Aug 26 13:48:52 2009 From: info at arin.net (Member Services) Date: Wed, 26 Aug 2009 13:48:52 -0400 Subject: =?windows-1252?Q?Draft_Policy_2008-3=3A_Community_Networ?= =?windows-1252?Q?ks_IPv6_Assignment_=96_Last_Call?= Message-ID: <4A957584.4040608@arin.net> Draft Policy 2008-3 Community Networks IPv6 Assignment On 20 August 2009 the ARIN Advisory Council (AC) decided to send an updated version of Draft Policy 2008-3 to a 21-day last call. ?The ARIN Advisory Council, based on comments from stakeholders expressed at the last three ARIN Public Policy Meetings (ARIN XXI, ARIN XXII and ARIN XXIII) and on the ARIN Public Policy Mailing List, having reviewed the comments collected, as well as the latest ARIN staff and legal reviews; and, updated the policy accordingly, and noting that the Policy Development Process has been followed, finds Advisory Council and Community support for Draft Policy 2008-3: Community Networks IPv6 Assignment, and moves to it to a 21-day extended Last Call.? Feedback is encouraged during this last call period. All comments must be provided to the Public Policy Mailing List. This last call will expire at 2:00 PM EDT, 17 September 2009. The policy proposal text is provided below and is also available at: https://www.arin.net/policy/proposals/2008_3.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2008-3 Community Networks IPv6 Assignment Date: 19 August 2009 Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a non-profit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA, or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Assignments 6.5.9.1 Qualification Criteria To qualify for a direct assignment, a community network must demonstrate it will immediately provide sustained service to at least 100 simultaneous users and must demonstrate a plan to provide sustained service to at least 200 simultaneous users within one year. For community networks located in rural regions (population less than 2,500) or in the Caribbean and North Atlantic Islands Sector, the numbers in these qualification criteria may be relaxed at ARIN's discretion. 6.5.9.2. Initial assignment size The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation of the characteristics of the Community Network's size and architecture that require the use of additional subnets. An HD-Ratio of .94 with respect to subnet utilization within the network must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. 6.5.9.3. Subsequent assignment size Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on a detailed plan of the network's architecture and the .94 HD-Ratio metric. When possible, assignments will be made from an aggregatable adjacent address block. Rationale: This policy was originally proposed by community network operators to provide them with the ability to receive a direct assignment of IPv6 address resources from ARIN. The operators of such networks have expressed their need to have a stable and globally unique address assignment with which to number their network infrastructure. Many such networks are not able to meet the current criteria for a PI IPv6 assignment from ARIN. in an environment where connections to outside networks may come and go, a stable internal address structure would be very valuable. Additionally, the ability to exchange routes with others, whether locally or tunneled, and thereby have native IPv6 connectivity, would be quite beneficial. These operators were also hopeful that, once this new class of address assignments was created, they could pursue lower annual fees for community networks through the ARIN Consultation and Suggestion Process (ACSP). There could also be a number of potential benefits to allowing community network participants to begin using IPv6 addressing. Some of these networks have many technically capable and adventurous members who would be motivated to begin developing and/or experimenting with the software extensions which will be needed to support IPv6 prefix selection among multiple IPv6 prefixes when establishing remote connections. Also, participants in networks receiving such assignments will have the necessary global-ID to experiment with the various proposals currently being developed for separating network locater from network ID. Also, during the more than one year timeframe that this policy has been under consideration, other people have suggested other scenarios where community networks would provide a valuable resource. One such proposal was discussed at one of the Caribbean Sector meetings where some participants pointed out the efforts were being made in remote or sparsely populated areas to establish community networks which would serve as connections back to educational resources for distant learning capabilities. There are also many still wild areas of North America where such community networks could provide improved connectivity over telephone modems. Timetable for implementation: Immediate. From info at arin.net Thu Aug 27 14:08:17 2009 From: info at arin.net (Member Services) Date: Thu, 27 Aug 2009 14:08:17 -0400 Subject: Policy Proposal 97: Waiting List for Unmet IPv4 Requests - Deferred In-Reply-To: <4A95747E.1090204@arin.net> References: <4A95747E.1090204@arin.net> Message-ID: <4A96CB91.4080201@arin.net> Policy Proposal 97 Waiting List for Unmet IPv4 Requests Member Services wrote: > V. The AC decided to defer discussion of ?Policy Proposal 97: Waiting > List for Unmet IPv4 Requests? until after the October Public Policy > Meeting. The AC deferred Policy Proposal 97 based in part on feedback the AC received from the ARIN staff and legal assessment. The AC asked that staff post the assessment (below) to PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Staff Assessment Proposal: Waiting List for Unmet IPv4 Requests Proposal Version (Date): 28 July 2009 Date of Assessment: 14 Aug 2009 1. Proposal Summary (Staff Understanding) Staff understands that this proposal would alter ARIN's current address issuing procedures and instead require the issuing of a single, contiguous address prefix for each approved IPv4 request. It would create a waiting list for requesters whose IPv4 address needs cannot be fulfilled by ARIN at the time of the request approval and includes policy text to prevent requesters from gaming the policy's intent by forbidding requesters from making multiple requests of a small size. 2. Comments A. ARIN Staff Comments * 4.1.6 - As written, this would significantly change ARIN?s current system of inventory management. Currently, allocations are issued to ISPs, and where relevant, space is reserved to account for the ISP's one-year need. This maximizes aggregation possibilities in keeping with ARIN's primary mission of promoting both address conservation and route aggregation. The text, as written, would force staff to stop this practice, and likely cause more de-aggregation (not less) in the immediate future. In addition, the proposal would preclude utilization (where suitable) of multiple smaller address blocks to meet a request, even if the requester knows that such addresses will not be routed to the Internet. The hard requirement for satisfying requests via a single, contiguous address prefix can therefore result in a less efficient utilization of IPv4 address space than otherwise possible. * 4.1.8 ? The term "repeated requests" will need to be defined and business procedures developed accordingly. The expected behavior upon request denial would be for an ISP to submit a revised request for smaller block, and this would naturally result in having to apply again at a future date for the remainder of the space. It is not clear under the present draft if this would be considered ?circumvention of 4.1.6? or not. B. ARIN General Counsel At the current time counsel cannot complete evaluation of this policy. While avoiding de-aggregation can be an important value to the community, from a legal standpoint it remains unclear whether this policy inappropriately elevates that single virtue, i.e., preserving the efficiency of routing while failing to address other simultaneous aspects of run-out. This policy may create significant and serious implementation problems that could lead to ?gaming? activity and a multiplicity of requests designed to circumvent this policy at a time when litigation may result from any real or perceived unfairness in management of scarce IPv4 resources. An alternative way of restating this concern is to focus on the following statement at the end of the policy: ?This policy does not attempt to ration addresses, define maximum allocations, or otherwise manage how much address space any given organization may request. As such, it is completely independent of any "Predictable IPv4 Run Out" proposals.? Counsel wishes to understand whether it is operationally and legally necessary to integrate multiple policy concerns and community needs simultaneously in an integrated proposal, i.e. it may not be possible to create equitable policy for a waiting list which includes a single-block assignment requirement without also considering these other policy concerns. 3. Resource Impact This policy would have moderate resource impact. It is estimated that implementation would occur within 6 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Software developed to monitor allocations, and modifications to the management web application * Changes to current business processes * Updated guidelines * Staff training 4. Proposal Text Waiting list for unmet IPv4 requests Version: 28 July 2009 Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. ARIN will make all allocations and assignments as a single continuous range of addresses. Add new section 4.1.8: 4.1.8 Unmet requests In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to either modify their request and request a smaller size block, or be placed on a waiting list of pre-qualified recipients. Repeated requests, in a manner that would circumvent 4.1.6, are not allowed. Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 4.1.8.1 Waiting list The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. 4.1.8.2 Fulfilling unmet needs As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. Rationale: ARIN will soon be unable to meet all approved requests for IPv4 address space. In the absence of a policy like this, it is unclear what ARIN should do with subsequent requests. This policy would allocate reclaimed address blocks (and the last of the ARIN free pool) on a first-come-first-served basis, while preserving aggregation to the degree possible. As the free pool shrinks, requests larger than the largest block left would be placed on a waiting list, while smaller requests would use up the rest of it, until all requests have to go on the waiting list. As additional reclaimed addresses become available, the requests that have been waiting the longest would be met first. If a requester gets the addresses they need via transfer, then they would be removed from the waiting list and would need to wait and submit a new request for additional address space, either directly or via transfer. This policy does not attempt to ration addresses, define maximum allocations, or otherwise manage how much address space any given organization may request. As such, it is completely independent of any "Predictable IPv4 Run Out" proposals. Member Services wrote: > In accordance with the ARIN Policy Development Process the ARIN Advisory > Council (AC) held a meeting on 20 August 2009 and made decisions about > several policy proposals and draft policies. > > I. The AC selected the following proposals and changed them into draft > policies for adoption discussion online and at the upcoming Public > Policy Meeting. The draft policies will be posted shortly to the PPML. > > Policy Proposal 89 (Global): Internet Assigned Numbers Authority (IANA) > Policy for Allocation of ASN Blocks (ASNs) to Regional Internet > Registries > > Policy Proposal 90: Open Access To IPv6 > > Policy Proposal 93: Equitable IPv4 Run Out > > II. The AC selected the following draft policy for adoption discussion > online and at the upcoming Public Policy Meeting. It will be posted > shortly to the PPML. > > Draft Policy 2009-3: (Global): Allocation of IPv4 Blocks to Regional > Internet Registries > > III. The AC used portions of ?Policy Proposal 94: Predictable IPv4 Run > Out by Allocation Window? to help with the creation of the ?Equitable > IPv4 Run Out.? The AC considers proposal 94 to be closed. > > IV. The AC abandoned ?Policy Proposal 96: Transfer Listing Service.? The > AC suggested that the President direct this matter through the ARIN > Consultation and Suggestion Process. > > V. The AC decided to defer discussion of ?Policy Proposal 97: Waiting > List for Unmet IPv4 Requests? until after the October Public Policy > Meeting. > > VI. The AC accepted the following proposals on to the AC's docket for > development and evaluation. There is not an adequate amount of time to > create and publish draft policies in time for the October Public Policy > Meeting. > > Policy Proposal 98: Last Minute Assistance for Small ISPs > > Policy Proposal 99: /24 End User Minimum Allocation Unit > > VII. The AC abandoned ?Policy Proposal 100: Multihomed Microallocations.? > > VIII. The AC sent a revised ?2008-3: Community Networks IPv6 Assignment? > to an extended last call. The text will be posted shortly to the PPML. > > The PDP states, ?Any member of the community, including a proposal > originator, may initiate a Discussion Petition if they are dissatisfied > with the action taken by the Advisory Council regarding any specific > policy proposal.? Several of the AC?s decisions above resulted in > proposals not being selected for adoption discussion. The purpose of a > petition would be to change a proposal into a draft policy for > discussion on the Public Policy Mailing List and at the October meeting. > The deadline to begin a petition is 2 September 2009. > > The following can be petitioned (status in parens): > > Policy Proposal 94: Predictable IPv4 Run Out by Allocation Window > (merged and closed) > > Policy Proposal 96: Transfer Listing Service (abandoned) > > Policy Proposal 97: Waiting List for Unmet IPv4 Requests (delayed) > > Policy Proposal 98: Last Minute Assistance for Small ISPs (added to AC?s > docket) > > Policy Proposal 99: /24 End User Minimum Allocation Unit (added to AC?s > docket) > > Policy Proposal 100: Multihomed Microallocations (abandoned) > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Policy Proposal texts under discussion are available > at: https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From info at arin.net Thu Aug 27 14:08:48 2009 From: info at arin.net (Member Services) Date: Thu, 27 Aug 2009 14:08:48 -0400 Subject: =?windows-1252?Q?Re=3A_=5Barin-ppml=5D_Draft_Policy_2008?= =?windows-1252?Q?-3=3A_Community_Networks_IPv6_Assignment_=96_?= =?windows-1252?Q?Last_Call?= In-Reply-To: <4A957584.4040608@arin.net> References: <4A957584.4040608@arin.net> Message-ID: <4A96CBB0.3040005@arin.net> Draft Policy 2008-3 Community Networks IPv6 Assignment 2008-3 (version dated 19 August 2009) is in last call. Prior to moving it to last call the AC asked for a staff assessment. Staff provided the assessment to the AC. The AC reviewed the assessment and made several revisions to the text. The AC moved the revised text to last call. The AC asked staff to post the assessment (below) to PPML to help with discussion. Regards, Member Services American Registry for Internet Numbers (ARIN) ##### Staff Assessment 2008-3 Community Networks IPv6 Assignment Proposal Version (Date): 31 July 2009 Date of Assessment: 08-18-09 1. Proposal Summary (Staff Understanding) Staff understand this policy defines a community network as providing free or low-cost connectivity, operating as or under the fiscal support of a non-profit or university, and run entirely by volunteers. This policy would allow community network operators to request an IPv6 assignment of /48 or larger by demonstrating that they would service at least 100 users immediately and 200 users within one year. In addition, this policy directs ARIN staff to use discretion when reviewing requests from rural regions, the Caribbean and North Atlantic Sector. 2. Comments A. ARIN Staff Comments The policy can be implemented as written. NRPM section 6.5.8.1.b was revised on 5 August 2008 by an unrelated proposal (2007-21). The proposed text for 6.5.8.1.b needs to be updated to reflect the current version of the NRPM (otherwise it would revoke 2007-21). ARIN staff would prefer criteria over discretion. Instead of discretion, the policy could give clear criteria for requests from rural regions, the Caribbean and North Atlantic Sector. For example, 50 users now and 100 in a year (or 25/50, 10/20, etc). The policy would add the term ?rural? to the NRPM. We suggest putting ?(population less than 2,500)? after the word ?rural regions?. The US Census Bureau definition: ?All persons living in [urban areas] and in places (cities, towns, villages, etc.) with a population of 2,500 or more outside of [urban areas] are considered the urban population. All others are considered rural.? B. ARIN General Counsel Counsel sees no material legal or litigation issues related to this policy. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Updated guidelines Staff training 4. Proposal Text 2008-3 Community Networks IPv6 Assignment Date: 31 July 2009 Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a non-profit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Assignments 6.5.9.1 Qualification Criteria To qualify for a direct assignment, a community network must demonstrate it will immediately provide sustained service to at least 100 simultaneous users and must demonstrate a plan to provide sustained service to at least 200 simultaneous users within one year. For community networks located in rural regions or in the Caribbean and North Atlantic Islands Sector, the numbers in these qualification criteria may be relaxed at ARIN's discretion. 6.5.9.2. Initial assignment size The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation of the characteristics of the Community Network's size and architecture that require the use of additional subnets. An HD-Ratio of .94 with respect to subnet utilization within the network must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. 6.5.9.3. Subsequent assignment size Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on a detailed plan of the network's architecture and the .94 HD-Ratio metric. When possible, assignments will be made from an aggregatable adjacent address block. Rationale: this policy was originally proposed by community network operators to provide them with the ability to receive a direct assignment of IPv6 address resources from ARIN. the operators of such networks have expressed their need to have a stable and globally unique address assignment with which to number their network infrastructure. many such networks are not able to meet the current criteria for a PI IPv6 assignment from ARIN. in an environment where connections to outside networks may come and go, a stable internal address structure would be very valuable. additionally, the ability to exchange routes with others, whether locally or tunneled, and thereby have native IPv6 connectivity, would be quite beneficial. these operators were also hopeful that, once this new class of address assignments was created, they could pursue lower annual fees for community networks through the ARIN Consultation and Suggestion Process (ACSP). there could also be a number of potential benefits to allowing community network participants to begin using IPv6 addressing. some of these networks have many technically capable and adventurous members who would be motivated to begin developing and/or experimenting with the software extensions which will be needed to support IPv6 prefix selection among multiple IPv6 prefixes when establishing remote connections. also, participants in networks receiving such assignments will have the necessary global-ID to experiment with the various proposals currently being developed for separating network locater from network ID. also, during the more than one year timeframe that this policy has been under consideration, other people have suggested other scenarios where community networks would provide a valuable resource. one such proposal was discussed at one of the Caribbean Sector meetings where some participants pointed out the efforts were being made in remote or sparsely populated areas to establish community networks which would serve as connections back to educational resources for distant learning capabilities. there are also many still wild areas of North America where such community networks could provide improved connectivity over telephone modems. Timetable for implementation: Immediate. Member Services wrote: > Draft Policy 2008-3 > Community Networks IPv6 Assignment > > On 20 August 2009 the ARIN Advisory Council (AC) decided to send an > updated version of Draft Policy 2008-3 to a 21-day last call. > > ?The ARIN Advisory Council, based on comments from stakeholders > expressed at the last three ARIN Public Policy Meetings (ARIN XXI, ARIN > XXII and ARIN XXIII) and on the ARIN Public Policy Mailing List, having > reviewed the comments collected, as well as the latest ARIN staff and > legal reviews; and, updated the policy accordingly, and noting that the > Policy Development Process has been followed, finds Advisory Council and > Community support for Draft Policy 2008-3: Community Networks IPv6 > Assignment, and moves to it to a 21-day extended Last Call.? > > Feedback is encouraged during this last call period. All comments must > be provided to the Public Policy Mailing List. This last call will > expire at 2:00 PM EDT, 17 September 2009. > > The policy proposal text is provided below and is also available at: > https://www.arin.net/policy/proposals/2008_3.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2008-3 > Community Networks IPv6 Assignment > > Date: 19 August 2009 > > Policy statement: > > [Add Section 2.8 to the NRPM.] > > 2.8 Community Network > > A community network is any network organized and operated by a volunteer > group operating as or under the fiscal support of a non-profit > organization or university for the purpose of providing free or low-cost > connectivity to the residents of their local service area. To be treated > as a community network under ARIN policy, the applicant must certify to > ARIN that the community network staff is 100% volunteers. > > [Modify 6.5.8.1b as follows.] > > b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 > policy currently in effect, or demonstrate efficient utilization of all > direct IPv4 assignments and allocations, each of which must be covered > by any current ARIN RSA, or be a qualifying Community Network as defined > in Section 2.8, with assignment criteria defined in section 6.5.9. > > [Add Section 6.5.9 to the NRPM.] > > 6.5.9 Community Network Assignments > > 6.5.9.1 Qualification Criteria > > To qualify for a direct assignment, a community network must demonstrate > it will immediately provide sustained service to at least 100 > simultaneous users and must demonstrate a plan to provide sustained > service to at least 200 simultaneous users within one year. For > community networks located in rural regions (population less than 2,500) > or in the Caribbean and North Atlantic Islands Sector, the numbers in > these qualification criteria may be relaxed at ARIN's discretion. > > 6.5.9.2. Initial assignment size > > The minimum size of the assignment is /48. Organizations requesting a > larger assignment must provide documentation of the characteristics of > the Community Network's size and architecture that require the use of > additional subnets. An HD-Ratio of .94 with respect to subnet > utilization within the network must be met for all assignments larger > than a /48. These assignments shall be made from a distinctly identified > prefix and shall be made with a reservation for growth of at least a > /44. This reservation may be assigned to other organizations later, at > ARIN's discretion. > > 6.5.9.3. Subsequent assignment size > > Additional assignments may be made when the need for additional subnets > is justified. Justification will be determined based on a detailed plan > of the network's architecture and the .94 HD-Ratio metric. When > possible, assignments will be made from an aggregatable adjacent address > block. > > Rationale: > > This policy was originally proposed by community network operators to > provide them with the ability to receive a direct assignment of IPv6 > address resources from ARIN. The operators of such networks have > expressed their need to have a stable and globally unique address > assignment with which to number their network infrastructure. Many such > networks are not able to meet the current criteria for a PI IPv6 > assignment from ARIN. in an environment where connections to outside > networks may come and go, a stable internal address structure would be > very valuable. Additionally, the ability to exchange routes with others, > whether locally or tunneled, and thereby have native IPv6 connectivity, > would be quite beneficial. These operators were also hopeful that, once > this new class of address assignments was created, they could pursue > lower annual fees for community networks through the ARIN Consultation > and Suggestion Process (ACSP). > > There could also be a number of potential benefits to allowing community > network participants to begin using IPv6 addressing. Some of these > networks have many technically capable and adventurous members who would > be motivated to begin developing and/or experimenting with the software > extensions which will be needed to support IPv6 prefix selection among > multiple IPv6 prefixes when establishing remote connections. Also, > participants in networks receiving such assignments will have the > necessary global-ID to experiment with the various proposals currently > being developed for separating network locater from network ID. > > Also, during the more than one year timeframe that this policy has been > under consideration, other people have suggested other scenarios where > community networks would provide a valuable resource. One such proposal > was discussed at one of the Caribbean Sector meetings where some > participants pointed out the efforts were being made in remote or > sparsely populated areas to establish community networks which would > serve as connections back to educational resources for distant learning > capabilities. There are also many still wild areas of North America > where such community networks could provide improved connectivity over > telephone modems. > > Timetable for implementation: Immediate. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From info at arin.net Mon Aug 31 11:38:39 2009 From: info at arin.net (Member Services) Date: Mon, 31 Aug 2009 11:38:39 -0400 Subject: Draft Policy 2009-6 (Global): IANA Policy for Allocation of ASNs to RIRs Message-ID: <4A9BEE7F.8090802@arin.net> Draft Policy 2009-6 (Global) Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries On 20 August 2009 the ARIN Advisory Council (AC) selected "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Dearborn. The draft was developed by the AC from "Policy Proposal 89. (Global) Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. After reviewing the assessment the AC did not change the text. Draft Policy 2009-6 is below and can be found at: https://www.arin.net/policy/proposals/2009_6.htm Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. You are encouraged to discuss Draft Policy 2009-6 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-6 (Global) Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Version/Date: 31 August 2009 Policy statement: Modification of NRPM section 10.3 extending the deadline for an undifferentiated ASN pool by 1 year to read: 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool. Rationale: a. Arguments supporting the proposal Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR's pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year. With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage. The subject was raised during RIPE 58 and a presentation was made: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf The feedback in this session suggested that a global policy proposal should be developed and should be discussed. b. Arguments opposing the proposal Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed. Timetable for implementation: Immediately upon ratification by ICANN Board ##### Staff Assessment Proposal: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Proposal Version (Date): 27 May 2009 Date of Assessment: 08-18-09 1. Proposal Summary (Staff Understanding) This is a global proposal. It modifies section 10.3 of the NRPM to extend the current deadline for an undifferentiated pool of ASNs from Dec 31, 2009 to Dec 31, 2010. This proposal would allow IANA to issue the RIRs blocks of both 16-bit ASNs and 32-bit ASNs until Dec 31, 2010. After that time, no distinction would be made between the two types of ASNs, and all ASNs would be allocated from a 32-bit pool. 2. Comments A. ARIN Staff Comments The policy can be implemented as written. The policy would completely remove the word ?byte? from the NRPM in favor of the term ?bit?. B. ARIN General Counsel Counsel does not see any material legal issues related to this policy. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Updated guidelines Staff training 4. Proposal Text Policy Proposal Name: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Date: 27 May 2009 Policy statement: Modification of NRPM section 10.3 extending the deadline for an undifferentiated ASN pool by 1 year to read: 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool. Rationale: a. Arguments supporting the proposal Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR's pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year. With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage. The subject was raised during RIPE 58 and a presentation was made: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf The feedback in this session suggested that a global policy proposal should be developed and should be discussed. b. Arguments opposing the proposal Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed. Timetable for implementation: Immediately upon ratification by ICANN Board From info at arin.net Mon Aug 31 11:39:06 2009 From: info at arin.net (Member Services) Date: Mon, 31 Aug 2009 11:39:06 -0400 Subject: Draft Policy 2009-7: Open Access To IPv6 Message-ID: <4A9BEE9A.2000405@arin.net> Draft Policy 2009-7 Open Access To IPv6 On 20 August 2009 the ARIN Advisory Council (AC) selected "Open Access To IPv6" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Dearborn. The draft was developed by the AC from "Policy Proposal 90: Open Access To IPv6". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. After reviewing the assessment the AC did not change the text. Draft Policy 2009-7 is below and can be found at: https://www.arin.net/policy/proposals/2009_7.htm Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. You are encouraged to discuss Draft Policy 2009-7 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-7 Open Access To IPv6 Version/Date: 31 August 2009 Policy statement: 1) Remove ?by advertising that connectivity through its single aggregated address allocation? from article 3 of section 6.5.1.1 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years? in its entirety. Rationale: It is acknowledged that these concepts have been put before the community in the past. However, with the wisdom of actual operational experience, the necessity of promoting IPv6 adoption throughout our region, and emerging native v6 only network models, it becomes obvious that these modifications to the NRPM are necessary. Removing the 200 end site requirement enables smaller, but no less important and viable, networks access to IPv6. Removing the ?known ISP? requirement enfranchises new, native v6 businesses that can drive innovation and expansion in the Internet industry, as well as other industries. Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification ##### ##### Staff Assessment Proposal: Open Access to IPv6 (proposal #90) Proposal Version (Date) 21 May 2009 Date Assessment Due: 05 Aug 2009 1. Proposal Summary (Staff Understanding) This policy proposal would modify NRPM section 6.5.1.1 by removing all or part of two initial criteria from the the existing IPv6 policy: the requirement to advertise the single aggregate and the requirement to plan on making 200 end site assignments to customers or be a known ISP in the ARIN region. The only remaining criteria to qualify for an IPv6 allocation are to be an LIR/ISP, not be an end site, and plan on providing IPv6 connectivity to organizations and assigning them IPv6 address space. 2. Comments A. ARIN Staff Comments * This policy would essentially remove all criteria for obtaining IPv6 address space, making it possible for any organization that claims to be an ISP, and who may have very few, or perhaps no customers, to get a /32 allocation directly from ARIN. * It may be viewed as unfair in that any ISP, regardless of size, will now be able to come to ARIN for a /32 with little or no justification, while other large enterprise organizations that are very well known to ARIN (i.e. Hewlett Packard) need to provide detailed justification to obtain any assignment larger than a /48. B. ARIN General Counsel Counsel believes this policy is unwise as a legal matter, but will not recommend the Board refuse to enable it. The flaw is that the policy is so permissive that fraudulent application to obtain resources will be made and cannot be stopped because the policy's criterion are so heavily weighted to issuance, and the criterion for issuance so limited that the mere assertion one is an ISP, albeit without customers, could lead to issuance of resources, unless I am misreading the proposed policy. While encouraging small business or start ups is important, I believe this policy will improperly encourage and permit fraud in the issuance of small blocs of IPv6 addresses. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within three months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines * Staff training 4. Proposal Text Policy Proposal Name: Open Access To IPv6 Version/Date: 21 May 2009 Policy statement: 1) Remove ?by advertising that connectivity through its single aggregated address allocation? from article 3 of section 6.5.1.1 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years? in its entirety. Rationale: It is acknowledged that these concepts have been put before the community in the past. However, with the wisdom of actual operational experience, the necessity of promoting IPv6 adoption throughout our region, and emerging native v6 only network models, it becomes obvious that these modifications to the NRPM are necessary. Removing the 200 end site requirement enables smaller, but no less important and viable, networks access to IPv6. Removing the ?known ISP? requirement enfranchises new, native v6 businesses that can drive innovation and expansion in the Internet industry, as well as other industries. Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification From info at arin.net Mon Aug 31 11:39:29 2009 From: info at arin.net (Member Services) Date: Mon, 31 Aug 2009 11:39:29 -0400 Subject: Draft Policy 2009-8: Equitable IPv4 Run-Out Message-ID: <4A9BEEB1.2070708@arin.net> Draft Policy 2009-8 Equitable IPv4 Run-Out On 20 August 2009 the ARIN Advisory Council (AC) selected "Equitable IPv4 Run-Out" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Dearborn. The draft was developed by the AC from Policy Proposals "93: Predicable IPv4 Run Out by Prefix Size and 94: Predictable IPv4 Run Out by Allocation Window". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. After reviewing the assessment the AC made several changes to the text. Draft Policy 2009-8 is below and can be found at: https://www.arin.net/policy/proposals/2009_8.htm Below the draft policy is the ARIN staff and legal assessment, including the original proposal text. You are encouraged to discuss Draft Policy 2009-8 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-8 Equitable IPv4 Run-Out Version/Date: 31 August 2009 Policy statement: Replace NRPM 4.2.4.4 with; 4.2.4.4 Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses. As the IANA free pool decreases, the length of supply that an organization may request will be reduced at the following thresholds. This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12 month supply of IP addresses. When IANA reaches 20 or fewer unallocated /8s, an organization may choose to request up to a 6 month supply of IP addresses; When IANA reaches 10 or fewer unallocated /8s, an organization may choose to request up to a 3 month supply of IP addresses; Create a new subsection in section 4 of the NRPM; 4.X Maximum Allocation or Assignment during and following Run-Out When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a proportionally decreasing maximum allocation, and assignment, size will be put into effect. The maximum allocation will be the next whole CIDR prefix less than or equal to one quarter (1/4) of the total ARIN free pool available at the time of each allocation, but no longer than the applicable minimum allocation. An organization may request additional resources when it can demonstrate it has properly utilized all previous allocations per applicable policies. However, the total of all allocations received within the last three (3) month period and the current request, cannot exceed the current maximum allocation size. This maximum allocation size is applicable to allocations from the ARIN free pool only. It is explicitly not applicable to resources received via transfer under section 8.3, or any other specially designated resources. Rationale: This proposed policy is intended to ensure an equitable distribution of IPv4 resources as run-out of the IANA free pool and subsequently the ARIN free pool occurs. This is achieved in two parts; first, changing section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4 resources that may be requested in steps as the IANA free pool runs-out. This helps accomplish equity by reducing the window that an advantage or disadvantage can exist between competitors, that will be created when one competitor receives a final allocation just before run-out and another competitor does not. The reductions in the length of supply will be triggered by IANA reaching defined levels of unallocated /8s, including the /8s reserved as part of section 10.4 of the NRPM. These triggers have been chosen base on the current rate of consumption of /8s by the RIRs. The first part of this policy is similar to ideas in RIPE policy proposal 2009-03 (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been adapted by discussion and for use within the ARIN region. The second part of this policy, allows a maximum of one quarter (1/4) of the then current total IPv4 resources to be allocated in a single request, once ARIN has received its last /8 from IANA. This helps achieve equity by ensuring the available resources are spread among multiple organizations and that no single organization may monopolize all of the resources available through a single request, at least until the maximum allocation size has been reduced down to the minimum allocation size. Incrementally reducing the length of supply and then reducing the maximum allocation size in proportion to the amount of resources available should minimize, or possibly eliminate, the need to fulfill requests with multiple smaller blocks. As in the current NRPM, the length of supply only applies to ISP allocations. However, the maximum allocation size is intended to apply to both ISP allocations and End-user assignments. This policy is intended to be independent of other policies or proposals to reserve address space for IPv6 transition or other purposes. Neither part is intended to limit Transfers to Specified Recipients per section 8.3 of the NRPM. The current maximum allocation size should be published on the ARIN website, preferably in real-time, as it may change rapidly as the ARIN free pool resources are exhausted. In the worst-case the maximum allocation size will decrease every forth allocation, when all four are the then current maximum allocation size. However, in the beginning there will likely be many smaller allocations before the maximum allocation size is decreased, accelerating as the resources are exhausted. Following the run-out phase, this policy provides an equitable means of distribution of resources if or when additional resources become available after ARIN has initially exhausted such resources. Such as if resources are returned, recovered by other means, or additional resources are obtained from IANA. Further, whenever ARIN receives a sufficiently large amount of additional resources, this policy intends for the maximum allocation size to be increased accordingly. After ARIN receives its last /8, the intent is to normally limit an organization to a single maximum allocation within a three month period. However, saying it that simply opens this policy to gamesmanship in requesting less than a maximum allocation. Requiring a maximum allocation to cover new requests and all allocations received in the previous three month period, should eliminate this kind of gamesmanship. There is a beneficial side effect of stating it this way, in the special situation when the maximum allocation size is increased, due to ARIN obtaining a sufficiently large amount of additional resources, an organization may receive additional resources earlier than the normal three month period. But, only in this special situation and when an organization properly utilizes a previous maximum allocation in less than three months, may an organization receive additional resources in less than the normal three month period. Other ratios, such as one half (1/2) or one eighth (1/8) could be considered. One eighth (1/8) would provide greater assurance of eliminating the need to use multiple blocks to fulfill requests and ensure a greater number of organizations receive resources. However, one eighth (1/8) is more likely to be seen as rationing and an attempt to artificially extend the lifetime of IPv4. During the ARIN XXIII policy discussion there seemed to be a consensus that attempts to extend the lifetime of IPv4 resources would be undesirable. While on the other hand, one half (1/2) is even less likely to ration resources, but it would likely result in the resource being spread across significantly fewer organizations and increase the need to use multiple blocks to fulfill requests. In conclusion, combining the final 3 month length of supply with the one quarter (1/4) ratio provides roughly an annualized equivalent of the whole ARIN free pool being made available to a single organization. While it is not possible for a single organization to receive the whole ARIN free pool within one year under this policy, it is a virtual certainty that multiple organization will be requesting resources, and that the ARIN free pool will not likely last a full year following the exhaustion of the IANA free pool anyway. Therefore, the ratio one quarter (1/4) seems to strike a balance between making resources available with as little restriction as possible and ensuring an equitable distribution of those resources during and following the run-out phase. EDITORIAL NOTE: This Draft Policy 2009-8 merges ideas from two separate policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run Out by Allocation Window. Timetable for implementation: Immediate ##### ##### Proposal: Equitable IPv4 Run-Out Proposal Version (Date): 3 August 2009 Date of Assessment: 18 August 2009 1. Proposal Summary (Staff Understanding) Staff understands the policy applies to ISPs who have been ARIN members for more than a year. When IANA reaches 20 /8s, the supply period for IPv4 address space will decrease from a 12 months to 6 months. When the IANA reaches 10 or less /8s, the supply period is reduced to 3 months. The second part of the proposal triggers upon receipt of ARIN?s last /8 from the IANA (per NRPM 10.4.2.2). The policy would establish a new maximum prefix size for all requests and place a limit on the amount of space an organization can receive within any three month period. The maximum prefix size would be on a sliding scale relative to the total amount of free IPv4 addresses in ARIN's inventory (one fourth of the total rounded down to the nearest smallest CIDR prefix). These polices do not apply to Transfers to Specified Recipients (NRPM 8.3). 2. Comments A. ARIN Staff Comments The policy can be implemented as written. The title of section 4.2.4.4 needs to change from ?Twelve Months? to ?Subscriber Members After One Year?. Note that the maximum prefix size in effect at any given time (e.g. /16) may be larger than the largest available contiguous address block in ARIN?s inventory (e.g. /18). In order to fulfill a request in this scenario, ARIN would have to issue several discontiguous address blocks. There is a suggestion in the rationale to display the maximum prefix size in real time. But that prefix size might not be available upon completion of a request. Example, on Friday we display /18. By the time the request is finalized, the maximum is a /19, and that?s what is issued to the customer. We could put a disclaimer that the actual prefix issued to a customer could be smaller. Also, we see value in keeping track of the maximum prefix size over time. The third sentence of the proposed 4.2.4.4 (starting with "This reduction") is a run-on sentence and contains grammatical errors. ARIN staff suggests the following replacement text: ?This reduction does not apply to resources received via section 8.3. Organizations requesting transfers under 8.3 may choose to request up to a 12-month supply of IP addresses.? B. ARIN General Counsel ARIN has the legal duty and authority to establish more restrictive rules to ?ration? the issuance of IPv4 resources as the scarcity of such resources increases. However, such rules must make clear rational sense given current circumstances, and may be tested in litigation by disappointed parties at the time they come fully into effect, not when adopted. Therefore, the proposed policy here will need to be carefully reviewed and if passed, carefully implemented, for example, to prevent any ?side effect? that would inadvertently favor one set of ISPs over another. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Updates to software Updated guidelines Staff training 4. Proposal Text Equitable IPv4 Run-Out Date: 3 August 2009 Policy statement: Replace the text in NRPM 4.2.4.4 with; After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses. As the IANA free pool decreases, the length of supply that an organization may request will be reduced at the following thresholds. This reduction does not apply to resources received via Transfers to Specified Recipients per section 8.3, in this case an organization may continue choose to request up to a 12 month supply of IP addresses. When IANA reaches 20 or fewer unallocated /8s , an organization may choose to request up to a 6 month supply of IP addresses; When IANA reaches 10 or fewer unallocated /8s , an organization may choose to request up to a 3 month supply of IP addresses; Create a new subsection in section 4 of the NRPM; 4.X Maximum Allocation or Assignment during and following Run-Out When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a proportionally decreasing maximum allocation, and assignment, size will be put into effect. The maximum allocation will be the next whole CIDR prefix less than or equal to one quarter (1/4) of the total ARIN free pool available at the time of each allocation, but no longer than the applicable minimum allocation. An OrgID may request additional resources when it can demonstrate it has properly utilized all previous allocations per applicable policies. However, the total of all allocations received within the last three (3) month period and the current request, cannot exceed the current maximum allocation size. This maximum allocation size is applicable to allocations from the ARIN free pool only, and is explicitly not applicable to resources received through Transfers to Specified Recipients per section 8.3, or any other specially designated resources. Rationale: This proposed policy is intended to ensure an equitable distribution of IPv4 resources as run-out of the IANA free pool and subsequently the ARIN free pool occurs. This is achieved in two parts; first, changing section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4 resources that may be requested in steps as the IANA free pool runs-out. This helps accomplish equity by reducing the window that an advantage or disadvantage can exist between competitors, that will be created when one competitor receives a final allocation just before run-out and another competitor does not. The reductions in the length of supply will be triggered by IANA reaching defined levels of unallocated /8s, including the /8s reserved as part of section 10.4 of the NRPM. These triggers have been chosen base on the current rate of consumption of /8s by the RIRs. The first part of this policy is similar to ideas in RIPE policy proposal 2009-03 (http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been adapted by discussion and for use within the ARIN region. The second part of this policy, allows a maximum of one quarter (1/4) of the then current total IPv4 resources to be allocated in a single request, once ARIN has received its last /8 from IANA. This helps achieve equity by ensuring the available resources are spread among multiple organizations and that no single organization may monopolize all of the resources available through a single request, at least until the maximum allocation size has been reduced down to the minimum allocation size. Incrementally reducing the length of supply and then reducing the maximum allocation size in proportion to the amount of resources available should minimize, or possibly eliminate, the need to fulfill requests with multiple smaller blocks. As in the current NRPM, the length of supply only applies to ISP allocations. However, the maximum allocation size is intended to apply to both ISP allocations and End-user assignments. This policy is intended to be independent of other policies or proposals to reserve address space for IPv6 transition or other purposes. Neither part is intended to limit Transfers to Specified Recipients per section 8.3 of the NRPM. The current maximum allocation size should be published on the ARIN website, preferably in real-time, as it may change rapidly as the ARIN free pool resources are exhausted. In the worst-case the maximum allocation size will decrease every forth allocation, when all four are the then current maximum allocation size. However, in the beginning there will likely be many smaller allocations before the maximum allocation size is decreased, accelerating as the resources are exhausted. Following the run-out phase, this policy provides an equitable means of distribution of resources if or when additional resources become available after ARIN has initially exhausted such resources. Such as if resources are returned, recovered by other means, or additional resources are obtained from IANA. Further, whenever ARIN receives a sufficiently large amount of additional resources, this policy intends for the maximum allocation size to be increased accordingly. After ARIN receives its last /8, the intent is to normally limit an organization to a single maximum allocation within a three month period. However, saying it that simply opens this policy to gamesmanship in requesting less than a maximum allocation. Requiring a maximum allocation to cover new requests and all allocations received in the previous three month period, should eliminate this kind of gamesmanship. There is a beneficial side effect of stating it this way, in the special situation when the maximum allocation size is increased, due to ARIN obtaining a sufficiently large amount of additional resources, an organization may receive additional resources earlier than the normal three month period. But, only in this special situation and when an organization properly utilizes a previous maximum allocation in less than three months, may an organization receive additional resources in less than the normal three month period. Other ratios, such as one half (1/2) or one eighth (1/8) could be considered. One eighth (1/8) would provide greater assurance of eliminating the need to use multiple blocks to fulfill requests and ensure a greater number of organizations receive resources. However, one eighth (1/8) is more likely to be seen as rationing and an attempt to artificially extend the lifetime of IPv4. During the ARIN XXIII policy discussion there seemed to be a consensus that attempts to extend the lifetime of IPv4 resources would be undesirable. While on the other hand, one half (1/2) is even less likely to ration resources, but it would likely result in the resource being spread across significantly fewer organizations and increase the need to use multiple blocks to fulfill requests. In conclusion, combining the final 3 month length of supply with the one quarter (1/4) ratio provides roughly an annualized equivalent of the whole ARIN free pool being made available to a single organization. While it is not possible for a single organization to receive the whole ARIN free pool within one year under this policy, it is a virtual certainty that multiple organization will be requesting resources, and that the ARIN free pool will not likely last a full year following the exhaustion of the IANA free pool anyway. Therefore, the ratio one quarter (1/4) seems to strike a balance between making resources available with as little restriction as possible and ensuring an equitable distribution of those resources during and following the run-out phase. EDITORIAL NOTE: This Draft Policy 2009-X merges ideas from two separate policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run Out by Allocation Window. Timetable for implementation: Immediate