Please note that as of Friday, 15 April 2011, each APNIC account holder is only eligible to receive IPv4 address delegations totaling a maximum /22 from the APNIC 103/8 IPv4 address pool.
On Tuesday, 27 May 2014, each APNIC account holder became eligible to receive additional delegations up to a maximum of /22 address space from the APNIC non-103/8 IPv4 address pool.
Section 1: Background
These guidelines are developed within the APNIC community, and are consistent with the goals and policies applicable to IPv4 address space management. They are intended to assist organisations requesting IPv4 address space only.
Nothing in these guidelines should be considered to replace or modify any of the specific policies defined in other APNIC documents.
This document applies to the management of global IPv4 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 IPv6, Multicast, or Private Address Space, or Autonomous System numbers. It should be read in conjunction with other APNIC documents, particularly Policies for IPv4 address space management in the Asia Pacific region.
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 APNIC FAQs and other information on the APNIC web site.
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 IPv4 address space management in the Asia Pacific region, namely:
- conservation; and
5. Application of guidelines
This document is primarily intended to guide LIRs 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 allocations and second-opinion requests for assignments.
It is intended that NIRs will either adopt these or similar guidelines for their own members.
Section 2: General guidelines
6. Static and dynamic assignments
All assignments should be made in a manner that is consistent with the goal of address conservation and should take account of the nature of the connection for which the addresses are to be assigned.
6.1. Assignments for transient connections
For services that are intended to connect the Internet on a transient basis (for example, dial-up connections), best current practice is to use a pool of IP addresses for dynamic addressing as connections are made.
If an organisation plans to make static assignments to transient connections, then full technical justification will be required to support the request.
6.2. Assignments for permanent connections
For services that are intended to connect the Internet on a permanent basis (for example cable, leased line, or DSL services), organisations may make static assignments without the need to provide additional technical justification.
Many networks will use dynamic addressing even for permanent connections. This may also be done without the need to provide additional technical justification.
7. IP unnumbered
APNIC encourages the use of the IP unnumbered functionality as it helps conserve IPv4 address space.
IP unnumbered allows IP processing on a serial interface, without assigning an explicit IP address for point-to-point links. This applies to statically routed, single-homed customer connections. It does not apply where BGP is used over a link.
For more details, please refer to Using the IP unnumbered configuration FAQ.
8. Assignment of multiple IP addresses
In general, if an organization plans to assign more than one IP address per host, then it must provide full technical justification.
See also section 9 “Virtual web hosting”.
9. Virtual web hosting
Virtual web hosting refers to the process of running multiple “virtual” web servers on a single physical host computer. This is achieved by either name-based techniques (where a single IP address is assigned to a single server hosting many web sites), or IP-based techniques (where an IP address is assigned to each web site hosted on the server).
More general information about virtual web hosting is available in the Virtual web hosting FAQ.
9.1. Evaluating requests involving web hosting plans
APNIC strongly encourages the use of name-based web hosting.
If an organisation plans to use IP-based web hosting, then it must provide full technical justification (see section 9.2).
Additional information may also be required for subsequent requests for address space (see section 9.3).
9.2. Justification for IP-based web hosting
There are few technical limitations to name-based hosting. Therefore, if an organisation plans to deploy services that require IP-based hosting, then it must provide a description of those services.
The most common services that require IP-based hosting are:
- websites that use SSL (Secure Sockets Layer) for e-commerce services, particularly if a separate certificate is used for each virtual domain; and
- virtual FTP services with anonymous login functionality.
Although some early web browsers are not HTTP1.0 compliant, research has shown that the use of these browsers is no longer widespread. Therefore, lack of HTTP1.0 compliance is not considered sufficient justification for large scale IP-based hosting.
9.3. Special verification for subsequent requests
Organisations requesting a subsequent allocation will need to provide additional information if:
- the organisation or its downstream customers have made assignments for IP-based web hosting; and
- one or more of those assignments exceeds /22.
In these cases, the organisation will be required to provide a list of each IP address used and the corresponding URLs for each of those large assignments.
This information is used to verify the responsible use of address space for IP-based web hosting.
10. Cable and DSL services
10.1. Bootstrap criteria for first allocation to new cable or DSL services
Organisations requesting address space for use in new cable or DSL services may choose to have their request evaluated under simplified “bootstrapping” criteria:
- Under the bootstrapping criteria, the amount of address space allocated is based on an assumption of the requestor assigning a /24 to each CMTS in their network.
- A bootstrap request must be supported by a description of the equipment in the network plan field.
- The bootstrap criteria may be used by either startup providers and existing providers that are commencing new cable or DSL services.
- The choice of using the bootstrap criteria is entirely at the discretion of the requesting organisation.
If an organisation requests more addresses than are allowed under the bootstrapping criteria, then they must provide the full supporting documentation, in the network plan field of the request form. In particular they should include:
- details of equipment that is installed at each network location; and
- for each subnet, the number and type of devices and servers which require IP addresses.
10.2. Criteria for subsequent allocations to cable or DSL services
Organisations seeking subsequent allocations to cable and DSL services must provide the following information:
- headend information specifying the number of CMTS or B-RAS devices planned per headend;
- the projected number of subscribers within 3 months;
- growth rate based on average growth or IP utilisation per month over past three months (as an option, the ISP can supply documentation such as an MRTG or a RADIUS/DHCP server log to support growth rate evaluation);
- the number of subscribers, subscribed DSL/cable circuits, or IP addresses consumed by subscribers at peak time projected within 12 months (if the projection is significantly higher than that predicted by the growth rate, then an additional explanation will be required); and
- purchase receipts for equipment (if requested by APNIC or the NIR).
Furthermore, if greater than a /22 is used in a cable or xDSL network, then special verification may be required, consisting of detailed information from a headend chosen at random by APNIC or the NIR.
11. Private address space
RFC 1918 Address Allocation for Private Internets describes the use of ‘private address space’ for the operation of private IP networks. IANA has reserved the following three blocks of IPv4 address space for private networks:
- 10.0.0.0 – 10.255.255.255 (10/8)
- 172.16.0.0 – 172.31.255.255 (172.16/12)
- 192.168.0.0 – 192.168.255.255 (192.168/16)
Using private addresses helps to meet the conservation goal and provides more flexibility for the user when addressing the network. For this reason, users should always be informed that private addresses might be a viable option.
The use of private address space is strongly recommended for organisations that have no requirement for Internet connectivity.Organisations that do intend to use private addresses may do so without having to make a request to APNIC or their NIR.
12. Network Address Translation (NAT)
RFC 1631 describes Network Address Translation (NAT). NAT allows a single device, such as a router, to act as a mediator between the Internet and a local (or “private”) network. This means that a single, unique public IP address is required to represent a group of computers. Fewer public IP addresses are consumed thereby assisting the goal of conservation. However, despite this, many drawbacks have been cited with the use of NAT.
APNIC does not require organisations to use NAT. The choice of whether to use NAT is entirely up to the discretion of individual organisations.
13. Guidelines for GPRS requests
The use of address space in GPRS networks is subject to the same policies that apply for any other use.
Although APNIC has not made specific guidelines for GPRS requests, the GSM Association, after consulting the communities of the respective RIRs, has developed a set of recommendations for organisations requesting space for these purposes.
APNIC considers that these recommendations provide useful guidance for GPRS network operators.
A useful presentation summarising the recommendations is available from:
3G & GPRS Network Technical Architect, BT Cellnet, UK
Presented: APNIC Open Policy Meeting, 19-21 August 2001
IP Addressing Policy for GPRS Mobile Terminals (300.3 KB)
IP Address Management and Assignment Methods and Authorities
(Page 2 of 2)
The Original IP Address Authority: IANA
The Internet is of course the big IP internetwork, and requires this coordination task to be performed for millions of organizations worldwide. The job of managing IP address assignment on the Internet was originally carried out by a single organization: the Internet Assigned Number Authority (IANA). IANA was responsible for allocating IP addresses, along with other important centralized coordination functions such as managing universal parameters used for TCP/IP protocols. In the late 1990s, a new organization called the Internet Corporation for Assigned Names and Numbers (ICANN) was created. ICANN now oversees the IP address assignment task of IANA, as well as managing other tasks such as DNS name registration.
IP addresses were originally allocated directly to organizations. The original IP addressing scheme was based on classes, and so IANA would assign addresses in Class A, Class B and Class C blocks. Today, addressing is classless, using CIDRs hierarchical addressing scheme. IANA doesnt assign addresses directly, but rather delegates them to regional Internet registries (RIRs). These are APNIC, ARIN, LACNIC, and RIPE NCC. Each RIR can in turn delegate blocks of addresses to lower-level registries such as national Internet registries (NIRs) and local Internet registries (LIRs).
Eventually, blocks of addresses are obtained by Internet Service Providers (ISPs) for distribution to end-user organizations. Some of the ISPs customers are end-user organizations, but others are (smaller) ISPs themselves. They can in turn use or delegate the addresses in their blocks. This can continue for several stages in a hierarchical fashion. This arrangement helps ensure that IP addresses are assigned and used in the most efficient manner possible. See the section on CIDR for more information on how this works.
IANA, ICANN and the RIRs are responsible for more than just IP address allocation, though I have concentrated on IP addresses here for obvious reasons. For more general information on IANA, ICANN, APNIC, ARIN, LACNIC and RIPE NCC, try a can of alphabet soup or the topic on Internet registration authorities. J
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.