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

APNIC guidelines for IPv4 allocation and assignment requests

About this document

These guidelines are intended to complement the document Policies for IPv4 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. Static and dynamic assignments

6.1. Assignments for transient connections

6.2. Assignments for permanent connections

7. IP unnumbered

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.

Top

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.

Top

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
• APNIC FAQs

Top

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.

Top

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.

Top

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.

Top

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.

Top

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.

Top

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 at:

http://www.apnic.net/info/faq/ip_unnumb.html

Top

8.Assignment of multiple IP addresses

In general, if an organisation plans to assign more than one IP address per host, then it must provide full technical justification.

See also section 9 "Virtual web hosting".

Top

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 at:

http://www.apnic.net/info/faq/virtualwebfaq.html

Top

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).

Top

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.

Top

9.3. Special verification for subsequent requests

Organisations requesting a subsequent allocation will need to provide additional information if:

1. the organisation or its downstream customers have made assignments for IP-based web hosting; and

2. 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.

Top

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.

Top

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.

Top

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.

Top

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.

Top

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.

The document "Guidelines for IPv4 Addressing and AS Numbering for GPRS Network Infrastructure and Mobile Terminals" is available at:

http://www.gsmworld.com/technology/gprs/guidelines.shtml

A useful presentation summarising the recommendations is available at:

http://www.apnic.net/meetings/12/docs/IP_Mobile.ppt

Top