APNIC guidelines for IPv6 allocation and assignment requests (Version 0.3 : 20040206) About this document These guidelines are intended to complement the document Policies for IPv6 address space management in the Asia Pacific region, which provides for APNIC to publish guidelines relating to specific request evaluation requirements and best current practice issues. These guidelines will be updated from time to time, in consultation with the Asia Pacific and global Internet communities, to ensure that they remain appropriate to the current addressing environment. Table of contents 1. Introduction 2. Scope 3. Additional guidance 4. Goals of address space management 5. Application of guidelines 6. Definition of a 'site' 6.1 Assignment address space size 7. Initial allocation criteria 7.1 Use of existing IPv4 infrastructure 7.2 Documentation required 7.2.1 Supplementary Document 7.3 Closed networks 8. Second opinion requests 8.1 Sub-Allocations and Second Opinion Request 8.2 Documentation required 9. Subsequent allocations 10. Requesting a reverse delegation 11. Database registrations 1. Introduction These guidelines are developed within the APNIC community, and are consistent with the goals and policies applicable to IPv6 address space management. They are intended to assist organisations requesting IPv6 address space only. Nothing in these guidelines should be considered to replace or modify any of the specific policies defined in other APNIC documents. 2. Scope This document applies to the management of global IPv6 public address space in the Asia Pacific region. Where practical, the guidelines in this document are expressed in relation to types of connectivity, rather than to specific technologies. This document does not apply to IPv4, Multicast, or 'Unique local IPv6 unicast address, or Autonomous System numbers. It should be read in conjunction with other APNIC documents, particularly APNIC-089 "IPv6 Address Allocation and Assignment Policy" 3. Additional guidance These guidelines are not intended to be exhaustive. Additional guidance and examples are available from the help information available for each APNIC request form and in FAQs and other information on the APNIC web site: Resource Guides http://www.apnic.net/services APNIC FAQs http://www.apnic.net/info/faq 4. Goals of address space management In this document, all reference to the goals of address space management refer to the goals described in Policies for IPv6 address space management in the Asia Pacific region, namely: * uniqueness; * registration; * aggregation; * conservation; * fairness; and * minimized overhead. 5. Application of guidelines This document is primarily intended to guide ISPs when making assignments to their customers or requesting address space from APNIC. The issues discussed in this document reflect many of the considerations used by APNIC in evaluating requests for initial allocations and subsequent allocations. It is intended that NIRs will either adopt these or similar guidelines for their own members. 6. Definition of a 'site' An end site is defined as an end user who has a business relationship, i.e. has a contract, with a service provider to receive their service. The end user (the end site) cannot re-assign IP addresses to other organization out of its assigned IP address space. The number of sites is counted in accordance with the number of contracts. Each 'end site' is eligible to receive /48 assignment in general case. For example; (Single site) - A home(corporate) user who has a single contract with a service provider for its own device and/or network. - A home(corporate) user who has multiple devices to connect the internet, but has only one contract with a service provider. (Multiple sites) - A home (corporate) user who has multiple contracts with (a) service provider(s). - A home (corporate) user who has multiple separate networks, and they are not connected each other because each network has different management policy, even if they are in the same place. (-note- In this case this user is considered to have multiple contracts with (a) service provider(s). e.g.) A merged company with independenet networks If two or more organizations each possessing independent networks merged into a single organization but continues to exchanging seperate contracts with ISPs, they can be considered as multiple sites. 6.1 Assignment address space size A single site may be assigned a /48 in general case as the policy defines. For example; - Residential subscribers, connecting through on-demand or always-on connections such as through ADSL/CATV, should receive a /48. - Even in the case where a /64 or a /128 seems to approproate initially (e.g. single PC), LIRs still can assign a /48 when future growth is anticipated. - A single site may receive larger address space than a /48 only if the case is justified by RIR/NIR level. (see 8. Second Opnion Request) 7. Initial allocation criteria According to current IPv6 policy, to qualify for an initial allocation of IPv6 address space, an organization must meet the criteria stated in IPv6 policy clause 5.1.1. Followings are the supplementary information about initial allocation criteria especially on 200*/48 criteria, to which the requestor can refer. (Planning 200*/48 assignment) - An organization must provide a 'plan' to make at least 200 /48 assignments, but is not necessarily required to 'commit' 200. RIR/NIR regards the exisitence of a 'plan' to provide IPv6 services or its readiness to commence, not its feasibility. e.g) An ISP which has 200 or more customers can meet the initial allocation criteria of 200*/48, if it plans to provide them with IPv6 connectivity service. - sub-allocations to downstream ISPs can be taken into account as "to be assigned /48". (*) e.g) The following case meets the initial allocation criteria of 200*/48. Plan within the next two years: /44 sub-allocation (= 16*/48 assignments) assignments to POPs 20*/48 assignments to "sites" 170*/48 ----------------------------------------- total 206*/48 > 200*/48 (*) When subsequent allocation requests, only /48s registered to RIR/NIR database are counted (not all the sub-allocated space. See 9. Subsequent Allocations) - A /48 can be assigned for customers to both static and dynamically addressed networks. - Existing IPv4 infrastructure/customers can also be taken into consideration. e.g) If a CATV provider has 4,000 IP static connection(*) customers in IPv4 and 5%(200) of them are expected to subscribe IPv6 service connection, then, this provider meets the initial allocation criteria of 200*/48. (*) Even if LIRs assign a single static IP in IPv4, it's up to the ISP to assign a /48 to these customers. 7.1 Use of existing IPv4 infrastructure LIRs can justify their requested initial allocation size by the number of their existing IPv4 users as well as the extent of their IPv4 network infrastructure. LIRs can choose this option to show their eligibility to receive initial IPv6 allocation. From this perspective LIRs are likely to be eligible for an initial allocation criteria in case they; - meet the current IPv4 allocation criteria AND - receive the current IPv4 allocation as an LIR AND - plan to tranfer the existing IPv4 infrastructure or customers partly or wholly to IPv6 in two years. Note: this is just to provide an idea, and not guarantee the initial allocation. However LIRs are still requested to provide the information on their plan on how many /48s are to be assigned within two years to ensure that they meet the 200*/48 criteria, or to decide the address block size allocated when they request larger space than a /32. 7.2 Documentation required When LIRs request their initial IPv6 address allocation to RIR/NIR, LIRs are requested to provide designated request form as well as the following supportive information. - Network diagram - Network equipment information. This is to ensure LIR has a plan to implement IPv6 ready infrastructure. - Approximate deployment date. - Service plan (Web hosting, Access service, etc) - IPv4 infrastructure and/or customer information if LIR chooses the option of use of existing IPv4 infrastructure (see 7.1 Use of existing IPv4 infrastructure). 7.2.1 Supplementary Document When requesting an initial allocation to RIR/NIR, model/Vendor name of LIR's network equipment is not mandatory but there may be a case that RIR/NIR asks those information if LIRs require a plenty of pool address such as CATV/ADSL operator. 7.3 Closed networks APNIC will allocate global IPv6 address space to organization which network is reachable or not reachable from global IPv6 Internet, if its organization meets the conditions stated in current IPv6 policy, [5.1.1 Initial allocation criteria], since it does not require global route advertisement. For example organizations below are likely to meet 5.1.1(c) in the current IPv6 policy despite they are closed networks. Therefore if they meet other criteria listed in 5.1.1, they are eligible to obtain IPv6 addresses. - An ISP which provides IPv6 services to other organization (company or individual) but its network is closed within its ISP or restricted ISPs such as peering partners. - A large company who provides IPv6 connectivity to its group companies or subsidiaries and its network is closed within itself. 8. Second opinion requests When one single end site requires shorter prefix than /48 (e.g. /47 , /46...)for 2 years requirement, or it requires additional /48(s) after its initial assignment, LIRs must follow Second opinion request process prior to the assignment. It is considered that a /48 address space is sufficent per one single end site, and there is no experience with such assignments as /47 to a single end site. Until such experience is gained RIR/NIR will review all such assignements. 8.1 Sub-Allocations and Second Opinion Request RIR/NIR do not require a Second Opinion Request for sub-allocations to downstream ISPs. (Please see [9. Subsequent allocations].) Nevertheless when LIRs are unsure how much address space to sub-allocate, LIRs are recommended to ask RIRs/NIRs for advice. 8.2 Documentation required In addition to the designated request form, LIRs are requested to provide RIR/NIR with the detailed network information as below; - Network diagram of an end-site - Network equipment information - Full details to justify multiple /48 assignments to an end-site (e.g. the number of clients (PCs or other NW equipments) or other information which justify multiple /48s assignment) 9. Subsequent allocations - An example of a typical ISP. (1) 1st subsequent allocation A typical ISP receives /32 that is 65,536 * /48s as an initial allocation. If this ISP allocates or assigns 7,132 * /48s to it's customers and its POPs, this ISP has a right of the 1st subsequent allocation. 7,132 is from the HD-Ratio table ( Policy : Appendix A ) Example assignments to POPs 326 * /48 assignments to end sites 6,500 * /48 assignments through downstream ISP 306 * /48 ------------------------------------------------ total 7,132 * /48s (2) Subsequent allocation (Example of the 2nd subsequent allocation) This ISP receives additional /32 from an adjacent address block as the second allocation. Now, this ISP has one /31 address block. If this ISP allocates or assigns 12,417 * /48s including the previous 7,132 * /48s to it's customers and its POPs, this ISP has a right of the 2nd subsequent allocation. 12,417 is from the HD-Ratio table ( Policy : Appendix A ) - Utilization in case of Sub-allocation Utilization is calculated based on the number of /48 assignments which are registered in the registry database(*) including /48 assignments through downstream ISPs. It is not based on the size of sub-allocations to the downstream ISPs. (*) needed clarified definition. If a sub-allocation is made to a down stream ISP, but assignments are not registered in the database, it will not considered utilized. e.g.) /40 sub-allocation is made to a downstream ISP. 2*/48 is assigned from this block. In this case, 2*/48 is considered as utilized, not /40(256*/48). So, LIRs should carefully consider and justify the sub-allocation size'. In IPv4, Sub-allocations to downstream ISPs are considered as assignment. - RIRs/NIRs do not request to LIRs for a Second Opinion Requests (SOR) for sub-allocations to downstream ISPs. In IPv4, To prevent LIRs from making unrealistic sub-allocations, RIRs/NIRs have a policy requesting for an SOR, so that RIRs/NIRs can see the details of the allocations. - RIRs temporarily reserve 8 * /32 adjacent address blocks for each organization. This space is worth /29. But unless each organization obtains additional allocation, these spaces can be allocated to other organizations based on the Space Allocation System. http://xxx.xxx.apnic.net 10. Requesting a reverse delegation - Responsibility of delegation - When RIR allocates to LIR, - Reserve lookup must be delegated to LIR. - When LIR assigns to end site, - Reserve lookup must be delegated to end site upon end site's request. - When LIR allocates to it's downstream ISP, - Reserve lookup must be delegated to LIR. - When downstream ISP assigns to end site - Reserve lookup must be delegated from downstream ISP to end site upon end site's request. It means it is downstream ISP or end site's responsibility. - Registration of each host It is not compulsory nor recomended. There is no recommendation or suggenstion about it in any document. - Registration of Temporary addresses defined in RFC3041 It is not compulsory nor recomended. The reason is same as Registration of each host. - Minimum size - Minimum size of reverse delegation is /48. - ip6.int. / ip6.arpa - ip6.int is now deprecated for all organizations. - Shifting from ip6.int. to ip6.arpa. is appreciated for all organizations. - If it is impossible to shift, the organization are requested to have both environment. 11. Database registrations - Definition of Database In this policy, "database" means the Whois Databases of RIRs and NIRs. - The organization responsible for registration (1) Allocation Each RIR is responsible for registering initial and subsequent allocation information in a database. Typical example is the /32 or /31 allocations to ISPs. (2) Assignment (a) When an organization that is holding an address allocation makes assignments, this organization is responsible for registering the assignment. Typical example of this organization is ISP. (b) When an organization makes an assignment through downstream ISP, Ether LIR or downstream ISP is responsible for registering the assignment. So, LIRs need some rules or contracts between downstream ISPs in order to receive assignment information. (3) Sub-allocations Each sub-allocations must be registered by LIRs when making allocations to its downstream ISPs. - Database to be registered - If NIR doesn't have it's own database, RIR's database is the one to be registered. - If NIR starts it's own database service, each organizaton must register NIR's database after NIR's announcement. - Items to be registered http://www.apnic.net/db/ref/attributes/attributes-inet6num.html - Registration grater then /48 For example, the organization which has assigned /47 have to register the /47 block in the database. - Updating of the database When some information is updated in the database, the organization which has assigned it is responsible for updating the database. ---------------------------------------------------------------------- End of document