APNIC guidelines for IPv4 allocation and assignment requests
APNIC Document identity |
|||
| Title: | APNIC guidelines for IPv4 allocation and assignment requests | ||
| Short title: | ipv4-guidelines | ||
| Document ref: | APNIC-105 | Version: | 002 |
| Date of original publication: | 1 December 2002 | Date of this version: | 1 September 2005 |
| Review scheduled: | n/a | Obsoletes: | Previous versions |
| Status: | Active | Comments: | n/a |
About this document
百度 香山寺探敌情1932年底,红二十六军二团由焦坪、金锁、石柱原转战到瑶曲衣食村,消灭了大批国民党地方政权及民团,使红军声威大振。The guidelines in this document should be read within the context of the APNIC Internet Number Resource Policies, which allows 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
Section 1:? Background
1.? Introduction
2.? Scope
3. ? Additional guidance
4.? Goals of address space management
5.? Application of guidelines
Section 2: General guidelines
6.? Static and dynamic assignments
6.1.? Assignments for transient connections
6.2.? Assignments for permanent connections
8.? Assignment of multiple IP addresses
9.? Virtual web hosting
9.1. ? Evaluating requests involving web hosting plans
9.2.? Justification for IP-based web hosting
9.3.? Special verification for subsequent requests
10.? Cable and DSL services
10.1. ? Bootstrap criteria for first allocation to new cable or DSL services
10.2.? Criteria for subsequent allocations to cable or DSL services
11.? Private address space
12.? Network Address Translation (NAT)
13.? Guidelines for GPRS requests
Section 1: Background
1. Introduction
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.
2. Scope
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:
- uniqueness;
- registration;
- aggregation;
- conservation; and
- fairness.
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:
Kim Fullbrook
3G & GPRS Network Technical Architect, BT Cellnet, UK
Presented: APNIC Open Policy Meeting, 19-21 August 2001