|

3. APNIC Internet Number Resource Policies

Part 1: Policy Environment

1 Leave a comment on paragraph 1 0 1.0. Introduction

2 Leave a comment on paragraph 2 0 The Asia Pacific Network Information Centre (APNIC) is the Regional Internet Registry (RIR) for the Asia Pacific. It is responsible for the regional distribution of public Internet address space and related resources, including Internet Protocol version 4 (IPv4) address space, Internet Protocol version 6 (IPv6) address space, and Autonomous System Numbers (ASNs). APNIC also coordinates the development and implementation of policies to manage those resources.

3 Leave a comment on paragraph 3 0 This document outlines the overall principals and goals of Internet number resource distribution. It also details specific policies for the distribution and management of these resources in the Asia Pacific region.

4 Leave a comment on paragraph 4 0 The policies and definitions described in this document were developed by the Internet community of the Asia Pacific region through a consensus process facilitated by APNIC. The policies are to be implemented by APNIC, by National Internet Registries (NIRs), and by Local Internet Registries (LIRs) throughout the region.

5 Leave a comment on paragraph 5 0 1.1. Scope

6 Leave a comment on paragraph 6 0 This document describes policies for the responsible management of global Internet number resources in the Asia Pacific region.

7 Leave a comment on paragraph 7 0 Specifically, this document focuses on policies relating to:

  • 8 Leave a comment on paragraph 8 0
  • The delegation of Internet Protocol version 4 (IPv4) address space.
  • The allocation and assignment of Internet Protocol version 6 (IPv6) address space.
  • The assignment of Autonomous System Numbers (ASNs).

9 Leave a comment on paragraph 9 0 1.1.1. Additional guidelines and policies

10 Leave a comment on paragraph 10 0 This document should be read in conjunction with other APNIC documents, policies, and guidelines; including those dealing with membership and fees, as these documents may provide additional operational guidance, or may impose additional requirements on resource holders.

11 Leave a comment on paragraph 11 0 In addition to the eligibility criteria described in this document, APNIC may publish other information relating to Internet number resources, including:

  • 12 Leave a comment on paragraph 12 0
  • further descriptions of evaluation procedures;
  • summaries of the best current practices that organizations requesting resources will generally be expected to adopt; and
  • other information that may assist organizations to request resources.

13 Leave a comment on paragraph 13 0 This document does not provide specific details of request evaluation by APNIC, or of expectations relating to specific technologies. Such details are dependent on technological advances, and may change frequently. Therefore, to assist organizations to request address space, APNIC publishes separate guideline documents relating to specific technologies or techniques as required.

14 Leave a comment on paragraph 14 0 These guidelines are developed within the APNIC community and will be consistent with the goals and policies described in this document.

15 Leave a comment on paragraph 15 0 1.1.2. Private address space

16 Leave a comment on paragraph 16 0 This document does not describe specific addressing policies related to multicast or private address space. The use of private address space may be appropriate for addressing networks where there are no technical requirements for the use of public address space. In general, private address space should be used for networks not directly connected to the Internet.

17 Leave a comment on paragraph 17 0 1.2. Hierarchy of resource distribution

18 Leave a comment on paragraph 18 0 IP addresses and ASNs are distributed in accordance with the hierarchical structure initially described in RFC720 and represented simply in fig.1.

19 Leave a comment on paragraph 19 0 [Figure 1: Diagram of distribution hierarchy]

20 Leave a comment on paragraph 20 0 In this hierarchy, IANA allocates address space to APNIC, to be redistributed throughout the Asia Pacific region. APNIC allocates address space to Internet Registries (IRs) and also delegates to them, the authority to make assignments and allocations. In some cases APNIC assigns address space to end-users. National and Local IRs allocate and assign address space to their Members and customers under the guidance of APNIC and in accordance with the relevant policies and principals described in this document.

21 Leave a comment on paragraph 21 0  

22 Leave a comment on paragraph 22 0 2.0. Definitions

23 Leave a comment on paragraph 23 0 The following terms and definitions are used in APNIC documents.

24 Leave a comment on paragraph 24 0 2.1. Internet Registry (IR)

25 Leave a comment on paragraph 25 0 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.

26 Leave a comment on paragraph 26 0 Internet Registries include:

28 Leave a comment on paragraph 28 0 2.1.1. Regional Internet Registry (RIR)

29 Leave a comment on paragraph 29 0 Regional Internet Registries (RIRs) are established and authorized by their respective regional communities, and recognized by the IANA to serve and represent large geographical regions. Their primary role is to manage, distribute, and register public Internet address space within their respective region. There are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and the RIPE NCC.

30 Leave a comment on paragraph 30 0 2.1.2. National Internet Registry (NIR)

31 Leave a comment on paragraph 31 0 National Internet Registries (NIRs) are established and authorized by their respective regional communities, and recognized by RIRs to delegate address space to their Members or constituents, which are generally LIRs organized at a national level. NIRs are expected to apply their policies and procedures fairly and equitably to all Members of their constituency.

32 Leave a comment on paragraph 32 0 The policies in this document apply to NIRs; however, this document does not describe the entire roles and responsibilities of NIRs with respect to their formal relationship with APNIC. Such roles and responsibilities may be described in other documents and agreements including;

34 Leave a comment on paragraph 34 0 2.1.3. Local Internet Registry (LIR)

35 Leave a comment on paragraph 35 0 A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides.

36 Leave a comment on paragraph 36 0 LIRs are generally Internet Service Providers (ISPs), and may assign address space to their own network infrastructure and to users of their network services. An LIR’s customers may be other “downstream” ISPs, which further assign address space to their own customers.

37 Leave a comment on paragraph 37 0 2.2. Address space

38 Leave a comment on paragraph 38 0 In this document, address space means public unicast IP address ranges, which include IP version 4 (IPv4) and IP version 6 (IPv6).

39 Leave a comment on paragraph 39 0 2.2.1. Delegated address space

40 Leave a comment on paragraph 40 0 APNIC “delegates” addresses to its account holders. These delegations can be for use on the organization’s own infrastructure (an “assignment”) or for subsequent delegation by the organization to its customers (an “allocation”).

