From info at arin.net Tue Apr 1 11:17:06 2008 From: info at arin.net (Member Services) Date: Tue, 01 Apr 2008 11:17:06 -0400 Subject: [ppml] Revision to 2008-3 In-Reply-To: <47F15E50.9020005@acornactivemedia.com> References: <47F15E50.9020005@acornactivemedia.com> Message-ID: <47F251F2.5070604@arin.net> Policy Proposal 2008-3, Community Networks IPv6 Allocation, has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) Josh King wrote: > Hello, > > Here's a revision of the 2008-3 policy proposal based upon the staff > recommendations. Sorry for the extreme lateness, I did not receive the > staff recommendations until yesterday due to problems with my email. > I've attempted to address the concerns expressed by staff, but some > points I've expressed may require further clarification, and I look > forward to further staff comments. > > Changes: > Added section 6.5.9 as per recommendation, listing allocation and user > requirements for Community Networks allocations. Largely based upon > 6.5.8.2 and .3, with revisions to attempt to reflect the fact that a > Community Network is neither an end-user or LIR. > > Modified section 6.5.8.1b to refer to section 6.5.9. > > -- Policy Proposal 2008-3 > Community Networks IPv6 Allocation > > Author: Joshua King > > Proposal Version: 1 > > Date: 4 March 2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > [Add Section 2.8 to the NRPM.] > > 2.8 Community Network > > A community network is a generic reference to any network that is > operated by a group of people living in a particular local area > organized for the purposes of delivery or provision of network services > to the residents of an incorporated or unincorporated regional > municipality, city, town, village, rural municipality, township, county, > district or other municipality or other such geographic space, however > designated. > > [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 Community Network as defined in > Section 2.8, with allocation criteria defined in section 6.5.9. > > [Add Section 6.5.9 to the NRPM.] > > 6.5.9 Community Network Allocations > > 6.5.9.1. Initial assignment size > > Organizations defined as Community Networks under section 2.8 are > eligible to receive a direct assignment. 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.2. 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 adjacent address block. > > 6.5.9.3. Number of customers > > Community Networks seeking an allocation must demonstrate that they > provide for a user base of at least 100 through connectivity to homes > and businesses, public facilities, public access points, or mobile > users. Community Networks with user bases of under 200 must also submit > a plan for doubling their service base over the next year. > > Rationale: > > There are currently a number of projects globally that aim to develop > community network infrastructure and related technologies. These are > usually coordinated by volunteer-run, grassroots organizations which > lack many of the resources of traditional internet service providers and > other network operators. They have diverse goals, including public > policy, software development, and implementation of community services > and resources. Many of them provide services free of charge, and thus > lack any paying user base. However, in order to create and maintain > community networks that are often composed of hundreds if not thousands > of inexpensive, commodity hosts and devices, a significant amount of > address space will be required. Current-generation workarounds to this > problem, such as NAT, not only make it difficult to develop > next-generation decentralized network technology by segmenting the > community's architecture from the Internet as a whole, but will cease to > be as viable a stopgap as the Internet moves towards IPv6 integration. > > Even now, common community networking software solutions such as > CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) > have nascent IPv6 addressing support, but participating organizations > lack the address space for widespread testing or adoption. As such, it > is necessary to implement an procedure as soon as possible for these > segregated networks to acquire address space. These organizations do not > meet the criteria traditionally defined for LIR's, and thus cannot > acquire address allocations through existing templates. By establishing > a procedure by which these organizations can seek to acquire the > resources they require for further development, ARIN can reach out to > this active community and establish a small but definite space for them > in the future of Internet. > > Timetable for implementation: Immediate. > > Josh King > -- > josh at acornactivemedia.com > -- > Senior Network Engineer, Acorn Active Media > (http://www.acornactivemedia.com) > System Administrator, Chambana.net (http://www.chambana.net) > -- > "I am an Anarchist not because I believe Anarchism is the final goal, > but because there is no such thing as a final goal." -Rudolf Rocker > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From info at arin.net Tue Apr 1 11:36:39 2008 From: info at arin.net (Member Services) Date: Tue, 01 Apr 2008 11:36:39 -0400 Subject: [ppml] Revision to 2007-17 In-Reply-To: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com> References: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com> Message-ID: <47F25687.3030808@arin.net> Policy Proposal 2007-17 Title: Legacy Outreach and Partial Reclamation Policy Revised: 28 March 2008 Date of Assessment: 1 April 2008 ARIN Staff Assessment (Revised) The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available below and at: http://www.arin.net/policy/proposals/2007_17.html II. Understanding of the proposal ARIN staff understands that this proposal would replace the existing amnesty policy in NRPM Section 4.6. III. Comments A. ARIN Staff There is currently an amnesty policy (NRPM 4.6) and an aggregation policy (NRPM 4.7). Both policies contain clear and concise criteria and have been used successfully by the ARIN community since implementation. B. ARIN General Counsel Pending. IV. Resource Impact ? Moderate The resource impact of implementing this policy is viewed as moderate. Barring any unforeseen resource requirements, this policy could be implemented within 90 - 180 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: ? Updates to Registration Services Guidelines ? Staff training ? Tracking tools for the return of the space and for the yearly contact requirement ? Creation of software that will flag records in WHOIS as "unreachable" Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Owen DeLong wrote: > > The following revised version of 2007-17 is submitted for consideration. > The amendments are being made to address concerns expressed by staff > in the "staff assessment" of the policy proposal. > > I ran these changes by staff prior to submitting them here. The changes > do address the concerns expressed by staff, but, staff may wish to revise > their "impact" statement. Beyond this statement, I'll leave it to staff > to comment further if they wish. > > Apologies for the late date on this amendment. Look forward to upcoming > changes to the IRPEP to improve this situation. > > Owen > > > Modifications: > > Extended 4.6.1 to allow ARIN to reject transactions of no benefit > to the community. (Hopefully this closes most of the abuse loopholes) > > Renumbered 4.6.6 to 4.6.7 Annual contact required > > Renumbered 4.6.5 to 4.6.6 RSA Required if new addresses received > > Inserted new 4.6.5 to spell out requirement for ARIN to work with > resource holders to specify a return timeframe in contract. > > Added text to rationale to clarify overriding intent and > > Policy Proposal 2007-17 > Legacy Outreach and Partial Reclamation > > Author: Owen DeLong > > Date: 21 February 2008 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace section 4.6 as follows: > > 4.6 Amnesty and Aggregation requests > > 4.6.1 Intent of this policy > > This policy is intended to allow the community and ARIN staff to work > together with holders of address resources in the best interests of > the community by facilitating the return of unused address space and > the aggregation of existing space in a manner which is in the best > interests of both parties. > > All transactions under this policy must either create greater > aggregation (a reduction in the number of prefixes) or the return of > address space. ARIN should reject any transaction which staff judges > is not in the interests of the community. > > 4.6.2 No penalty for returning or aggregating > > ARIN shall seek to make the return of address space as convenient and > risk-free to the returning organization as possible. An organization > with several non-contiguous blocks seeking to aggregate and return > space at the same time should be accommodated if possible. If it is > possible to expand one block, for example, to facilitate the return of > other blocks, ARIN should do th.6.3 Return should not force renumbering > > An organization shall be allowed to return a partial block of any size > to ARIN. For any return greater than a /24, ARIN shall not require > that the non-returned portion of the block be renumbered unless the > returning organization wishes to do so. > > 4.6.4 Incentives > > The Board of Trustees should consider creating incentives for > organizations to return addresses under this policy. > > 4.6.5 Timeframe for return > > Any organization which is returning addresses under this policy shall > negotiate with ARIN an appropriate timeframe in which to return the > addresses after any new resources are received under this policy. In > the case of a simple return, the timeframe shall be immediate. In the > case where renumbering into new addresses out of existing addresses to > be returned is required, the returning organization shall sign a > contract with ARIN which stipulates a final return date not less than > 6 months nor more than 18 months after the receipt of new addresses. > If an organization misses this return date, but, ARIN believes the > organization is working in good faith to complete the renumbering, > ARIN may grant a single extension of 6-12 months as staff deems > appropriate to the situation. Such an extension must be requested in > writing (email to hostmaster at arin.net ) by > the organization at least 15 > days prior to the original expiration date. > > 4.6.6 RSA Required if new addresses received > > Any organization which receives any additional addresses under this > policy shall be required to sign an ARIN RSA which will apply to all > new addresses issued and to any retained blocks which are expanded > under this policy. > > 4.6.7 Annual contact required > > Any organization which participates in this policy shall be required > to sign an agreement stipulating that ARIN will attempt contact at > least once per year via the contact mechanisms registered for the > organization in whois. Should ARIN fail to make contact, after > reasonable effort the organization shall be flagged as "unreachable" > in whois. After six months in "unreachable" status, the organization > agrees that ARIN may consider all resources held by the organization > to be abandoned and reclaim such resources. Should the organization > make contact with ARIN prior to the end of the aforementioned six > month period and update their contact information appropriately, ARIN > shall remove the "unreachable" status and the annual contact cycle > shall continue as normal. If the organization pays annual fees to > ARIN, the payment of annual fees shall be considered sufficient contact. > > Rationale: > > Existing policy supports aggregation (4.7) and provides some amnesty > (existing 4.6) for returning blocks. However, a number of resource > holders have expressed discomfort with the current section 4.6 > believing that they will be forced to return their entire address > space and renumber rather than being able to make partial returns and > retain some of their existing space. > > This policy seeks to eliminate those concerns and make the return of > unused address space more desirable to the resource holders. > > A very high percentage of underutilized space is in the hands of > legacy holders who currently have no benefit to joining the ARIN > process and no way to return any portion of their address space > without incurring significant disadvantage as a result. > > A suggestion to the board would be to adopt benefits along the > following lines for people returning space. These benefits would > provide additional incentive for resource holders to make appropriate > returns and for legacy holders to join the ARIN process: > > 1. If the organization does not currently pay ARIN fees, they shall > remain fee exempt. > > 2. If the organization currently pays ARIN fees, their fees shall be > waived for two years for each /20 returned, with any fractional /20 > resulting in a one-time single year waiver. > > 3. Any organization returning address space under this policy shall > continue under their existing RSA or they may choose to sign the > current RSA. For organizations which currently do not have an RSA, > they may sign the current RSA, or, they may choose to remain without > an RSA. > > 4. All organizations returning space under this policy shall, if they > meet other eligibility requirements and so request, obtain an > appropriate IPv6 end-user assignment or ISP allocation as applicable, > with no fees for the first 5 years. Organizations electing to receive > IPv6 allocation/assignment under this provision must sign a current > RSA and must agree that their IPv4 resources are henceforth subject to > the RSA. > > The overriding intent of this policy proposal is to make it as easy as > possible for both ARIN and resource holders to "do the right thing" > with regard to excess resources or dis-aggregated (fragmented) address > blocks. It is the desire of the author that staff make any judgment > calls necessary under this policy with that ideal clearly in mind. > While the author has made a concerted effort to make the policy as > clear as possible and > as concrete as can be, the reality is that these types of transactions > must rely heavily on the judgment and expertise of the ARIN staff in > determining what is in the best interests of the community. > > > Timetable for implementation: Immediate > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From info at arin.net Thu Apr 3 15:27:07 2008 From: info at arin.net (Member Services) Date: Thu, 03 Apr 2008 15:27:07 -0400 Subject: [ppml] Poll - Transfer Policy - Results In-Reply-To: <47F10A45.70001@arin.net> References: <47F10A45.70001@arin.net> Message-ID: <47F52F8B.6060105@arin.net> Transfer Policy Poll The total subscriber count for PPML was 1812 when the poll began. The poll ran for three days (12:00 EDT, 31 March thru 12:00 EDT, 3 April 2008). Poll Results: Q1: Do you feel a transfer proposal to change the current transfer policy should exist? Answer Count Yes 96 No 28 Undecided 132 I don't care 18 Q2: Do you feel that you have been informed enough on the pro's and con's of what a change in the current transfer policy would have in our internet community? Answer Count Yes 100 No 172 Q3: Do you feel informed enough in general to make a decision regarding a change to the current transfer policy? Answer Count Yes 103 No 170 Q4: Will you attend the April ARIN meeting in Denver via remote participation? Answer Count Yes 74 No 218 Q5: Will you attend the April ARIN meeting in Denver in person? Answer Count Yes 37 No 298 Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > The ARIN Advisory Council is conducting a poll. The poll contains five > questions. You will receive five e-mails, one question per message. > > Every e-mail address subscribed to the Public Policy Mailing List (PPML) > will be e-mailed individually with instructions on how to participate in > the poll. If an alias is subscribed to the PPML that is then distributed > to several individuals, only the first opinion registered will be > counted. Only those who are already subscribed when the poll starts may > participate. > > The poll ends at noon EDT on Thursday, 3 April 2008. The results will be > sent to PPML. > > 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From info at arin.net Mon Apr 7 11:03:43 2008 From: info at arin.net (Member Services) Date: Mon, 07 Apr 2008 11:03:43 -0400 Subject: ARIN XXI Now Underway Message-ID: <47FA37CF.1000304@arin.net> The ARIN XXI Public Policy and Members Meeting is now underway in Denver, Colorado. For those in the community who were unable to make it to Denver, ARIN is offering a webcast of the Public Policy and Members Meetings. The times of the broadcast are as follows: Public Policy Meeting (Policy and technical discussions) Monday, 7 April 9AM - 5PM Tuesday, 8 April 9AM - 5PM Members Meeting (ARIN reports and Board of Trustees and Advisory Council reports) Wednesday, 9 April 9AM - 12PM All times are Mountain Daylight Time(MDT), (UTC/GMT -6 hours) Registered remote participants may send in questions or comments during the times listed above. The full agenda is available at http://www.arin.net/ARIN-XXI/agenda.html. For details about how to connect to the webcast, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XXI/webcast.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Apr 8 10:19:06 2008 From: info at arin.net (Member Services) Date: Tue, 08 Apr 2008 10:19:06 -0400 Subject: ARIN XXI Agenda Updates Message-ID: <47FB7EDA.2050409@arin.net> Agenda Updates: Please note the following changes in the ARIN XXI meeting agenda for today's Public Policy Meeting. Discussion of Policy Proposal 2008-2, IPv4 Transfer Policy Proposal, will be continued this morning starting at 9:00 AM Mountain Daylight Time (MDT). Policy Proposal 2007-23, End Policy for IANA IPv4 allocations to RIRs, and Policy Proposal 2007-14, Resource Review Process will be discussed today at 10:45 AM Mountain Daylight Time (MDT). Please refer to the meeting agenda posted at: http://www.arin.net/ARIN-XXI/agenda.html for additional details about today?s agenda. For details about how to connect to the webcast, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XXI/webcast.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Apr 14 15:57:03 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 15:57:03 -0400 Subject: Changes to Mailing List Names Message-ID: <4803B70F.1060409@arin.net> As a result of a suggestion made through ARIN's Consultation and Suggestion Process (ACSP), ARIN will be standardizing two mailing list names. ARIN's Public Policy Mailing List (PPML), ppml at arin.net, will be renamed arin-ppml at arin.net. Similarly, ARIN's Consultation and Suggestion Process (ACSP) Mailing List, consult at arin.net, will be renamed arin-consult at arin.net. Both of these changes will be implemented between 6am EDT and 8am EDT April 23, 2008. During this brief outage, subscriptions will be migrated to the new mailing list names and mailing list archives will be converted to their new names. Organizations may need to adjust mail filters and anti-spam software accordingly. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Apr 14 16:28:36 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:28:36 -0400 Subject: Policy Proposal 2007-14: To Be Revised Message-ID: <4803BE74.4010705@arin.net> Policy Proposal 2007-14 Resource Review Process On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that this proposal should be revised. The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_14.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal Version: 2.1 Date: 24 March 2008 Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are believed to be necessary by ARIN to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has reason to believe that the resources were originally obtained fraudulently, or c. at any other time without having to establish cause unless a prior review has been completed in the preceding 24 months. 3. ARIN shall communicate the results of the review to the organization. 4. Organizations found by ARIN to be substantially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance. 4a. The extent to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organizations utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation. 4b. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as requested, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, or intentional violations of policy, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no any maintenance fees assessed during that period shall be calculated as if the return or revocation was complete. 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. pursuant to this subsection. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. 9. In considering compliance with policies which allow a timeframe (such as a requirement to assign some number of prefixes within 5 years) failure to comply cannot be measured until after the timeframe specified in the applicable policy has elapsed. Blocks subject to such a policy shall be assumed in compliance with that policy until such time as the specified time since issuance has elapsed. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: The authors have been told that current policy does not clearly give ARIN the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six- month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The intent of paragraph 2c is to prevent ARIN from doing more than one without-cause review in a 24 month period. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Mon Apr 14 16:30:26 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:30:26 -0400 Subject: Policy Proposal 2007-17: To Be Revised Message-ID: <4803BEE2.4090606@arin.net> Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that this proposal should be revised. The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_17.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Date: 28 March 2008 Proposal type: modify Policy term: permanent Policy statement: Replace section 4.6 as follows: 4.6 Amnesty and Aggregation requests 4.6.1 Intent of this policy This policy is intended to allow the community and ARIN staff to work together with holders of address resources in the best interests of the community by facilitating the return of unused address space and the aggregation of existing space in a manner which is in the best interests of both parties. All transactions under this policy must either create greater aggregation (a reduction in the number of prefixes) or the return of address space. ARIN should reject any transaction which staff judges is not in the interests of the community. 4.6.2 No penalty for returning or aggregating ARIN shall seek to make the return of address space as convenient and risk-free to the returning organization as possible. An organization with several non-contiguous blocks seeking to aggregate and return space at the same time should be accommodated if possible. If it is possible to expand one block, for example, to facilitate the return of other blocks, ARIN should do that where possible. 4.6.3 Return should not force renumbering An organization shall be allowed to return a partial block of any size to ARIN. For any return greater than a /24, ARIN shall not require that the non-returned portion of the block be renumbered unless the returning organization wishes to do so. 4.6.4 Incentives The Board of Trustees should consider creating incentives for organizations to return addresses under this policy. 4.6.5 Timeframe for return Any organization which is returning addresses under this policy shall negotiate with ARIN an appropriate timeframe in which to return the addresses after any new resources are received under this policy. In the case of a simple return, the timeframe shall be immediate. In the case where renumbering into new addresses out of existing addresses to be returned is required, the returning organization shall sign a contract with ARIN which stipulates a final return date not less than 6 months nor more than 18 months after the receipt of new addresses. If an organization misses this return date, but, ARIN believes the organization is working in good faith to complete the renumbering, ARIN may grant a single extension of 6-12 months as staff deems appropriate to the situation. Such an extension must be requested in writing (email to hostmaster at arin.net) by the organization at least 15 days prior to the original expiration date. 4.6.6 RSA Required if new addresses received Any organization which receives any additional addresses under this policy shall be required to sign an ARIN RSA which will apply to all new addresses issued and to any retained blocks which are expanded under this policy. 4.6.7 Annual contact required Any organization which participates in this policy shall be required to sign an agreement stipulating that ARIN will attempt contact at least once per year via the contact mechanisms registered for the organization in whois. Should ARIN fail to make contact, after reasonable effort the organization shall be flagged as "unreachable" in whois. After six months in "unreachable" status, the organization agrees that ARIN may consider all resources held by the organization to be abandoned and reclaim such resources. Should the organization make contact with ARIN prior to the end of the aforementioned six month period and update their contact information appropriately, ARIN shall remove the "unreachable" status and the annual contact cycle shall continue as normal. If the organization pays annual fees to ARIN, the payment of annual fees shall be considered sufficient contact. Rationale: Existing policy supports aggregation (4.7) and provides some amnesty (existing 4.6) for returning blocks. However, a number of resource holders have expressed discomfort with the current section 4.6 believing that they will be forced to return their entire address space and renumber rather than being able to make partial returns and retain some of their existing space. This policy seeks to eliminate those concerns and make the return of unused address space more desirable to the resource holders. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process and no way to return any portion of their address space without incurring significant disadvantage as a result. A suggestion to the board would be to adopt benefits along the following lines for people returning space. These benefits would provide additional incentive for resource holders to make appropriate returns and for legacy holders to join the ARIN process: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 returned, with any fractional /20 resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that their IPv4 resources are henceforth subject to the RSA. The overriding intent of this policy proposal is to make it as easy as possible for both ARIN and resource holders to "do the right thing" with regard to excess resources or dis-aggregated (fragmented) address blocks. It is the desire of the author that staff make any judgment calls necessary under this policy with that ideal clearly in mind. While the author has made a concerted effort to make the policy as clear as possible and as concrete as can be, the reality is that these types of transactions must rely heavily on the judgment and expertise of the ARIN staff in determining what is in the best interests of the community. Timetable for implementation: Immediate From info at arin.net Mon Apr 14 16:30:53 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:30:53 -0400 Subject: Policy Proposal 2008-2: To Be Revised Message-ID: <4803BEFD.2010602@arin.net> Policy Proposal 2008-2 IPv4 Transfer Policy Proposal On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that this proposal should be revised. The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_2.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-2 IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1.1 Date: 7 March 2008 Proposal type: modify Policy term: permanent Policy statement: Replace the current NRPM section 8 with the following -- 8. Transfers [8.1. Transfers ? retain as is: Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified.] [8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact of Change in Resource Holder Ownership?: 8.2. Transfers as an Artifact of Change in Resource Holder Ownership ARIN will consider requests for the transfer of number resources upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: ? Existing customer base ? Qualified hardware inventory ? Specific software requirements.] [Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation Requirements for Transfers as an Artifact of Change in Resource Holder Ownership?: 8.2.1. Documentation Requirements for Transfers as an Artifact of Change in Resource Holder Ownership In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: ? An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree ? A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource ? A list of the requesting party's customers using the number resource. If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: ? A general listing of the assets or components acquired ? A specific description of acquisitions, including: o Type and quantity of equipment o Customer base ? A description of how number resources are being utilized ? Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers] 8.3. Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool (when IANA allocates its last unallocated unicast IPv4 address block), ARIN will also process IPv4 address transfer requests subject to the following conditions. These conditions apply only to Simple IPv4 transfers, not to transfers performed according to section 8.2. 8.3.1 Conditions on the transferor (the organization providing addresses for transfer): ? The transferor resides in the ARIN service area. ? The transferor has signed an RSA and/or a legacy RSA covering the IPv4 addresses transferred. ? The transferor has no outstanding balances with ARIN. ? The transferor has not received any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the preceding 24 months. ? The transferor may not request any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the subsequent 24 months. 8.3.2 Conditions on the transferee (the organization receiving the transferred addresses): ? The transferee resides in the ARIN service area and intends to use the transferred IPv4 addresses within the ARIN service area. ? The transferee has no outstanding balances with ARIN. ? The transferee?s need is confirmed by ARIN, according to current ARIN policies, including but not limited to confirmation of utilization rate of any prior IPv4 allocations, assignments, or previously transferred IPv4 addresses held by the transferee. ? The transferee signs (or has previously signed) an RSA covering the IPv4 addresses transferred. ? The transferee has not provided any IPv4 addresses for transfer through this Simple Transfer process within the preceding 24 months. ? The transferee may not provide any IPv4 addresses for transfer through this Simple Transfer process within the subsequent 24 months, except in the case of business failure. ? The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. ? The transferee may only receive one IPv4 address transfer through this Simple Transfer process every 6 months. 8.3.3 Conditions on the IPv4 address block to be transferred: ? The IPv4 block must comply with applicable ARIN requirements, including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4., 4.3.2., 4.3.6.). However, an IPv4 allocation or assignment of /24 or larger, but smaller than the current minimum allocation size, may be transferred as a whole resource, but may not be subdivided. ? The IPv4 block must currently be registered for use within the ARIN service area, either as part of an address block assigned by IANA to ARIN, or as part of a legacy address block allocated within the ARIN service area. ? There must exist no dispute as to the status of the IPv4 block or regarding the allocation or assignment of such block to the transferor. ? The transferor may retain one contiguous address range out of their original allocation or assignment for their own use, and transfer the other contiguous address range. If the address range to be transferred consists of multiple non-aggregatable CIDR blocks, each may be transferred to a different transferee. The retained address range may not be further subdivided or transferred for a period of 12 months. Notwithstanding the preceding, the block may be subdivided as provided in section 8.3.6. 8.3.4 Fees ? Completion of a transfer requires payment of a transfer fee according to ARIN?s schedule of fees. ? The transferee will be subject to all future ARIN membership and service fees according to the transferee?s total address holdings. 8.3.5 Pre-qualification ? An interested transferee must seek pre-qualification from ARIN to confirm its eligibility to receive a transfer (including satisfaction of need according to current ARIN policies) before making any solicitation for transfer. Upon pre-qualification, ARIN will provide the transferee with documentation of the pre-qualification, including the size (CIDR prefix length) of the largest IPv4 address block the transferee is eligible to receive, and the expiration date of the pre-qualification. ? An interested transferor must seek pre-qualification from ARIN to confirm its eligibility to offer a transfer (including lack of outstanding balances and having signed an RSA) before offering IPv4 address resources for transfer. Upon pre-qualification, ARIN will provide the transferor with documentation of the pre-qualification, including the network block and the expiration date of the pre-qualification. 8.3.6 Deaggregation when Permitted by ARIN If ARIN determines that there is an inadequate supply of small blocks, ARIN may allow transferors to subdivide network blocks beyond the limited subdivision permitted under 8.3.3. ARIN will attempt to ensure an adequate supply of small blocks while minimizing deaggregation. 8.3.7. Safe Harbor for IPv4 Transfers through this Simple Transfer Process When an IPv4 address resource is made available for transfer, it shall be deemed exempt from ARIN utilization audit until 90 days after its transfer pre-qualification or until the transfer is completed, whichever comes first. In the event that a transfer is not consummated within the prequalification time period, the block may be immediately re-prequalified for transfer. Notwithstanding the current offered state of the address resource, however, the audit exemption period shall expire untolled 90 days after the expiration of the first pre-qualification period. After the expiration of any utilization audit exemption period, ARIN shall have 90 days in which to initiate a utilization audit. In no event shall non-exempt time be construed to extend the end of the next exemption period. 8.3.8. Simple IPv4 Transfers to or from Organizations Under Common Ownership or Control If an IPv4 transferor or transferee is under common ownership or control with any other organization that holds one or more IPv4 blocks, the IPv4 transfer request must report all such organizations under common ownership or control. When evaluating compliance with IPv4 Simple Transfer conditions, ARIN may consider a transferor?s transfer request in light of requests from other organizations under common ownership or control with the transferor. Similarly, ARIN may consider a transferee?s request in light of requests from other organizations under common ownership or control with the transferee. In evaluating requests from other organizations under common ownership or control, ARIN staff will consider the relationship between the organizations, the degree of coordination between the organizations, and the bona fide use of the addresses at issue to determine whether all appropriate conditions are met. 8.3.9. Record-keeping and Publication of Simple Transfers of IPv4 Addresses ARIN will develop and operate a listing service to assist interested transferors and transferees by providing them a centralized location to post information about IPv4 blocks available from prequalified transferors and IPv4 blocks needed by prequalified transferees. Participation in the listing service is voluntary. After completion of the transfer, ARIN will update the registration records pertaining to the IPv4 block at issue. ARIN will adjust its records as to the holdings of the transferor and transferee. After the transfer, ARIN will publish WHOIS data that reflects the current allocation or assignment of the transferred block. ARIN will also make available information about any prior recipient(s) of such block. ARIN will also publish a log of all transfers, including block, transferor, transferee, and date. Rationale: The ARIN Board of Trustees asked the Advisory Council to consider a set of questions around the depletion of the free pool of IPv4 addresses, the transition to IPv6 for Internet address needs in the future, and ARIN's possible role in easing the transition. Over the past few years the AC has spent a great deal of time reflecting on these issues ? as a group, as individuals, and in consultation with the community. One outcome of this process is this policy proposal, which the AC is submitting for consideration at the next meeting. We are proposing some changes to existing ARIN policy regarding the transfer of IP address block registrations between subscribers, which will allow for the emergence of trade in IPv4 address space, with ARIN to provide a listing service for address blocks available for transfer under the liberalized policy. We are aware that this proposal, if adopted, will mark a major change in ARIN's role in the community and the Internet. This policy proposal would create a transfer mechanism for IPv4 number resources between those who have excess resources and those who have a need, thereby allowing ARIN to continue to serve its mission after IANA free pool exhaustion. This proposal would also set conditions on such transfers intended to preserve as much as possible the existing policy related to efficient, needs-based resource issuance, and would leverage ARIN's extensive control systems, audit trails, and recognized position as a trusted agent to avoid speculation and hoarding and diminish the likelihood and extent of an uncontrolled 'black market' where the risk and potential for fraud is immeasurably higher. Many of the transfer conditions are self-explanatory, but some worth highlighting are that: ? To discourage speculation, a waiting period (proposed at 24 months) is required before a transferee (or ordinary resource recipient) can become a transferor, or vice versa. ? Transferees must qualify for IPv4 space (just as they do today when getting it from ARIN) before they can receive address space by transfer, or solicit space on a listing service. ? To discourage unnecessarily rapid growth of routing tables, an allocation or assignment may not be arbitrarily deaggregated. To allow a transferor to downsize within their existing space, they may split off a contiguous address range, once every 12 months, and transfer the resulting netblock(s), which are subject to ARIN?s minimum allocation size, to one or more transferee(s). ? A transferee may receive one transfer every 6 months, so they?ll be incented to transfer a block appropriately sized for their needs, which will further discourage deaggregation and keep smaller blocks available for smaller organizations. The proposal would also have ARIN develop and operate a listing service to facilitate transfers and provide an authoritative central source of information on space available and requested for transfer. It would not prohibit private party transactions, but would require that potential transferors and transferees be pre-qualified first, so that neither party will encounter any unexpected surprises when they ask ARIN to process the transfer. Timetable for implementation: Immediately, with most aspects of policy taking effect upon IANA exhaustion, per the policy text. From info at arin.net Mon Apr 14 16:31:12 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:31:12 -0400 Subject: Policy Proposal 2008-3: To Be Revised Message-ID: <4803BF10.7010707@arin.net> Policy Proposal 2008-3 Community Networks IPv6 Allocation On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that this proposal should be revised. The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_3.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-3 Community Networks IPv6 Allocation Author: Joshua King Date: 1 April 2008 Proposal type: new Policy term: permanent Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is a generic reference to any network that is operated by a group of people living in a particular local area organized for the purposes of delivery or provision of network services to the residents of an incorporated or unincorporated regional municipality, city, town, village, rural municipality, township, county, district or other municipality or other such geographic space, however designated. [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 Community Network as defined in Section 2.8, with allocation criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Allocations 6.5.9.1. Initial assignment size Organizations defined as Community Networks under section 2.8 are eligible to receive a direct assignment. 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.2. 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 adjacent address block. 6.5.9.3. Number of customers Community Networks seeking an allocation must demonstrate that they provide for a user base of at least 100 through connectivity to homes and businesses, public facilities, public access points, or mobile users. Community Networks with user bases of under 200 must also submit a plan for doubling their service base over the next year. Rationale: There are currently a number of projects globally that aim to develop community network infrastructure and related technologies. These are usually coordinated by volunteer-run, grassroots organizations which lack many of the resources of traditional internet service providers and other network operators. They have diverse goals, including public policy, software development, and implementation of community services and resources. Many of them provide services free of charge, and thus lack any paying user base. However, in order to create and maintain community networks that are often composed of hundreds if not thousands of inexpensive, commodity hosts and devices, a significant amount of address space will be required. Current-generation workarounds to this problem, such as NAT, not only make it difficult to develop next-generation decentralized network technology by segmenting the community's architecture from the Internet as a whole, but will cease to be as viable a stopgap as the Internet moves towards IPv6 integration. Even now, common community networking software solutions such as CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) have nascent IPv6 addressing support, but participating organizations lack the address space for widespread testing or adoption. As such, it is necessary to implement an procedure as soon as possible for these segregated networks to acquire address space. These organizations do not meet the criteria traditionally defined for LIR's, and thus cannot acquire address allocations through existing templates. By establishing a procedure by which these organizations can seek to acquire the resources they require for further development, ARIN can reach out to this active community and establish a small but definite space for them in the future of Internet. Timetable for implementation: Immediate. From info at arin.net Mon Apr 14 16:31:26 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:31:26 -0400 Subject: Policy Proposal 2007-21: Last Call Message-ID: <4803BF1E.7060904@arin.net> Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that the community supports this proposal and moves it to last call. Note that the AC amended the text. The AC changed "...must be covered by a current ARIN RSA." to "...must be covered by any current ARIN RSA." Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire at 23:59 EDT, 29 April 2008. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_21.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Date: 14 April 2008 Proposal type: modify Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. 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. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Mon Apr 14 16:31:40 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:31:40 -0400 Subject: Policy Proposal 2007-23: Last Call Message-ID: <4803BF2C.30608@arin.net> Policy Proposal 2007-23 (Global) End Policy for IANA IPv4 allocations to RIRs On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that the community supports this proposal and moves it to last call. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire at 23:59 EDT, 29 April 2008. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_23.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-23 (Global) End Policy for IANA IPv4 allocations to RIRs Proposal Version: Version 2 Date: 8 February 2008 Author: Roque Gagliano, ANTEL; Francisco Obispo, CENIT; Haitham EL Nakhal, MCIT; Didier Allain Kla, ISOC Cote d'Ivoire; JPNIC IPv4 countdown policy team: - Akinori Maemura - Akira Nakagawa - Izumi Okutani - Kosuke Ito - Kuniaki Kondo - Shuji Nakamura - Susumu Sato - Takashi Arano - Tomohiro Fujisaki - Tomoya Yoshida - Toshiyuki Hosaka Proposal type: new Policy term: temporary Policy statement: This is a revised version of ; prop-046: IPv4 countdown policy proposal prop-051: Global policy for the allocation of the remaining IPv4 address space This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 4.1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to he RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA either cannot be fulfilled with the remaining IPv4 space available at the IANA pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 4.2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 4.2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate one /8 to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 4.2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate one /8 to each RIR from the reserved space. Rationale: The exhaustion of IPv4 address space is projected to take place within the next few years. This proposal seeks to focus on measures that should be taken globally in the address management area in order to prepare for the situation in all RIR regions. To continue applying a global coordinated policy for distribution of the last piece(s) of each RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. Timetable for implementation: after approval by ICANN board From info at arin.net Mon Apr 14 16:32:06 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:32:06 -0400 Subject: Policy Proposal 2008-1: Last Call Message-ID: <4803BF46.8040306@arin.net> Policy Proposal 2008-1 SWIP support for smaller than /29 assignments On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that the community supports this proposal and moves it to last call. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire at 23:59 EDT, 29 April 2008. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_1.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-1 SWIP support for smaller than /29 assignments Author: Joe Maimon Proposal Version: 1 Date: 26 February 2008 Proposal type: modify Policy term: permanent Policy statement: 4.2.2.1.2.) " ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data using the table format described in Section 4.2.3.7.5. " Replace with " ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWHOIS server or by using the table format described in Section 4.2.3.7.5. " 4.2.2.2.1.) " Utilization for blocks smaller than /29 can be documented using the format described in Section 4.2.3.7.5. " Replace with " Utilization for blocks smaller than /29 can be documented via SWIP or RWHOIS server or by using the format described in Section 4.2.3.7.5. " 4.2.3.7.2.) " For blocks smaller than /29 and for internal space, ISPs should provide utilization data using the format described in Section 4.2.3.7.5. " Replace with " For blocks smaller than /29 and for internal space, ISPs should provide utilization data via SWIP or RWHOIS server or by using the format described in Section 4.2.3.7.5. " 4.2.3.7.5.) Accounting for additional utilization " The following format should be used to provide the required information for utilization of blocks smaller than /29 and for describing internal networks: " Replace with " The following format should be used to provide the required information for utilization of blocks smaller than /29 and for describing internal networks when either SWIP or RWHOIS server is not used: " Rationale: With increasing frequency of smaller than /29 assignements to customers, the ability for ISP's to utilize SWIP or RWHOIS as a single comprehensive source of their utilization data should be supported. To implement this policy change, ARIN SWIP would need to no longer reject SWIP templates smaller then /29. Timetable for implementation: Immediate From info at arin.net Mon Apr 14 16:32:38 2008 From: info at arin.net (Member Services) Date: Mon, 14 Apr 2008 16:32:38 -0400 Subject: Policy Proposal 2007-27: Abandoned Message-ID: <4803BF66.5050605@arin.net> Policy Proposal 2007-27 Cooperative distribution of the end of the IPv4 free pool On 9 April 2008, the ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process, determined that this proposal did not have the support of the community and decided to abandon it. At this time the author of the proposal may elect to use the petition process to attempt to advance the proposal. The deadline for the author to initiate a petition is 23:59 EDT, 21 April 2008. If the author chooses not to petition or the petition is unsuccessful, then the determination of the AC stands and the proposal is abandoned. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_27.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-27 Cooperative distribution of the end of the IPv4 free pool Author: Tony Hain Date: 20 November 2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009 From info at arin.net Fri Apr 18 16:11:15 2008 From: info at arin.net (Member Services) Date: Fri, 18 Apr 2008 16:11:15 -0400 Subject: ARIN XXI Meeting Report Now Available Message-ID: <48090063.5000605@arin.net> From 6-9 April, the ARIN community took part in the ARIN XXI Public Policy and Members Meeting, held in Denver. The report of that meeting, which includes presentations, summary notes, and transcripts of the entire meeting, is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XXI/ The URL referenced above also provides links to presentations from the ARIN XXI IPv6 Pre-Game Show and IPv6 Main Event. Please check back next week when an archive of the meeting's webcast will be available. We?d like to congratulate Matt Pounsett, winner of the Meeting Survey Raffle and David Williamson, winner of the General Meeting Raffle ! Matt?s name was randomly selected from those entries submitted by completing the ARIN XXI survey. David?s name was selected from the remaining unselected entries to all of the surveys conducted as part of ARIN XXI. Matt will receive an Optimus Mini Three Keyboard, and David will receive the Apple TV, generously donated by EGATE Networks. We thank everyone in the community who participated in person or remotely and those who responded to the surveys. We look forward to seeing you 15-17 October 2008 for ARIN XXII in Los Angeles,California . Regards, Member Services American Registry for Internet Numbers From info at arin.net Wed Apr 23 12:05:52 2008 From: info at arin.net (Member Services) Date: Wed, 23 Apr 2008 12:05:52 -0400 Subject: Policy Proposal: Minimum Allocation in the Caribbean Region Message-ID: <480F5E60.5060101@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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 Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Minimum Allocation in the Caribbean Region Author: Cathy Aronson and Paul Andersen Proposal Version: Initial Submission Date: 23 April 2008 Proposal type: New Policy term: Renewable Policy statement: Minimum Allocation. The minimum IPv4 allocation size for ISPs from the Caribbean portion of the ARIN region is /22. 1. Allocation Criteria. 1. The requesting organization must show the efficient utilization of an entire previously allocated /22 from their upstream ISP. This allocation (/22) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 4 /24s. 2. A multi-homed organization must show the efficient utilization of an entire previously allocated /23 from their upstream ISP. This allocation (/23) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 2 /24s. 2. Utilization Reporting and Justification. All other ARIN policies regarding the reporting of justification information for the allocation of IPv4 and IPv6 address space will remain in effect. Rationale: ARIN staff have noted that organizations in the Caribbean region have problems meeting the current criteria due to the fact that the population in the region is smaller than that of Canada and the US. There is also a lack of competition with many countries in the region faced with a monopoly or duopoly situation in terms of transport providers. To spur development in the region a similar proposal was passed in this region for the portion of the African region that ARIN administered prior to the formation of AfriNIC. This proposal seeks a similar outcome. Timetable for implementation: immediate From info at arin.net Fri Apr 25 11:33:02 2008 From: info at arin.net (Member Services) Date: Fri, 25 Apr 2008 11:33:02 -0400 Subject: Proposed Revision to the ARIN Policy Development Process Message-ID: <4811F9AE.1020108@arin.net> On 8 April 2008, at ARIN XXI in Denver, Colorado, Scott Bradner presented a proposed policy development process to replace the current Internet Resource Policy Evaluation Process (IRPEP). We invite the entire community to review and comment on the proposed new PDP. The presentation can be found at: http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html and the webcast can be found at: http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html. Please post any comments no later than 5 PM EDT, Friday, 9 May 2008 to arin-ppml at arin.net. PRINCIPLE ARIN's Internet Resource Policies are documented community decisions that directly determine the rules by which Internet numbering resources are managed and administered by ARIN. Internet Resource Policies are developed in an open and transparent manner by the Internet community. Anyone may participate in the process - ARIN membership is not required. The Policy Development Process (PDP) described in this document defines how policy is established in the ARIN region. The ARIN Board of Trustees adopts proposed Internet Number Resource Policies recommended to it by the ARIN Advisory Council (AC) if the Board determines that the PDP has been followed, that support and consensus for a policy has been reached among the community, and if the proposed policies are consistent with ARIN's Articles of Incorporation and Bylaws and with the applicable laws and regulations. It is important to note that Internet Resource Policies are distinctly separate from ARIN general business practices and procedures. ARIN's general business practices (including fees) and procedures are not within the purview of the Policy Development Process. (The ARIN Consultation and Suggestion Process can be used to propose changes in non-policy areas.) OVERIVEW The proposed PDP is intended to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments before discussion; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. The proposed PDP empowers the ARIN Advisory Council by shifting its scope from a policy advisory body to a policy development body while providing checks and balances and maintains an open and transparent process. THE POLICY DEVEOPMENT PROCESS 1. Proposal. [15 Days, maximum] a. Submittal. Policy proposals may be submitted at any time. Anyone in the community, except a member of the ARIN Board of Trustees or a member of ARIN staff can originate a policy proposal. Policy proposals must be sent to the policy e-mail address at ARIN. Proposals can be submitted at any time but only proposals received more than 70 days before a Public Policy Meeting (PPM) can generate a draft policy for consideration at that meeting. b. Clarity & Understanding. ARIN staff works with the proposal originator to ensure there is clarity and understanding of what is being proposed. The staff does not evaluate the proposal itself at this stage, their only aim is to make sure that they understand what the proposal is proposing and believe that the community will as well. If understanding is reached the proposal is announced to the community via the ARIN Public Policy Mailing List (PPML) and forwarded to the AC. The proposal is dropped if the staff and originator cannot reach an agreement on clear and understandable text. In this case, the originator may make a Submittal Petition and send the proposal to PPML and request community support to have the proposal forwarded to the AC for review. There is no AC action in this phase. 2. Draft Policy. [30 Days, maximum] a. Development & Evaluation. The AC assumes ownership of all proposals. The AC develops and evaluates proposals to only bring forth technically sound policies that make a positive contribution to the Number Resource Policy Manual. The AC may rewrite, merge, abandon, etc.; for example, they may use a proposal as an idea to generate a draft policy. If the AC intends to move a draft policy forward, it must first submit it for staff and legal review (10 days max to perform). The AC must understand and address staff and legal comments before a proposal may go on. These comments may cause the AC to revise a draft policy. b. Selection. The AC selects the draft policies that will be published for discussion and review by the community on the PPML. The relevant staff and legal comments will be published along with each draft policy. If any member of the community, including a proposal originator, is dissatisfied with the AC action on a policy proposal they can initiate a Discussion Petition to move this particular proposal to the PPML for discussion as a draft policy. A successful petition may result in competing versions of the same draft policy. Staff and legal review will be conducted and published for successful petitions. 3. Discussion and Review. [25 Days, minimum] Only draft policies selected by the AC or successfully petitioned are open to community discussion and review on PPML. The text of all draft policies is frozen at 10 days prior to the Public Policy Meeting. The text remains frozen until after the completion of the Public Policy Meeting so that a single text for each draft policy is considered at the meeting. 4. Public Policy Meeting. The AC presents draft policies at the Public Policy Meeting; the successful petitioner presents theirs. Competing proposals, if any, will be discussed together. Discussion and votes at the meeting are for the consideration of the AC. 5. Consensus. a. Discussion Evaluation. [30 Days, maximum] At the conclusion of the PPM the AC owns all draft policies, including those that were successfully petitioned. The AC reviews all draft policies and, taking into account discussion both on the PPML and at the Public Policy Meeting, decides what to do with each draft policy. The AC may rewrite, merge, abandon, send to last call, etc. The results of the AC's decisions are announced to the PPML. Draft policies that are not abandoned or sent to last call are placed on the AC docket for further development and evaluation. If any member of the community, including a proposal originator, is dissatisfied with the AC action on a policy proposal they can initiate a Last Call Petition to move this particular proposal to the PPML for last call. b. Last Call [10 Days, minimum] The AC selects draft policies that have support both in the community and the AC itself and sends them to a last call for comments on the PPML. The last call period will be for a minimum of 10 days. The AC may decide that certain draft proposals may require a longer last call period of review, such as those that were revised based on comments received while the text was frozen. If the AC sends a draft policy to last call that is different from the frozen version, then the AC will explain and justify changes to the text. c. Last Call Review [30 Days, maximum] The AC determines consensus for each draft policy by reviewing last call comments, revisiting its decision (the AC may rewrite, merge, abandon, etc.), and determining readiness for consideration by the Board of Trustees. If the AC modifies a draft policy, it will be sent for another round of last call or may be placed back on the AC's docket for further development and evaluation. If any member of the community is dissatisfied with the AC action on a policy proposal they can initiate a Board of Trustees Consideration Petition to move this particular proposal for consideration by the Board of Trustees. The results of the AC's decisions are announced to the PPML. The AC forwards the draft policies that it supports to the Board of Trustees for consideration. 6. Board of Trustee Review. [30 Days, maximum] The ARIN Board of Trustees reviews and evaluates each draft policy presented to it. The Board examines each draft policy in terms of fiduciary risk, liability risk, conformity to law, development in accordance with the ARIN PDP, and adherence to the ARIN Articles of Incorporation and bylaws. The Board may adopt, reject or remand draft policies to the AC. Rejections will include an explanation. Remands will include an explanation and a recommendation. The Board may also seek clarification from the AC without remanding the draft policy. The results of the Board's decision are announced to the community via PPML. 7. Implementation. The expected implementation date of the policy is announced at the time that adoption of the policy is announced. ARIN staff updates to include the adopted policy into the Number Resource Policy Manual and implements and publishes a new version of the manual. REMINDER: COMMUNITY REVIEW REQUEST We invite the entire community to review and comment on the proposed new PDP. The presentation can be found at: http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html and the webcast can be found at: http://www.arin.net/meetings/minutes/ARIN_XXI/ppm.html. Please post any comments no later than 5 PM EDT, Friday, 9 May 2008 to arin-ppml at arin.net. Raymond A Plzak President and CEO American Registry for Internet Numbers (ARIN)