From memsvcs at arin.net Mon Jul 1 08:19:55 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 1 Jul 2002 08:19:55 -0400 (EDT) Subject: June Issue of ARIN Today Released Message-ID: The latest edition of ARIN's quarterly newsletter is available at: http://www.arin.net/newsletter/2002_June_arintoday.pdf This issue features the following content: Database and template conversion news and tips WHOIS beta-testing information Highlights of the ARIN IX Meeting Article entitled "DNS Delegation Gone Bad" Announcement of Oct. back-to-back NANOG and ARIN meetings Summary of recent international meetings and upcoming meeting calendar A look at ARIN's network abuse information from our website As always, your comments regarding content in this issue and suggestions for items you would like to see in future editions are welcome and can be sent to arintoday at arin.net. Regards, Susan Hamlin Director, Member Services From memsvcs at arin.net Tue Jul 2 16:56:55 2002 From: memsvcs at arin.net (Member Services) Date: Tue, 2 Jul 2002 16:56:55 -0400 (EDT) Subject: New Micro-allocation Policy Ratified Message-ID: The following new policy has been ratified in the ARIN region and will be implemented immediately: Policy 2001-3: Micro-allocation Policy ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. The full text of this policy can be viewed here: http://www.arin.net/policy/2001_3.html This policy replaces ARIN's existing Micro-Allocation Policy and was created in accordance with ARIN's Internet Resource Policy Evaluation Process which can be viewed here: http://www.arin.net/policy/ipep.html ARIN Member Services From memsvcs at arin.net Tue Jul 2 16:58:43 2002 From: memsvcs at arin.net (Member Services) Date: Tue, 2 Jul 2002 16:58:43 -0400 (EDT) Subject: Waiver of IP and AS Number Transfer Fees Message-ID: At the ARIN IX Member's Meeting there was consensus expressed that transfer fees should be waived as a means of encouraging subscribers to participate in database cleanup. The database cleanup effort is a part of the database conversion project. There was overwhelming support for such a waiver for the remainder of the fiscal year. During its June 5 meeting the ARIN Board of Trustees approved a motion to waive the fees for the transfer of AS Numbers and IP addresses for the period extending from July 1, 2002 through December 31, 2002. The Board meeting minutes can be viewed at: http://www.arin.net/library/minutes/bot/bot06052002.html ARIN Member Services From memsvcs at arin.net Thu Jul 11 14:58:38 2002 From: memsvcs at arin.net (Member Services) Date: Thu, 11 Jul 2002 14:58:38 -0400 (EDT) Subject: ARIN Conversion: Template Instructions Now Available Message-ID: In February of this year, ARIN released the new templates to be used after the conversion taking place on August 9, 2002. We have now modified those templates to include the instructions. These instructions should provide any guidance necessary to correctly complete a template. Please note that some of these templates make references to websites that will not be modified or posted until after conversion. The templates can be found at: ftp://ftp.arin.net/pub/new-templates/ If you have any questions regarding these templates and/or the database conversion, please address your questions to jumpstart at arin.net. Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Fri Jul 12 14:41:24 2002 From: memsvcs at arin.net (Member Services) Date: Fri, 12 Jul 2002 14:41:24 -0400 (EDT) Subject: ARIN Conversion Training: Register Today Message-ID: ARIN has developed a training course designed to provide ARIN members and the Internet community at large an understanding of the changes in registration templates and procedures caused by the August 9 database conversion. Registration is now open for this free course scheduled at the following two locations: -- July 30 in Dallas, Texas To register: http://www.arin.net/library/training/conversion/dallas_info.html -- August 12, Marina del Rey, California To register: http://www.arin.net/library/training/conversion/calif_info.html For more detailed information about the conversion please visit the Database & Template Conversion Information Center on our web site at: http://www.arin.net/template_conversion/index.html Contact us at training at arin.net if you have any questions regarding this training. ARIN Member Services From memsvcs at arin.net Mon Jul 22 13:15:30 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 22 Jul 2002 13:15:30 -0400 (EDT) Subject: Nomination Committee Volunteers Sought - Quick Response Required Message-ID: Per the ARIN bylaws, three (3) volunteers from the general membership are being sought to serve on the Nomination Committee (NomCom) for the fall 2002 ARIN Board of Trustees election. If interested, please submit your name, e-mail address and member organization name to memsvcs at arin.net no later than 5:00 PM EDT on July 24. Three names will be randomly selected from all eligible submissions. The business of the NomCom will take place via teleconference calls. Details regarding the responsibility of the committee are found in the Bylaws excerpts below. Thank you for your interest in participating. Regards, ARIN Member Services >From ARIN Bylaws: Article VI Section 4. Nomination and Election of Trustees. b. Nomination Committee. The Nomination Committee shall be appointed annually by the Board of Trustees. The Nomination Committee shall consist of seven (7) persons including: two (2) members of the Board of Trustees, two (2) members of the Advisory Council, and three (3) volunteer members from the General Membership who shall be selected by random lot. Any member of the Nomination Committee may be removed by a majority vote of the Board of Trustees. The Nomination Committee shall be responsible for identifying, recruiting, and certifying a properly selected slate of candidates to be placed in nomination before the General Membership for election. ... d. Duties of Nomination Committee. 1. The Nomination Committee shall select two (2) or more candidates recruited from the General Membership or recommended by the General Membership for each such vacancy or vacancies on the Board of Trustees as are to be filled at the ensuing election. 2. The Nomination Committee shall require each candidate to submit a curriculum vitae in form and format to be determined by the Board of Trustees in order to evaluate their experience and qualifications. 3. The Nomination Committee shall, following evaluation of candidates' experience and qualifications, submit its selected list of candidates for election to the Secretary of the Board of Trustees prior to the fall meeting of the General Membership of ARIN. 4. The Nomination Committee may not nominate anyone selected for the Nomination Committee in any year for a Trustee position in the same year. The NomCom is responsible for reviewing the list of nominees for BOT positions (submitted by the general membership), verifying the qualifications of these nominees and finally, selecting the slate of nominations for the elections. From memsvcs at arin.net Mon Jul 22 15:11:11 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 22 Jul 2002 15:11:11 -0400 (EDT) Subject: ARIN/LACNIC Transition Update Message-ID: Since November 2001, ARIN has been working very closely with LACNIC (The Latin American and Caribbean IP address Regional Registry) to prepare for their eventual emergence as a new Regional Internet Registry. As part of this transition process, ARIN and LACNIC have been conducting joint reviews of all IP and AS number requests coming from the emerging LACNIC region. On July 27, to begin the next step of the transition process, all IP and AS number requests from the LACNIC region will be submitted directly to LACNIC using LACNIC templates. These requests will continue to be reviewed under the current ARIN policies. The request process will also continue to include coordination between the LACNIC and ARIN registration staffs to ensure consistency. Also on July 27, registrations with postal addresses inside the emerging LACNIC region will be documented in the LACNIC WHOIS database. The list of countries that make up the emerging LACNIC region can be found at: http://lacnic.net/en/list.html More information about LACNIC is available at: http://www.lacnic.net Raymond A. Plzak President & CEO The American Registry for Internet Numbers Raul Echeberria Chairman, LACNIC Board of Directors From memsvcs at arin.net Wed Jul 24 14:05:36 2002 From: memsvcs at arin.net (Member Services) Date: Wed, 24 Jul 2002 14:05:36 -0400 (EDT) Subject: OPEN CALL for ASO Address Council Nominations from ARIN Region Message-ID: OPEN CALL for ASO Address Council Nominations from ARIN Region ------------------------------------------------------- This is an open call for nominations from the ARIN region to fill one seat on the ASO Address Council that becomes vacant with the expiration of Cathy Wittbrodt's term on December 31, 2002. The elected representative must be willing to serve a three (3) year term beginning January 1, 2003. If you are interested in nominating an individual or if you are interested in being nominated as a member of the Address Council, please carefully read the document below which describes the functions of the ASO, the Address Council and the role of the council members. Please visit http://www.arin.net/elections/aso/asonomform.html to submit your nominations or submit the information outlined below to aso-nominations at arin.net. Nominations will be accepted until 23:59 EDT September 30, 2002. Questions regarding this nomination process may be directed to memsvcs at arin.net. Regards, ARIN Member Services 1. The Address Supporting Organization -------------------------------------- The ASO was created through a Memorandum of Understanding (MoU) that was executed on October 18, 1999 between the current Regional Internet Registries (RIRs) and ICANN (http://www.arin.net/library/internet_info/mou.htm). The ASO is a consensus-based advisory body established within the ICANN Framework. The ICANN bylaws assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, interdomain routing identifiers, and the part of the DNS name space that is used to name these addresses and identifiers. Normally, proposals for global policies within the area of ASO responsibility will be developed within context of the RIRs' policy development forums, and then forwarded to ICANN through the ASO. Submissions by interested parties and other ICANN bodies will also be considered by this organization. The ASO is responsible for the appointment of three (3) Directors to ICANN, in accordance with ICANN's bylaws. The ASO conducts its business in an open and transparent fashion. 2. The Address Council ---------------------- The Address Council is responsible for managing the business functions of the ASO. Each RIR selects three (3) individuals to serve as members of the Address Council. Using the MoU-defined procedures as a guideline, Address Council members manage the policy development process in the areas where the ASO is responsible. Specifically, this includes the periodic hosting of an open General Assembly of the ASO, as well as the management of policy development activities. The other major role of the Address Council is the appointment of Directors to the ICANN Board of Directors. The Address Council follows the procedures described in the MoU, using an open call for nominations and an open process of selection. 3. The Role of Members of the Address Council --------------------------------------------- Members of the Address Council will not receive any compensation or reimbursement of expenses from the ASO. They will not be indemnified by the ASO, nor will the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. Council members will not represent any RIR, nor act as a representative of any other body. The Council members are appointed in their individual capacity, and their membership shall not be proxied by any other individual or organization. Upon request, ARIN will pay ASO AC meeting travel expenses for the three representatives it votes onto the Address Council. 4. Address Council Nominations Process -------------------------------------- Any individual may be nominated within this process, with the exception of staff members of any Regional Internet Registries. Self-nominations are permitted. Please visit http://www.arin.net/elections/aso/asonomform.html to submit your nominations or send the required information to aso-nominations at arin.net. The following information is required: Name of nominee: Country of residence: Organization name: E-mail address: Postal address: Phone number: Biographical information: (highlight track record of serving Internet community in ARIN's region) Motivation for nomination: (Please list reasons why you think this person will be a good representative of the ARIN community) Name of nominating individual: Organization: E-mail address: All nominees will be contacted via e-mail to confirm their willingness to serve as an Address Council member. If the nominee is not reachable via e-mail then the nomination will not be confirmed. All confirmed nominations will be listed on the ARIN website with biographical information. A procedure to allow others to express support for nominated individuals will be published on this website. 5. Selection Process and Time Schedule: ----------------------------------------------------- September 30, 2002 (23:59 EDT): Deadline for submission of nominations October 10, 2002: Website posting of all confirmed nominees October 23, 2002 (09:00 EST): On-line voting available for eligible ARIN members. October 29 and 30, 2002: On-site voting available at specified times for all attendees of the NANOG and ARIN meetings. Only RIR staff and those ARIN members who previously voted on-line are ineligible to vote. October 30, 2002 (17:00 EST): On-line voting booth closes October 31, 2002:The winner of the election will be announced during the ARIN X Public Policy meeting. ----------------------------------------------------------- From memsvcs at arin.net Mon Jul 29 12:11:17 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 29 Jul 2002 12:11:17 -0400 (EDT) Subject: Open Call for Nominations: ARIN Board and Advisory Council Message-ID: ARIN Board of Trustees and Advisory Council Nominations Sought An open call is issued for ARIN members to nominate candidates for two (2) seats on the Board of Trustees and five (5) seats on the Advisory Council that become open when current terms expire on December 31, 2002. All new terms are for three years and begin January 1, 2003. The Board seats opening are those currently held by David Conrad and the seat recently vacated by Scott Marcus. The five seats opening on the Advisory Council are currently held by Bill Darte, Mark Kosters, Alec Peterson, Lea Roberts, and John Sweeting. Individuals may be re-elected to both the Board and Council. Nominations must be received by 23:59 EDT September 30, 2002 in order to be eligible. Use the ARIN 2002 Nomination Election Form on the ARIN website (http://www.arin.net/elections/index.html) or submit the required information below to ac-nominations at arin.net or bot-nominations at arin.net, respectively: Name of nominee Organization E-mail address Phone number Name of person making the nomination. Organization of person making the nomination. E-mail address of person making the nomination All nominees will be contacted via e-mail to verify that they accept their nomination and to request biographical information. If they cannot be reached, the nomination will not be accepted. BOARD OF TRUSTEE NOMINATIONS ARIN's Board of Trustees is responsible for the business affairs, financial health, and property of ARIN. Board nominees should be able to demonstrate experience in performing fiduciary duties at the corporate level and making high-level budgetary, contractual, or other corporate/executive decisions. Board nominees should be available to attend several board meetings a year. There are three ways to become a candidate for a seat on the Board of Trustees: 1. Be nominated by an ARIN member. Nominees do not have to be ARIN members. 2. If you are an ARIN member, you may self-nominate. 3. Nomination by petition as described below. Nominations for the Board may be made without the Nomination Committee's participation by presenting a petition signed by 5% of the total ARIN membership. Current ARIN membership totals 1,840; therefore ninety two (92) members will be required to send statements of support to elections at arin.net in order for the petitioning candidate to be nominated Per the ARIN Bylaws, a Nomination Committee has been formed to aid in the Board of Trustees election process. The seven-member 2002 Nomination Committee members are: Board Representatives: Scott Bradner, Bill Manning Advisory Council Representatives: Bill Darte, Barbara Roseman General Members Representatives: Daniel Salama, IFX Corporation; Miguel Fernandez, Prima SA; Kris Foster, Telus The Nomination Committee is responsible for identifying and recruiting nominees, in addition to certifying a properly selected list of candidates for the Board of Trustees. The Nomination Committee is required to send at least two (2) candidates per open seat to the general membership for a vote. ADVISORY COUNCIL NOMINATIONS The Advisory Council functions as an advisory body to the Board of Trustees on matters involving IP allocation policies and related issues that the Board may request, and on those issues that the membership promotes. Council nominees should be knowledgeable in the technical aspects of network resources and will be expected to attend several meetings each year. There are three ways to become a candidate for a seat on the Advisory Council: 1. Be nominated by an ARIN member. Nominees do not have to be ARIN members. 2. If you are an ARIN member, you may self-nominate. 3. Nomination by petition as described below. Present a petition signed by 5% of the ARIN membership. Current ARIN membership totals 1,840; therefore ninety two (92) members will be required to send statements of support to elections at arin.net in order for the petitioning candidate to be nominated. All nominations made and accepted according to the ARIN Bylaws and the time schedule set forth below will be forwarded to the general membership for a vote. TIMELINE FOR BOT AND AC ELECTIONS July 29, 2002: Call for BOT and AC nominations announced via e-mail to arin-announce at arin.net and posted on the ARIN website. September 30, 2002, 23:59 EDT: Call for nominations closes. October 10, 2002: Nominees for the Advisory Council and the Board of Trustees will be announced on ARIN's web site along with their biographical information. The final list of nominees will also be sent by e-mail to each ARIN member representative. November 1, 2002: At the members meeting to be held in Eugene, Oregon, the BOT and AC nominees will be given the opportunity to briefly present their qualifications to the general membership. November 4, 2002: Elections open at 9:00 am EST via online balloting on the ARIN website. November 11, 2002: Elections close at 9:00 am EST. November 15, 2002: ARIN President announces election results. --------------------------------------------------------------- Please send any questions concerning this election process to memsvcs at arin.net. Regards, ARIN Member Services From memsvcs at arin.net Mon Jul 29 15:57:02 2002 From: memsvcs at arin.net (Member Services) Date: Mon, 29 Jul 2002 15:57:02 -0400 (EDT) Subject: New IPv6 Allocation Policies Ratified Message-ID: The following new policy has been ratified in the ARIN region and will be implemented on August 1, 2002: Policy 2001-4: Modification to the IPv6 Allocation Policies The three RIRs have compiled the "IPv6 Address Allocation and Assignment Policy" document dated June 26, 2002, using feedback received from the RIR communities since the publishing of the provisional IPv6 document in 1999. In the interest of maintaining IPv6 policies that are global in scope, ARIN accepts the document with language on initial allocations as amended following the APNIC 13 and ARIN IX Public Policy Meetings. The full text of the "IPv6 Address Allocation and Assignment Policy" document can be viewed below. This new policy text and accompanying request templates will be posted on the ARIN website on August 1, 2002. This policy replaces ARIN's existing IPv6 allocation policies and was created in accordance with ARIN's Internet Resource Policy Evaluation Process which can be viewed here: http://www.arin.net/policy/ipep.html Member Services American Registry for Internet Numbers (ARIN) ##### * ##### The following modifications to this document have been made since its final posting on June 26, 2002: * Duplicate word "Assignment" removed from title * Page numbers removed * Editorial comment regarding change status of definitions removed ##### * ##### IPv6 Address Allocation and Assignment Policy June, 26 2002 Status of this Memo This document was developed through joint discussions among the APNIC, ARIN and RIPE communities. Abstract This document defines registry policies for the assignment and allocation of globally-unique IPv6 addresses to ISPs and other organizations. This document obsoletes the "Provisional IPv6 assignment and allocation policy document". This document was developed jointly by the communities of APNIC, ARIN, and RIPE. Contents Status of this Memo 1. Introduction 1.1. Overview 2. Definitions 2.1. Internet Registry (IR) 2.2. Regional Internet Registry (RIR) 2.3. National Internet Registry (NIR) 2.4. Local Internet Registry (LIR) 2.5. Allocate 2.6. Assign 2.7. Utilization 2.8. HD-Ratio 2.9. End site 3. Goals of IPv6 address space management 3.1. Goals 3.2. Uniqueness 3.3. Registration 3.4. Aggregation 3.5. Conservation 3.6. Fairness 3.7. Minimized Overhead 3.8. Conflict of goals 4. IPv6 Policy Principles 4.1. Address space not to be considered property 4.2. Routability not guaranteed 4.3. Minimum Allocation 4.4. Consideration of IPv4 Infrastructure 5. Policies for allocations and assignments 5.1. Initial allocation 5.1.1. Initial allocation criteria 5.1.2. Initial allocation size 5.2. Subsequent allocation 5.2.1. Subsequent allocation criteria 5.2.2. Applied HD-Ratio 5.2.3. Subsequent Allocation Size 5.3. LIR-to-ISP allocation 5.4. Assignment 5.4.1. Assignment address space size 5.4.2. Assignment of multiple /48s to a single end site 5.4.3. Assignment to operator's infrastructure 5.5. Registration 5.6. Reverse lookup 5.7. Existing IPv6 address space holders 6. References 7. Appendix A: HD-Ratio 8. Appendix B: Background information 8.1. Background 8.2. Why a joint policy 8.3. The size of IPv6's address space 8.4. Acknowledgment 1. Introduction 1.1. Overview This document describes policies for the allocation and assignment of globally-unique Internet Protocol Version 6 (IPv6) address space. It updates and obsoletes the existing Provisional IPv6 Policies in effect since 1999 [RIRv6-Policies]. Policies described in this document are are intended to be adopted by each registry. However, adoption of this document does not preclude local variations in each region or area. [RFC2373, RFC2373bis] designate 2000::/3 to be global unicast address space that IANA may allocate to the RIRs. In accordance with [RFC2928, RFC2373bis, IAB-Request], IANA has allocated initial ranges of global unicast IPv6 address space from the 2001::/16 address block to the existing RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. Because end sites will generally be given /48 assignments [RFC 3177, RIRs- on-48s], the particular emphasis of this document is on policies relating the bits within 2000::/3 to the left of the /48 boundary. However, since some end sites will receive /64 and /128 assignments, all bits to the left of /64 are in scope. This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6. 2. Definitions The following terms and their definitions are of particular importance to the understanding of the goals, environment, and policies described in this document. Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below. +--------+ | IANA | +--------+ | +-----------+ | | +--------+ +--------+ | RIR | | RIR | Regional Internet +--------+ +--------+ Registries (APNIC, ARIN, RIPE NCC, | | plus possible future RIRs) | | | +-----+ | | NIR | National Internet | +-----+ Registries (AP region) | | +--------+ +--------+ |LIR/ISP | |LIR/ISP | Local Internet +--------+ +--------+ Registries (ISPs) | | +--------+ | | | | +-------+ +----+ +----+ |EU(ISP)| | EU | | EU | End users +-------+ +----+ +----+ 2.1. Internet Registry (IR) An Internet Registry (IR) is an organization that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above. 2.2. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. 2.3. National Internet Registry (NIR) A National Internet Registry (NIR) primarily allocates address space to its members or constituents, which are generally LIRs organized at a national level. NIRs exist mostly in the Asia Pacific region. 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs. 2.5. Allocate To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. 2.6. Assign To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties. 2.7. Utilization Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts (/48). The actual usage of addresses within each assignment will be quite low, when compared to IPv4 assignments. In IPv6, "utilization" is only measured in terms of the bits to the left of the /48 boundary. In other words, utilization refers to the assignment of /48s to end sites, and not the number of addresses assigned within individual /48s at those end sites. Throughout this document, the term utilization refers to the allocation of /48s to end sites, and not the number of addresses assigned within individual /48s within those end sites. 2.8. HD-Ratio The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an adaptation of the H-Ratio originally defined in [RFC1715] and is expressed as follows: Log (number of allocated objects) HD = ------------------------------------------------ Log (maximum number of allocatable objects) where (in the case of this document) the objects are IPv6 site addresses (/48s) assigned from an IPv6 prefix of a given size. 2.9. End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: - that service provider assigning address space to the end user - that service provider providing transit service for the end user to other sites - that service provider carrying the end user's traffic. - that service provider advertising an aggregate prefix route that contains the end user's assignment 3. Goals of IPv6 address space management 3.1. Goals IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy. 3.2. Uniqueness Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified. 3.3. Registration Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to end users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. 3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. IPv6 address policies should seek to avoid fragmentation of address ranges. Further, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation. 3.5. Conservation Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. 3.6. Fairness All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size or any other factor. 3.7. Minimized Overhead It is desirable to minimize the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions. 3.8. Conflict of goals The goals described above will often conflict with each other, or with the needs of individual IRs or end users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole. In IPv6 address policy, the goal of aggregation is considered to be the most important. 4. IPv6 Policy Principles To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below. 4.1. Address space not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. The policies in this document are based upon the understanding that globally-unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license. RIRs will generally renew licenses automatically, provided requesting organizations are making a good-faith effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organization is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment. 4.2. Routability not guaranteed There is no guarantee that any address allocation or assignment will be globally routable. However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability. 4.3. Minimum Allocation RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32. 4.4. Consideration of IPv4 Infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. 5. Policies for allocations and assignments 5.1. Initial allocation 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organizations within two years. 5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. Organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure. 5.2. Subsequent allocation Organizations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies. 5.2.1. Subsequent allocation criteria Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /48 assignments. The HD- Ratio [RFC 3194] is used to determine the utilization thresholds that justify the allocation of additional address as described below. 5.2.2. Applied HD-Ratio The HD-Ratio value of 0.8 is adopted as indicating an acceptable address utilization for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilization value for a given address block size. 5.2.3. Subsequent Allocation Size When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left. If an organization needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement. 5.3. LIR-to-ISP allocation There is no specific policy for an organization (LIR) to allocate address space to subordinate ISPs. Each LIR organization may develop its own policy for subordinate ISPs to encourage optimum utilization of the total address block allocated to the LIR. However, all /48 assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary. 5.4. Assignment LIRs must make IPv6 assignments in accordance with the following provisions. 5.4.1. Assignment address space size Assignments are to be made in accordance with the existing guidelines [RFC3177,RIRs-on-48], which are summarized here as: - /48 in the general case, except for very large subscribers - /64 when it is known that one and only one subnet is needed by design - /128 when it is absolutely known that one and only one device is connecting. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on IPv6 user networks as they did in IPv4, except for the cases described in Section 4.4 and for the purposes of measuring utilization as defined in this document. 5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. 5.4.3. Assignment to operator's infrastructure An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator. 5.5. Registration When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /48 networks. When more than a /48 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an RIR/NIR database. RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time. IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration. 5.6. Reverse lookup When an RIR/NIR delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. 5.7. Existing IPv6 address space holders Organizations that received /35 IPv6 allocations under the previous IPv6 address policy [RIRv6-Policies] are immediately entitled to have their allocation expanded to a /32 address block, without providing justification, so long as they satisfy the criteria in Section 5.1.1. The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document. 6. References [RFC1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, RFC 1715. [IAB-Request] "Email from IAB to IANA", http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt. [RFC2373] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. July 1998, RFC 2373. [RFC2373bis] draft-ietf-ipngwg-addr-arch-v3-07.txt. [RFC2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000, RFC 2928. [RFC3177] "IAB/IESG Recommendations on IPv6 Address". IAB, IESG. September 2001, RFC 3177. [RFC3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, RFC 3194. [RIRs-on-48] http://www.arin.net/library/guidelines/ipv6_initial.html, [RIRv6-Policies] http://www.arin.net/regserv/ipv6/ipv6guidelines.html, http://www.ripe.net/ripe/docs/ripe-196.html, http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html. 7. Appendix A: HD-Ratio The HD-Ratio is not intended to replace the traditional utilization measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio still requires counting the number of assigned objects. The primary value of the HD-Ratio is its usefulness at determining reasonable target utilization threshold values for an address space of a given size. This document uses the HD-Ratio to determine the thresholds at which a given allocation has achieved an acceptable level of utilization and the assignment of additional address space becomes justified. The utilization threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as: ((48-P)*HD) T = 2 Thus, the utilization threshold for an organization requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilization refers to the allocation of /48s to end sites, and not the utilization of those /48s within those end sites. It is an address allocation utilization ratio and not an address assignment utilization ratio. In accordance with the recommendations of [RFC 3194], this document adopts an HD-Ratio of 0.8 as the utilization threshold for IPv6 address space allocations. The following table provides equivalent absolute and percentage address utilization figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 8. Appendix B: Background information 8.1. Background The impetus for revising the 1999 Provisional IPv6 policy started with the APNIC meeting held in Taiwan in August 2001. Follow-on discussions were held at the October, 2001 RIPE and ARIN meetings. During these meetings, the participants recognized an urgent need for more detailed, complete policies. One result of the meetings was the establishment of a single mailing list to discuss a revised policy together with a desire to develop a general policy that all RIRs could use. This document does not provide details of individual discussions that lead to policies described in this document; detailed information can be found in the individual meeting minutes at the www.apnic.net, www.arin.net, and www.ripe.net web sites. 8.2. Why a joint policy IPv6 addresses are a public resource that must be managed with consideration to the long-term interests of the internet community. Although regional registries adopt allocation policies according to their own internal processes, address policies should largely be uniform across registries. Having significantly varying policies in different regions is undesirable because it can lead to situations where "registry shopping" can occur as requesting organizations request addresses from the registry that has the most favorable policy for their particular desires. This can lead to the policies in one region undermining the efforts of registries in other regions with regards to prudent stewardship of the address space. In cases where regional variations from the policy are deemed necessary, the preferred approach is to raise the issue in the other regional registries in order to develop a consensus approach that all registries can support. 8.3. The size of IPv6's address space Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space. It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier [RFC2373], will often be a globally-unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration [RFC2462]. The middle 16 bits of an address indicate the subnet ID. Per [RFC 3177, RIRs-on-48s], this field will often be inefficiently utilized, but the operational benefits of a consistent width subnet field were deemed to be outweigh the drawbacks. The decisions to inefficiently utilize the bits to the right of /48 were made under the knowledge and assumption that the bits to the left of /48 would be managed prudently and that if done so, will be adequate for the expected lifetime of IPv6 [RFC3177]. 8.4. Acknowledgment The initial version of this document was produced by The JPNIC IPv6 policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly. An editing team was then organized by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of RIPE NCC's IPv6 WG). The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Gert Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woeber. The final editing of this document was done by Thomas Narten. ## END ##