41 Leave a comment on paragraph 41 0 2.2.2. Allocated address space

42 Leave a comment on paragraph 42 0 Allocated address space is address space that is distributed to IRs or other organizations for the purpose of subsequent distribution by them.

43 Leave a comment on paragraph 43 0 2.2.3. Assigned address space

44 Leave a comment on paragraph 44 0 Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive use within the Internet infrastructure they operate.

45 Leave a comment on paragraph 45 0 2.3. Autonomous System (AS)

46 Leave a comment on paragraph 46 0 An Autonomous System (AS) is a connected group of one or more IP prefixes run by one or more network operators under a single and clearly-defined routing policy.

47 Leave a comment on paragraph 47 0 2.3.1. Autonomous System Number (ASN)

48 Leave a comment on paragraph 48 0 An Autonomous System Number (ASN) is a unique two- or four-byte number associated with an AS. The ASN is used as an identifier to allow the AS to exchange dynamic routing information with other Autonomous Systems.

49 Leave a comment on paragraph 49 0 2.4. Multihomed

50 Leave a comment on paragraph 50 0 Multihoming is a way of connecting an organization’s network to the public Internet through more than one AS.

51 Leave a comment on paragraph 51 0 2.5. Internet resources

52 Leave a comment on paragraph 52 0 Internet resources are public IPv4 and IPv6 address numbers, Autonomous System Numbers, and reverse DNS delegations.

53 Leave a comment on paragraph 53 0 2.5.1. Current resources

54 Leave a comment on paragraph 54 0 Current resources are Internet resources registered by APNIC under explicit policies and agreements.

55 Leave a comment on paragraph 55 0 2.5.2. Historical resources

56 Leave a comment on paragraph 56 0 Historical resources are Internet resources registered under early registry policies without formal agreements and include:

  • 58 Leave a comment on paragraph 58 0
  • Registrations transferred as part of the Early Registration Transfer (ERX) project
    • 58 Leave a comment on paragraph 58 0
    • Most historical registrations were initially made by the global registries that predated ARIN, such as DDN-NIC, SRI-NIC, and InterNIC. ARIN inherited these registrations automatically when it was established. Historical registrations made to organizations in the APNIC region were transferred to APNIC during 2003 and 2004 as part of the RIRs’ Early Registration Transfer (ERX) project.
    • A list of resources transferred to APNIC as part of the ERX project is available at: http://www.apnic.net/erx
  • Historical APNIC resources
    • 59 Leave a comment on paragraph 59 0
    • Historical APNIC resources were delegated to organizations by APNIC prior to the introduction of a Membership structure. These resources have always been registered in the APNIC Whois Database, but if the resource holder did not become an APNIC Member at any time after the introduction of the Membership structure, the resources were not made subject to current APNIC policies.

60 Leave a comment on paragraph 60 0 2.6. Internet Exchange Point (IXP)

61 Leave a comment on paragraph 61 0 An Internet Exchange Point (IX or IXP) is a layer 1 and layer 2 network structure that interconnects three or more Autonomous Systems (AS) for the purpose of Internet traffic interchange.

62 Leave a comment on paragraph 62 0 2.7. Usage rate

63 Leave a comment on paragraph 63 0 Usage rate is the rate at which the LIR made delegations from relevant past address space, including Historical delegations.

64 Leave a comment on paragraph 64 0 2.8. Utilization

65 Leave a comment on paragraph 65 0 Utilization is a measure of IPv6 address usage where “utilization” is only measured in terms of the bits to the left of the /56 boundary. In other words, utilization refers to the delegation of /56s to end sites, and not the number of addresses assigned within individual /56s at those end sites.

66 Leave a comment on paragraph 66 0 2.8.1. HD-Ratio

67 Leave a comment on paragraph 67 0 The HD-Ratio is a way of measuring the efficiency of address assignment [RFC3194]. 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)

71 Leave a comment on paragraph 71 0 where (in the case of this document) the objects are IPv6 site addresses (/56s) assigned from an IPv6 prefix of a given size.

72 Leave a comment on paragraph 72 0 2.9. End site

73 Leave a comment on paragraph 73 0 An end site is defined as an end-user (subscriber) who has a business relationship with a service provider that involves:

  • 74 Leave a comment on paragraph 74 0
  • 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

75 Leave a comment on paragraph 75 0 2.10. aut-num object

76 Leave a comment on paragraph 76 0 An aut-num object is an object in the Whois database used to register ASN assignment details. For the purposes of this document, aut-num object also refers to the ASN registration objects in NIR databases.

77 Leave a comment on paragraph 77 0 2.11. Routing policy

78 Leave a comment on paragraph 78 0 The routing policy of an AS is a description of how network prefixes are exchanged between that AS and other Autonomous Systems.

79 Leave a comment on paragraph 79 0 2.12. Transfers

80 Leave a comment on paragraph 80 0 Resource transfers involve the re-allocation of current address blocks (or ASNs), or the re-allocation of historical resources claimed and transferred to an APNIC account.

81 Leave a comment on paragraph 81 0 2.12.1. Counterpart RIR

82 Leave a comment on paragraph 82 0 A counterpart RIR is the Regional Internet Registry that APNIC transfers resources to, or from, in an inter-RIR transfer.

83 Leave a comment on paragraph 83 0 2.12.2. Source

84 Leave a comment on paragraph 84 0 The source in a resource transfer is the organization which, prior to the transfer, is the legitimate holder of the resources to be transferred. Where the source is in the APNIC region, the source must be a current APNIC account holder, except in the case of an Historical resource transfer. Where the source is from another RIR region, it must be that RIR’s equivalent to the “Source” as defined here.

85 Leave a comment on paragraph 85 0 2.12.3. Recipient

86 Leave a comment on paragraph 86 0 The recipient in a resource transfer is the organization which, after the transfer is completed, will be the legitimate holder of the resources to be transferred. Where the recipient is in the APNIC region, the recipient must be a current APNIC account holder. Where the recipient is from another RIR region, it must be that RIR’s equivalent to the “Recipient” as defined here.

87 Leave a comment on paragraph 87 0  

88 Leave a comment on paragraph 88 0 3.0. Policy framework

89 Leave a comment on paragraph 89 0 IP address space and other number resources, are public resources which must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible management involves balancing a set of sometimes competing goals. The following are the goals relevant to Internet number policy.

90 Leave a comment on paragraph 90 0 3.1. Goals of resource management

91 Leave a comment on paragraph 91 0 The goals described here were formulated by the Internet community and reflect the mutual interest of all members of that community in ensuring that the Internet is able to function and grow to the maximum extent possible.

92 Leave a comment on paragraph 92 0 It is APNIC’s primary duty, as a custodian of a public resource, to ensure these goals are met within the Asia Pacific region. APNIC does this by providing guidance and leadership in developing and implementing responsible policies and practices.

93 Leave a comment on paragraph 93 0 It is the responsibility of every NIR and LIR to also ensure these goals are met within their respective regions and communities.

94 Leave a comment on paragraph 94 0 3.1.1. Uniqueness

95 Leave a comment on paragraph 95 0 Every assignment and allocation of address space must be guaranteed as globally unique. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

96 Leave a comment on paragraph 96 0 3.1.2. Registration

97 Leave a comment on paragraph 97 0 All assignments and allocations made directly by APNIC to its Members and customers must be registered in a publicly accessible database. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to end-users.

98 Leave a comment on paragraph 98 0 It also reflects the expectation of the Internet community that custodians of these public resources should be identifiable. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available.

99 Leave a comment on paragraph 99 0 If the organization does not indicate a choice, or it chooses to hide its customer assignment registrations, then those records will not be visible in the public whois database. Whois queries on these records will return details of the allocation.

100 Leave a comment on paragraph 100 0 3.1.3. Aggregation

101 Leave a comment on paragraph 101 0 Address policies should seek to avoid fragmentation of address ranges.

102 Leave a comment on paragraph 102 0 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 network operators, and to limit the expansion of Internet routing tables.

103 Leave a comment on paragraph 103 0 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.

104 Leave a comment on paragraph 104 0 It is a condition of all delegations made under initial or subsequent LIR delegation criteria, that the address space is aggregated by the LIR within a minimum number of route announcements (preferably one).

105 Leave a comment on paragraph 105 0 LIRs must only delegate addresses to customers who will be using those addresses in relation to network connectivity services provided by the LIR.

106 Leave a comment on paragraph 106 0 LIRs are expected to enter into agreements with their customers specifying that the end-user will hold the addresses only for so long as the end-user remains a customer of that LIR. Such agreements should also be consistent with the license under which the address space is being used by the LIR.

107 Leave a comment on paragraph 107 0 3.1.4. No guarantee of contiguous delegations

108 Leave a comment on paragraph 108 0 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.

109 Leave a comment on paragraph 109 0 APNIC will attempt to make any subsequent delegations contiguous with previous delegations, but cannot guarantee that this will be possible.

110 Leave a comment on paragraph 110 0 3.1.5. Conservation

111 Leave a comment on paragraph 111 0 To maximize the lifetime of the available resource, address space must be distributed according to actual need and for immediate use. Stockpiling address space and maintaining reservations are contrary to this goal. Conservation also implies efficiency. Therefore, all users of address space should adopt techniques such as Variable Length Subnet Masking (VLSM) and appropriate technologies that ensure the address space is not used wastefully.

112 Leave a comment on paragraph 112 0 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 IPv6 addresses should also be avoided.

113 Leave a comment on paragraph 113 0 3.1.6. Fairness

114 Leave a comment on paragraph 114 0 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.

115 Leave a comment on paragraph 115 0 3.1.7. Minimized Overhead

116 Leave a comment on paragraph 116 0 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. There is overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.

117 Leave a comment on paragraph 117 0 3.1.8. Conflict of goals

118 Leave a comment on paragraph 118 0 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 address space must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.

119 Leave a comment on paragraph 119 0 This document is intended to help IRs perform their role in consistent and equitable ways. IRs must maintain full documentation of and transparency within the decision-making process.

120 Leave a comment on paragraph 120 0 In IPv6 address policy, the goal of aggregation is considered to be the most important.

121 Leave a comment on paragraph 121 0 3.2. Policy Environment

122 Leave a comment on paragraph 122 0 Apart from the goals described above, other factors influence the APNIC policy environment. These other factors include the expectations of the Internet community, current administrative structures, and technological constraints.

123 Leave a comment on paragraph 123 0 The policy environment may change quickly or in unpredictable ways, so APNIC, on behalf of its Members, must monitor any changes and communicate any policy implications.

124 Leave a comment on paragraph 124 0 This section describes the factors in the current operating environment that have been most important in determining current APNIC policies.

125 Leave a comment on paragraph 125 0 3.2.1. Routability

126 Leave a comment on paragraph 126 0 There is no guarantee that any address allocation or assignment will be globally routable.

127 Leave a comment on paragraph 127 0 The routability of address space throughout the Internet can never be guaranteed by any single organization. However, IRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.

128 Leave a comment on paragraph 128 0 To reduce the number of globally advertised routes, network operators may implement route filtering policies based on prefix length. As a result, small portable assignments are the most likely to suffer routability problems. Therefore, APNIC policies

129 Leave a comment on paragraph 129 0 encourage those seeking address space to request from upstream providers rather than from APNIC directly.

130 Leave a comment on paragraph 130 0 The responsible management of ASNs is also necessary to help limit the expansion of global routing tables. Aggregating contiguous IP address prefixes within single Autonomous Systems helps to minimize the number of routes announced to the global Internet.

131 Leave a comment on paragraph 131 0 3.2.2. Internet growth rates

132 Leave a comment on paragraph 132 0 Early strategies for distributing address space did not anticipate the rapid growth of the Internet and the scaling problems that followed, affecting both the amount of address space available and routing. Therefore, APNIC policies take account of past experience and seek to manage address space in a way that will maximize future scaling of the Internet.

133 Leave a comment on paragraph 133 0 3.2.3. Collective responsibility

134 Leave a comment on paragraph 134 0 APNIC shares with its Members and their customers a collective responsibility to ensure manageable and scalable Internet growth and to make decisions consistent with the goals described here. Therefore, APNIC policies and procedures are developed by APNIC Members and the broader Internet community as a whole, in the common interest of those communities.

135 Leave a comment on paragraph 135 0 In implementing policies, APNIC and its Members rely on an implicit trust that delegated responsibilities are carried out in good faith. Specifically, APNIC must trust that the information gathered from Members during the request process is genuine and accurate.

136 Leave a comment on paragraph 136 0 3.2.4. Impartiality

137 Leave a comment on paragraph 137 0 APNIC represents the interests of the Internet community in general and the Internet community of the Asia Pacific region in particular. Therefore, APNIC must apply its policies fairly and equitably, without regard to an organization’s size, geographic location, or any other factor.

138 Leave a comment on paragraph 138 0 3.2.5. Varying levels of expertise

139 Leave a comment on paragraph 139 0 Different IRs and end-users have varying levels of experience and expertise. APNIC policies allow for varying levels of assistance and monitoring, appropriate to ensure a consistent approach to address space management throughout the Asia Pacific Internet community.

140 Leave a comment on paragraph 140 0 3.2.6. Address ownership

141 Leave a comment on paragraph 141 0 The Internet community regards address space as a scarce, public resource that should only be distributed according to demonstrated need. ISPs and other organizations and individuals that use address space are considered “custodians” rather than “owners” of the resource. As address space becomes more scarce, address space management policies may be adjusted by the community.

142 Leave a comment on paragraph 142 0 3.2.7. Address stockpiling

143 Leave a comment on paragraph 143 0 Stockpiling addresses is harmful to the goals of conservation and fairness. APNIC policies must prevent stockpiling and ensure efficient deployment of address space on the basis of immediate demonstrated need.

144 Leave a comment on paragraph 144 0 3.2.8. Reservations not supported

145 Leave a comment on paragraph 145 0 When an LIR wants to delegate address space for customers, it must use any address space it currently holds.

146 Leave a comment on paragraph 146 0 When evaluating address requests, reserved address space is not considered to be delegated.

147 Leave a comment on paragraph 147 0 3.2.9. Evaluations to be based on best practice

148 Leave a comment on paragraph 148 0 APNIC should ensure that address space holders adopt current best practice in the management of the resources they use. If appropriate technologies exist for improved management of address space in particular situations, the community expects that those technologies should be used. APNIC consults with its Members and the broader Internet community to define and develop current best practice recommendations relating to Internet addressing technologies and techniques.

149 Leave a comment on paragraph 149 0 3.2.10. Minimum practical delegation

150 Leave a comment on paragraph 150 0 Because the goals of aggregation and conservation conflict, it is necessary to apply a minimum practical size for address space delegation. This minimum size may be reviewed from time to time, as technologies and administrative conditions evolve.

151 Leave a comment on paragraph 151 0 3.2.11. Slow start mechanism

152 Leave a comment on paragraph 152 0 APNIC and NIRs apply a slow start mechanism to all new LIRs. The slow start is applied to prevent delegations of large blocks of address space that may then remain substantially unused.

153 Leave a comment on paragraph 153 0 3.2.11.1. Exceptions to slow start

154 Leave a comment on paragraph 154 0 In exceptional circumstances, an LIR may receive a greater initial delegation if it can demonstrate that its immediate need for address space exceeds the standard slow start delegation.

155 Leave a comment on paragraph 155 0 The documentation required to justify an exception to the slow start may include (but is not limited to):

  • 156 Leave a comment on paragraph 156 0
  • Receipts for the purchase of equipment, Purchase Orders, or
  • Signed project contracts indicating the immediate network requirements to be met by the LIR.

157 Leave a comment on paragraph 157 0 3.3. Organizations seeking address space from multiple IRs

158 Leave a comment on paragraph 158 0 Organizations must obtain their address space from only one IR at a time. Organizations requesting address space from any IR must declare all the address space they currently hold, regardless of the source. Organizations making concurrent requests to more than one IR must declare the details of all of those requests.

159 Leave a comment on paragraph 159 0 In certain circumstances (for example, where an organization is multihomed), strong technical reasons may justify an organization receiving address space from more than one source.

160 Leave a comment on paragraph 160 0 For the purposes of this section, a parent organization and its subsidiaries are considered to be a single organization. Exceptions may arise in cases where the parts of the organization:

  • 161 Leave a comment on paragraph 161 0
  • Are separate legal entities,
  • Maintain fully independent network infrastructures and are routed under different ASNs, or
  • Can otherwise demonstrate a justified need to obtain address space from more than one IR.

162 Leave a comment on paragraph 162 0  

163 Leave a comment on paragraph 163 0 4.0. Resource License

164 Leave a comment on paragraph 164 0 It is contrary to the goals of this document and is not in the interests of the Internet community as a whole, for Internet number resources to be considered freehold property.

165 Leave a comment on paragraph 165 0 Neither delegation nor registration confers ownership of resources. Organizations that use them are considered “custodians” rather than “owners” of the resource, and are not entitled to sell or otherwise transfer that resource to other parties outside the provisions in this document.

166 Leave a comment on paragraph 166 0 Internet resources are regarded as public resources that should only be distributed according to demonstrated need.

167 Leave a comment on paragraph 167 0 The policies in this document are based upon the understanding that globally-unique unicast address space is licensed for use rather than owned.

168 Leave a comment on paragraph 168 0 4.1. License Renewal

169 Leave a comment on paragraph 169 0 Specifically, APNIC will delegate Internet resources on a ‘license’ basis, with licenses subject to renewal on a periodic basis (normally one year).

170 Leave a comment on paragraph 170 0 The granting of a license is subject to specific conditions as described in the APNIC membership agreements, service agreements, and other relevant APNIC documents, at the start or renewal of the license.

171 Leave a comment on paragraph 171 0 IRs 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.

172 Leave a comment on paragraph 172 0 Licenses to organizations shall be renewable on the following conditions:

174 Leave a comment on paragraph 174 0 4.1.1. Review

175 Leave a comment on paragraph 175 0 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, IRs reserve the right to not renew the license. However, individual licenses shall only be subject to review if the relevant IR has reason to believe that the existing license terms are no longer being complied with. IRs may implement their own procedures for the review of existing licenses as they see fit.

176 Leave a comment on paragraph 176 0 When a license is renewed, the new license will be evaluated and governed subject to all policies and license conditions effective at the time of renewal.

177 Leave a comment on paragraph 177 0 These may differ from those in place at the time of the original delegation, provided that a minimum notice period of one year is given of any substantial changes. Substantial changes to license conditions are subject to the consensus of APNIC Members, in accordance with the APNIC Document Editorial Policy.

178 Leave a comment on paragraph 178 0 4.1.2. Validity of delegations

179 Leave a comment on paragraph 179 0 A resource delegation is valid only while the original criteria on which it was made remains valid. If a delegation becomes invalid then the resource must be returned to the appropriate IR.

180 Leave a comment on paragraph 180 0 An allocation or assignment becomes invalid if it is:

182 Leave a comment on paragraph 182 0 4.2. Closure and recovery

183 Leave a comment on paragraph 183 0 If an LIR holding APNIC address space ceases to provide Internet connectivity services, all of its address space must be returned to APNIC. It is the responsibility of the LIR (or any liquidator or administrator appointed to wind up the Member’s business) to advise all of its customers that address space will be returned to APNIC, and that renumbering into new address space will be necessary.

184 Leave a comment on paragraph 184 0 In the case that a new LIR takes over the business or infrastructure of the closed LIR, the existing address space may be transferred to the new LIR, however such a transfer is subject to re-examination by APNIC and may be treated as a new address request process.

185 Leave a comment on paragraph 185 0 4.2.1. Recovery of unused historical resources

186 Leave a comment on paragraph 186 0 A significant amount of historical resources registered in the APNIC Whois Database are not announced to the global routing table.

187 Leave a comment on paragraph 187 0 To recover these globally un-routed resources and place them back in the free pool for re-delegation, APNIC will contact networks responsible for historical address space in the APNIC region that has not been globally routed since 1 January 1998. To recover un-routed historical AS numbers, APNIC will contact networks responsible for resources not globally used for a reasonable period of time.

188 Leave a comment on paragraph 188 0  

189 Leave a comment on paragraph 189 0 5.0. Resource Management

190 Leave a comment on paragraph 190 0 All NIRs and LIRs that receive address space from APNIC (either directly or indirectly) must adopt delegation policies that are consistent with the policies described in this document.

191 Leave a comment on paragraph 191 0 NIRs and LIRs must ensure that address space for which they are responsible is only allocated or assigned subject to agreements consistent with the license provisions in this document. Also, NIRs must, wherever possible, apply slow start, assignment window, and second opinion policies to their own members in a manner consistent with the way APNIC applies such policies.

192 Leave a comment on paragraph 192 0 5.1. How APNIC manages address space

193 Leave a comment on paragraph 193 0 5.1.1. Reservation for future uses

194 Leave a comment on paragraph 194 0 A /16 of IPv4 address space will be held in reserve for future uses, as yet unforeseen.

195 Leave a comment on paragraph 195 0 If the reserved /16 remains unused by the time the remaining available space has been delegated, the /16 will be returned to the APNIC pool for distribution under the policies described in this document.

196 Leave a comment on paragraph 196 0 5.1.2. Sparse allocation framework

197 Leave a comment on paragraph 197 0 APNIC will document the sparse allocation algorithm framework used to select IPv6 address blocks for delegation, in document apnic-114: APNIC guidelines for IPv6 allocation and assignment requests. This document is available at the following URL: http://www.apnic.net/ipv6-guidelines

198 Leave a comment on paragraph 198 0 5.1.3. IPv4 addresses returned to APNIC

199 Leave a comment on paragraph 199 0 Any IPv4 resources received by APNIC will be placed into the APNIC IPv4 pool for delegation under the policies described in this document. This placement applies to any IPv4 addresses APNIC receives from IANA and/or holders of addresses in the APNIC Whois Database, subject to any future global policy for the redistribution of addresses received by IANA from the RIRs.

200 Leave a comment on paragraph 200 0 5.1.4. Preventing the Use of Undelegated APNIC Address Space

201 Leave a comment on paragraph 201 0 Undelegated APNIC Address Space (IPv4 or IPv6) should not be publicly advertised by any Autonomous System. To prevent its use, APNIC will create RPKI ROAs with origin AS0 (AS zero) for all undelegated address space (marked as “Available” and “Reserved” in the delegated-apnic-extended-latest stats file) for which it is the current administrator.

202 Leave a comment on paragraph 202 0 While any current resource holder can create AS0 ROA for the resources they have under their account administration, only APNIC has the authority to create AS0 ROAs for APNIC address space not yet delegated to an organization. When APNIC delegates address space to an organization, APNIC will remove the prefix from the AS0 ROA.

203 Leave a comment on paragraph 203 0 5.2. LIR address space management

204 Leave a comment on paragraph 204 0 LIRs may delegate address space to their customers subject to the following provisions.

205 Leave a comment on paragraph 205 0 5.2.1. Assignment window for LIRs

206 Leave a comment on paragraph 206 0 APNIC and NIRs shall apply an assignment window mechanism to help LIRs understand and comply with APNIC policies and the address management goals.

207 Leave a comment on paragraph 207 0 The assignment window indicates the maximum number of addresses an LIR may delegate to an end-user without first seeking a “second opinion”. If an LIR wishes to make a delegation that exceeds its delegation window, the LIR must first submit a second opinion request.

208 Leave a comment on paragraph 208 0 LIRs start with a delegation window of zero, meaning all proposed delegations must first be approved.

209 Leave a comment on paragraph 209 0 APNIC, or the relevant NIR, will regularly assess the proficiency of LIR staff in making delegations and seeking second opinions and will review the size of the assignment window accordingly. As the LIR staff become more proficient, the size of their assignment window may be raised.

210 Leave a comment on paragraph 210 0 The maximum IPv4 assignment window given to any LIR will be a /19 (8,192 addresses).

211 Leave a comment on paragraph 211 0 If an LIR’s staff appears to become less proficient (for example, due to the training of new staff or other relevant circumstances) then that LIR’s assignment window may be temporarily reduced.

212 Leave a comment on paragraph 212 0 5.2.2. IPv4 address usage estimates

213 Leave a comment on paragraph 213 0 Requests for delegations must be supported by usage estimates based on immediate and projected future need. These requests must be accompanied by documentation that supports the estimates.

214 Leave a comment on paragraph 214 0 The estimates should be made for the following periods:

216 Leave a comment on paragraph 216 0 APNIC recommends that, as a general guideline, organizations should base their resource requests on the assumption that 25% of the address space will be used immediately and 50% will be used within one year.

217 Leave a comment on paragraph 217 0 The end-user must provide documentation that supports its one-year usage estimate. If it is not possible for the end-user to estimate confidently what the two-year usage rate will be, then APNIC or the NIR may make a delegation that will be sufficient for the one-year needs only.

218 Leave a comment on paragraph 218 0 5.2.3. IPv4 Delegations to downstream IRs

219 Leave a comment on paragraph 219 0 LIRs may delegate address space to their downstream customers, which are operating networks, such as ISPs, subject to the following conditions:

  • 220 Leave a comment on paragraph 220 0
  • Delegations are non-portable and must be returned to the LIR if the downstream customer ceases to receive connectivity from the LIR.
  • Delegations are subject to the LIR’s assignment window. Requests for delegations, which exceed the LIR’s assignment window, must first be referred to APNIC for second opinion approval.
  • The downstream customer is not permitted to further allocate the address space.

221 Leave a comment on paragraph 221 0 5.2.3.1. Effect of delegation to downstream IRs on upstream LIR’s usage rate

222 Leave a comment on paragraph 222 0 For the purposes of evaluating the LIR’s usage rate, address space delegated to downstream LIRs will be considered as “used”. However, APNIC will give careful consideration to the registration of delegations made by the downstream LIR to their customers and may request supporting documentation as necessary.

223 Leave a comment on paragraph 223 0 5.2.4. Policies for LIR IPv6 allocation and assignment

224 Leave a comment on paragraph 224 0 5.2.4.1. LIR-to-ISP allocation

225 Leave a comment on paragraph 225 0 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.

226 Leave a comment on paragraph 226 0 5.2.4.2. Assignment address space size

227 Leave a comment on paragraph 227 0 LIRs must make IPv6 assignments in accordance with the following provisions.

228 Leave a comment on paragraph 228 0 End-users are assigned an end site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of “n” x /64.

229 Leave a comment on paragraph 229 0 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 do in IPv4, except for the cases described in Section 9.2.1 and for the purposes of measuring utilization as defined in this document.

230 Leave a comment on paragraph 230 0 5.2.4.3. Assignment of multiple /48s to a single end site

231 Leave a comment on paragraph 231 0 Assignment larger than /48 (shorter prefix) or additional assignments exceeding a total of /48 must be made based on address usage, or because of different routing requirements exist for additional assignments.

232 Leave a comment on paragraph 232 0 In case of a review or when making a request for a subsequent allocation, the LIR must be able to present documentation justifying the need for assignments shorter than a /48 to a single end site.

233 Leave a comment on paragraph 233 0 5.3. Registration requirements

234 Leave a comment on paragraph 234 0 5.3.1. Requirements for IPv4 addresses

235 Leave a comment on paragraph 235 0 IRs are responsible for promptly and accurately registering their address space use with APNIC as follows:

  • 236 Leave a comment on paragraph 236 0
  • All delegations from APNIC to the IR must be registered.
  • All delegations to downstream IRs must be registered.
  • Delegations made to networks greater than a /30 must be registered.
  • Delegations made to networks of a /30 or less may be registered, at the discretion of the IR and the network administrator.
  • Delegations to hosts may be registered, at the discretion of the IR and the end-user.

237 Leave a comment on paragraph 237 0 IRs can choose whether or not to designate this information “public”. Customer registration details that are not designated “public” will not be generally available via the APNIC Whois Database. The database record will instead direct specific whois enquiries to the IR concerned.

238 Leave a comment on paragraph 238 0 5.3.1.1. Updating registration details

239 Leave a comment on paragraph 239 0 IRs must update their registration records when any of the registration information changes. This is the responsibility of the IR concerned. However, this responsibility may be formally assigned to the end-user as a condition of the original delegation.

240 Leave a comment on paragraph 240 0 5.3.2. Registration requirements for IPv6 addresses

241 Leave a comment on paragraph 241 0 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).

242 Leave a comment on paragraph 242 0 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.

243 Leave a comment on paragraph 243 0 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.

244 Leave a comment on paragraph 244 0 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.

245 Leave a comment on paragraph 245 0 Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization does not indicate a choice, or it chooses to hide its customer assignment registrations, then those records will not be visible in the public whois database. Whois queries on these records will return details of the allocation.

246 Leave a comment on paragraph 246 0 5.3.3. Registration requirements for AS Numbers

247 Leave a comment on paragraph 247 0 All ASNs assigned must be publicly registered in the APNIC, or relevant NIR, Whois database. APNIC, or the relevant NIR, will create the aut-num object.

248 Leave a comment on paragraph 248 0 All attributes of the aut-num object must be properly registered in accordance with the APNIC or NIR whois database documentation. Without limiting these general requirements, Section 5.3.3.1 and Section 5.3.3.2. describe particular requirements for ASN registration.

249 Leave a comment on paragraph 249 0 5.3.3.1. Registering routing policy

250 Leave a comment on paragraph 250 0 APNIC recommends that the routing policy of the AS is registered for each ASN assigned.

251 Leave a comment on paragraph 251 0 5.3.3.2. Updating registration details

252 Leave a comment on paragraph 252 0 Organizations responsible for ASNs should update the aut-num object in the appropriate database if any of the registration information changes.

253 Leave a comment on paragraph 253 0 5.3.4. Registering Contact Persons

254 Leave a comment on paragraph 254 0 Administrative and technical contact persons must be registered.

255 Leave a comment on paragraph 255 0 The registered administrative contact (“admin-c”) must be someone who is physically located at the site of the network, subject to the following exceptions:

  • 256 Leave a comment on paragraph 256 0
  • For residential networks or users, the IR’s technical contact may be registered as the admin-c.
  • For networks in exceptional circumstances that make it impractical to maintain an on-site administrative contact, an off-site person may be registered as the admin-c. The technical contact (“tech-c”) need not be physically located at the site of the network, but must be a person who is responsible for the day-to-day operation of the network.

257 Leave a comment on paragraph 257 0 In addition, it is mandatory to register an Incident Response Team (IRT) object for each resource record in the APNIC Whois Database. Contact addresses listed in the IRT object (email, abuse-mailbox attributes) be regularly monitored and any abuse complaints sent to these contacts must be responded to promptly to resolve the complaints.

258 Leave a comment on paragraph 258 0 APNIC will validate IRT contacts periodically or every six (6) months to ensure they are accurate and contactable. Members are required to complete these validation checks within fifteen (15) days of receiving the validation check email from APNIC. If the IRT contacts fail the validation, APNIC will mark the IRT object invalid in the APNIC Whois Database and follow up according to relevant policies and procedures. If validation still fails after thirty (30) days, the Member will have limited access to MyAPNIC until their IRT contacts are validated.

259 Leave a comment on paragraph 259 0 5.4. Reverse lookup

260 Leave a comment on paragraph 260 0 5.4.1. Responsibility to maintain IPv4 in-addr.arpa records

261 Leave a comment on paragraph 261 0 LIRs should maintain in-addr.arpa resource records for their customers’ networks. If a network is not specifically associated with an LIR then the in-addra.arpa records should be maintained by either the appropriate NIR or APNIC.

262 Leave a comment on paragraph 262 0 5.4.2. IPv6 reverse lookup

263 Leave a comment on paragraph 263 0 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.

264 Leave a comment on paragraph 264 0 5.5. Managing Historical resources

265 Leave a comment on paragraph 265 0 Historical resources were often delegated to organizations in a policy environment quite different to those in use today. Historical resource holders should be aware of the current goals of Internet resource management as outlined in this document.

266 Leave a comment on paragraph 266 0 The following policies specifically apply to Historical resources.

267 Leave a comment on paragraph 267 0 5.5.1. Utilization of Historical IPv4 address space

268 Leave a comment on paragraph 268 0 Utilization of Historical IPv4 address space is taken into account when any organization holding Historical IPv4 addresses requests more IPv4 from APNIC.

269 Leave a comment on paragraph 269 0 5.5.2. Protecting Historical records in the APNIC Whois Database

270 Leave a comment on paragraph 270 0 APNIC will protect all registrations of Historical Internet resources with the APNIC-HM maintainer, a practice consistent with the management of current resources.

271 Leave a comment on paragraph 271 0 To ensure integrity of information, APNIC will not update historical information in the APNIC Whois Database until the resource holder demonstrates the organization’s right to the resources and enters a formal agreement with APNIC either as a Member or Non-Member account holder.

272 Leave a comment on paragraph 272 0 5.5.3. Updating Historical registrations

273 Leave a comment on paragraph 273 0 Detailed information on how to request an update to a historical Internet resource registration is available on the historical resource page of the APNIC website.

274 Leave a comment on paragraph 274 0 http://www.apnic.net/services/manage-historical-resources

275 Leave a comment on paragraph 275 0 Please note that resource holders will not be able to update registration information if they fail to pay the fees associated with their APNIC Member or Non-Member account.

276 Leave a comment on paragraph 276 0 Historical resource holders with a current APNIC account have access to MyAPNIC, which allows organizations to manage their resources and account information via a secure website.

277 Leave a comment on paragraph 277 0 5.5.4. Policies applicable to updated Historical resources

278 Leave a comment on paragraph 278 0 Historical Internet resources that are updated under this policy are subject to the registration requirements as specified above.

279 Leave a comment on paragraph 279 0 5.6. General requirements for requests

  • 280 Leave a comment on paragraph 280 0
  • All requests for address space must be supported by documentation describing:
  • The network infrastructure of the organization making the request,
  • Any address space currently held by that organization (including Historical address space),
  • Previous assignments made by that organization (including assignments made from Historical address allocations), and
  • The intended use for the address space requested.

281 Leave a comment on paragraph 281 0 In addition to this general requirement, more specific documentation may also be requested, as outlined below.

282 Leave a comment on paragraph 282 0 5.6.1. Documentation

283 Leave a comment on paragraph 283 0 To properly evaluate requests, IRs must carefully examine all relevant documentation relating to the networks in question. This documentation may include:

  • 284 Leave a comment on paragraph 284 0
  • Network engineering plans
  • Subnetting plans
  • Descriptions of network topology
  • Descriptions of network routing plans
  • Equipment invoices and purchase orders
  • Other relevant documents

285 Leave a comment on paragraph 285 0 All documentation should conform to a consistent standard and any estimates and predictions that are documented must be realistic and justifiable.

286 Leave a comment on paragraph 286 0 5.6.2. Security and confidentiality

287 Leave a comment on paragraph 287 0 The documentation, which supports address space requests, involves information that may be highly confidential to the commercial and infrastructure operations of all Members and their customers.

288 Leave a comment on paragraph 288 0 Therefore, APNIC will reflect the trust implicit in its position by:

  • 289 Leave a comment on paragraph 289 0
  • applying and enforcing systems, practices, and procedures that protect the confidential information of its Members and their customers, and
  • ensuring the employment of all staff, or agents, is based upon an explicit condition of confidentiality regarding such information.

290 Leave a comment on paragraph 290 0 APNIC provides for authorization and verification mechanisms within the APNIC Whois Database. It is the responsibility of each IR, or end-user, to apply these mechanisms.

291 Leave a comment on paragraph 291 0 5.6.3. Equitable processing of requests

292 Leave a comment on paragraph 292 0 APNIC will only process requests that have been completely and properly documented. If the documentation contains errors or omissions, APNIC will advise the applicant as soon as possible.

293 Leave a comment on paragraph 293 0 APNIC may also request the applicant to provide further information, or clarify relevant issues that are not clear in the initial request.

294 Leave a comment on paragraph 294 0 Once the errors and omissions are rectified, or the additional questions answered, APNIC will deal with the request in the strict order in which it receives proper documentation.

295 Leave a comment on paragraph 295 0 APNIC will make all reasonable efforts to maintain a consistent and reliable level of service with respect to processing of requests and will maintain a request tracking system for efficient request management.

296 Leave a comment on paragraph 296 0 To provide fair treatment for all applicants, APNIC will not, under any circumstance, provide any special treatment or make exceptions to the standard order of request processing.

297 Leave a comment on paragraph 297 0 5.7. Experimental allocations policy

298 Leave a comment on paragraph 298 0 This Section describes the APNIC policies which apply to requests for Internet resource allocations that are to be used for experimental purposes.

299 Leave a comment on paragraph 299 0 5.7.1. Introduction

300 Leave a comment on paragraph 300 0 As the Internet continues to expand and evolve, there is an increased need for technologies and practices to be refined and standardized.

301 Leave a comment on paragraph 301 0 To achieve this, it is often necessary to experiment with proposed technologies to evaluate their interaction with the installed base of the Internet. For a small proportion of these experimental activities, it may be necessary to allocate or assign Internet resources on a temporary basis.

302 Leave a comment on paragraph 302 0 5.7.1.1. Scope and goal

303 Leave a comment on paragraph 303 0 This section describes policies for the responsible management of global Internet resources in the Asia Pacific region, specifically relating to the temporary allocation and assignment of Internet resources for experimental purposes.

304 Leave a comment on paragraph 304 0 The goal of this policy is to provide fair access to Internet resources for genuine researchers, to encourage development of new technologies and refinement of standards.

305 Leave a comment on paragraph 305 0 5.7.2. Allocations for experimental purposes

306 Leave a comment on paragraph 306 0 APNIC will allocate public Internet resources to be used for experimental purposes. These experimental allocations are subject to the eligibility criteria, conditions, and restrictions described below. An experiment is eligible for an allocation if it meets the criteria described in either 5.7.2.1 or Section 5.7.2.2 below.

307 Leave a comment on paragraph 307 0 5.7.2.1. Publication of an experimental RFC

308 Leave a comment on paragraph 308 0 Experiments are eligible for allocations if they are described in an RFC designated by the IETF as “Experimental”. The requestors must specifically refer to this RFC, describe their participation in the experiment, and provide a summary of the experiment which details their requirement for Internet resources.

309 Leave a comment on paragraph 309 0 5.7.2.2. Alternative publication approved by APNIC

310 Leave a comment on paragraph 310 0 Experiments may be eligible for an allocation if they are described in a document that is available free of charge and publicly accessible in a forum approved by APNIC.

311 Leave a comment on paragraph 311 0 Under this criterion, APNIC has the sole discretion to determine whether such an experiment is eligible. To do so, APNIC may liaise with IETF working groups, other standards bodies, RIRs, or Internet experts to evaluate the status of the document, the validity of the experiment it describes, and the Internet resource requirements of the experiment.

312 Leave a comment on paragraph 312 0 The requestors must specifically refer to the published document, describe their participation in the experiment, and provide a summary of the experiment which details their requirement for Internet resources.

313 Leave a comment on paragraph 313 0 5.7.3. Experimental allocations

314 Leave a comment on paragraph 314 0 5.7.3.1. Public disclosure of experiment

315 Leave a comment on paragraph 315 0 It is a condition for experimental allocations that all material details of the experiments are published free of charge and without any constraints on their disclosure or use. The details to be published include the objectives of the experiment, the practices, and any other relevant details. At the completion of the experiment, the results must be published under the same terms.

316 Leave a comment on paragraph 316 0 To this extent, the terms of APNIC’s regular non-disclosure provisions are specifically excluded from these requests. Although APNIC may consider requests for certain aspects of a project to be subject to a non-disclosure agreement, it will not agree to any restrictions on the public benefit to be gained from any experiments.

317 Leave a comment on paragraph 317 0 APNIC may publish and maintain public archives of all experiments which receive allocations under this policy.

318 Leave a comment on paragraph 318 0 5.7.3.2. Size of IP allocations

319 Leave a comment on paragraph 319 0 In the case of experimental allocations of IP addresses, the allocation size will be consistent with APNIC’s standard minimum allocation size, unless the nature of the experiment specifically requires an allocation of a different size.

320 Leave a comment on paragraph 320 0 5.7.3.3. APNIC input on proposed experiment

321 Leave a comment on paragraph 321 0 During the request process, APNIC may comment on the objectives of the experiment with regards to the requested amount of numbering resources. APNIC may also propose changes to the size of the requested allocation.

322 Leave a comment on paragraph 322 0 If the requestor does not agree with the proposed changes, then APNIC will seek advice from the IETF or another relevant standards body involved in publishing the experiment.

323 Leave a comment on paragraph 323 0 5.7.3.4. Duration of allocation licenses

324 Leave a comment on paragraph 324 0 APNIC will make experimental allocations on a temporary license basis. Licenses to use the resources will be valid for one year.

325 Leave a comment on paragraph 325 0 5.7.3.5. Extension of license

326 Leave a comment on paragraph 326 0 At the end of the initial license period, the holder of the resources may apply to have the license extended, to meet the objectives of the experiment, as publicly documented.

327 Leave a comment on paragraph 327 0 It is intended that the majority of the experiments to be considered under this policy will be concluded without extension of the original license.

328 Leave a comment on paragraph 328 0 5.7.4. Registration

329 Leave a comment on paragraph 329 0 All experimental allocations will be registered in the APNIC Whois Database. The registration details will indicate the temporary nature of these allocations.

330 Leave a comment on paragraph 330 0 5.7.4.1. Restriction on commercial or undocumented uses

331 Leave a comment on paragraph 331 0 APNIC may revoke an experimental allocation if the resources are being used for commercial purposes, or are being used for any activities not documented in the original request.

332 Leave a comment on paragraph 332 0 5.7.5. Fees for experimental allocations

333 Leave a comment on paragraph 333 0 Experimental allocations are available to APNIC Members only.

334 Leave a comment on paragraph 334 0 New Members wishing to receive experimental allocations may join at the Associate Member level. Their request for an experimental allocation will not be subject to the “IP resource application fee”.

Pages: 1 2 3 4 5 6
Page 4

Source: https://comment.apnic.net/?page_id=81&page=2