diff_apnic-089-v005

apnic-089-v004.txt

apnic-089-v005.txt

——————————————————————-

APNIC Document identity

Title: IPv6 Address Allocation and Assignment Policy

Short title: ipv6-address-policy

Document ref: APNIC-089

Version: 004

Version: 005

Date of original publication: 1 July 2002

Date of this version: 15 January 2007

Date of this version: 19 March 2007

Review scheduled: n/a

Obsoletes: Previous versions

Status: Obsolete

Comments: n/a

——————————————————————–

IPv6 Address Allocation and Assignment Policy

Status of this Memo

skipping to change at line 102

5.4.1. Assignment address space size

5.4.2. Assignment of multiple /48s to a single end site

5.4.3. Assignment to operator’s infrastructure

5.5. Registration

5.6. Reverse lookup

5.7. Existing IPv6 address space holders

5.8. Assignments to IXPs and critical infrastructure

5.8. Portable assignments

5.8.1. Internet Exchange Points

5.8.1. Small multihoming assignments

5.8.2. Critical infrastructure

5.8.2. Internet Exchange Points

5.8.3. Critical infrastructure

6. References

7. Appendix A: HD-Ratio

8. Appendix B: Background information

8.1. Background

8.2. Why a joint policy

8.3. The size of IPv6’s address space

skipping to change at line 136

skipping to change at line 137

document are intended to be adopted by each registry. However,

adoption of this document does not preclude local variations in each

region or area.

[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast address

space that IANA may allocate to the RIRs. In accordance with

[RFC2928, RFC2373bis, IAB-Request], IANA has allocated initial ranges

of global unicast IPv6 address space from the 2001::/16 address block

to the existing RIRs. This document concerns the initial and

subsequent allocations of the 2000::/3 unicast address space, for

which RIRs formulate allocation and assignment policies. Because end

which RIRs formulate allocation and assignment policies.

sites will generally be given /48 assignments [RFC 3177, RIRs-

on-48s], the particular emphasis of this document is on policies

relating the bits within 2000::/3 to the left of the /48 boundary.

However, since some end sites will receive /64 and /128 assignments,

all bits to the left of /64 are in scope.

This policy is considered to be an interim policy. It will be

reviewed in the future, subject to greater experience in the

administration of IPv6.

2. Definitions

[note: some of these definitions will be replaced by definitions from

other RIR documents in order to be more consistent.]

skipping to change at line 228

skipping to change at line 224

2.6. Assign

To assign means to delegate address space to an ISP or end-user, for

specific use within the Internet infrastructure they operate.

Assignments must only be made for specific purposes documented by

specific organizations and are not to be sub-assigned to other

parties.

2.7. Utilization

Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts

The actual usage of addresses within each assignment will be

(/48). The actual usage of addresses within each assignment will be

quite low, when compared to IPv4 assignments. In IPv6, “utilization”

is only measured in terms of the bits to the left of the /48

is only measured in terms of the bits to the left of the /56

boundary. In other words, utilization refers to the assignment of

/48s to end sites, and not the number of addresses assigned within

/56s to end sites, and not the number of addresses assigned within

individual /48s at those end sites.

individual /56s at those end sites.

Throughout this document, the term utilization refers to the

allocation of /48s to end sites, and not the number of addresses

allocation of /56s to end sites, and not the number of addresses

assigned within individual /48s within those end sites.

assigned within individual /56s within those end sites.

2.8. HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address

assignment [RFC 3194]. 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)

where (in the case of this document) the objects are IPv6 site

addresses (/48s) assigned from an IPv6 prefix of a given size.

addresses (/56s) assigned from an IPv6 prefix of a given size.

2.9. End site

An end site is defined as an end user (subscriber) who has a business

relationship with a service provider that involves:

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

skipping to change at line 416

skipping to change at line 411

5.1. Initial allocation

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an

organization must:

a) be an LIR;

b) not be an end site;

c) plan to provide IPv6 connectivity to organizations to which it

will assign /48s, by advertising that connectivity through its

will make assignments, by advertising that connectivity through

single aggregated address allocation; and

its single aggregated address allocation; and

d) have a plan for making at least 200 /48 assignments to other

d) have a plan for making at least 200 assignments to other

organizations within two years.

Private networks (those not connected to the public Internet) may

also be eligible for an IPv6 address space allocation provided they

meet equivalent criteria to those listed above.

5.1.2. Minimum initial allocation size

Organizations that meet the initial allocation criteria are eligible

to receive a minimum allocation of /32.

skipping to change at line 457

skipping to change at line 452

5.2. Subsequent allocation

Organizations that hold an existing IPv6 allocation may receive a

subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organization (ISP/LIR)

satisfies the evaluation threshold of past address utilization in

terms of the number of sites in units of /48 assignments. The HD-

terms of the number of sites in units of /56 assignments. The HD-

Ratio [RFC 3194] is used to determine the utilization thresholds that

justify the allocation of additional address as described below.

5.2.2. Applied HD-Ratio

The HD-Ratio value of 0.8 is adopted as indicating an acceptable

The HD-Ratio value of 0.94 is adopted as indicating an acceptable

address utilization for justifying the allocation of additional

address space. Appendix A provides a table showing the number of

assignments that are necessary to achieve an acceptable utilization

value for a given address block size.

5.2.3. Subsequent Allocation Size

When an organization has achieved an acceptable utilization for its

allocated address space, it is immediately eligible to obtain an

additional allocation that results in a doubling of the address space

skipping to change at line 500

skipping to change at line 495

properly evaluate the HD-Ratio when a subsequent allocation becomes

necessary.

5.4. Assignment

LIRs must make IPv6 assignments in accordance with the following

provisions.

5.4.1. Assignment address space size

Assignments are to be made in accordance with the existing guidelines

End-users are assigned an end site assignment from their LIR or ISP.

[RFC3177,RIRs-on-48], which are summarized here as:

The exact size of the assignment is a local decision for the LIR or

ISP to make, using a minimum value of a /64 (when only one subnet is

– /48 in the general case, except for very large subscribers

anticipated for the end site) up to the normal maximum of /48,

– /64 when it is known that one and only one subnet is needed by

except in cases of extra large end sites where a larger assignment

design

can be justified.

– /128 when it is absolutely known that one and only one device is

connecting.

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 did in IPv4,

except for the cases described in Section 4.4 and for the purposes of

measuring utilization as defined in this document.

5.4.2. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it

skipping to change at line 544

skipping to change at line 537

is regarded as one assignment regardless of the number of users using

the PoP. A separate assignment can be obtained for the in-house

operations of the operator.

5.5. Registration

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

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.

IRs shall maintain systems and practices that protect the security of

personal and commercial information that is used in request

skipping to change at line 587

skipping to change at line 580

Organizations that received /35 IPv6 allocations under the previous

IPv6 address policy [RIRv6-Policies] are immediately entitled to have

their allocation expanded to a /32 address block, without providing

justification, so long as they satisfy the criteria in Section 5.1.1.

The /32 address block will contain the already allocated smaller

address block (one or multiple /35 address blocks in many cases) that

was already reserved by the RIR for a subsequent allocation to the

organization. Requests for additional space beyond the minimum /32

size will be evaluated as discussed elsewhere in the document.

5.8. Assignments to IXPs and critical infrastructure

5.8. Portable assignments

5.8.1 Internet Exchange Points

5.8.1. Small multihoming assignments

An organization is eligible to receive a portable assignment from

APNIC if it is currently multihomed or plans to be multihomed

within three months.

An organization is considered to be multihomed if its network receives

full-time connectivity from more than one ISP and has one or more

routing prefixes announced by at least two of its ISPs.

The minimum assignment made under these terms is /48.

Address space assigned under these terms that is not used for

multihoming within three months of assignment by APNIC will be

reclaimed.

5.8.2. Internet Exchange Points

Internet Exchange Points are eligible to receive a portable assignment

from APNIC to be used exclusively to connect the IXP participant devices

to the Exchange Point.

The minimum assignment made under these terms is /48.

Global routability of the portable assignment is left to the discretion

of the IXP and its participants.

5.8.2 Critical infrastructure

5.8.3. Critical infrastructure

The following critical infrastructure networks, if operating in the Asia

Pacific region, are eligible to receive a portable assignment:

– root domain name system (DNS) server;

– global top level domain (gTLD) nameservers;

– country code TLD (ccTLDs) nameservers;

– IANA;

– Regional Internet Registry (RIRs); and

– National Internet Registry (NIRs).

Assignments to critical infrastructure are available only to the actual

operators of the network infrastructure performing such functions. Registrar

organisations which do not actually host the network housing the registry

infrastructure, will not be eligible for an assignment under this policy.

The maximum assignment made under these terms is /32 per operator.

Exchanges made under this policy remain subject to the address space license

policy.

skipping to change at line 665

skipping to change at line 674

The HD-Ratio is not intended to replace the traditional utilization

measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio

still requires counting the number of assigned objects. The primary

value of the HD-Ratio is its usefulness at determining reasonable

target utilization threshold values for an address space of a given

size. This document uses the HD-Ratio to determine the thresholds at

which a given allocation has achieved an acceptable level of

utilization and the assignment of additional address space becomes

justified.

The utilization threshold T, expressed as a number of individual /48

The utilization threshold T, expressed as a number of individual /56

prefixes to be allocated from IPv6 prefix P, can be calculated as:

((48-P)*HD)

((56-P)*HD)

T = 2

Thus, the utilization threshold for an organization requesting

subsequent allocation of IPv6 address block is specified as a

function of the prefix size and target HD ratio. This utilization

refers to the allocation of /48s to end sites, and not the

refers to the allocation of /56s to end sites, and not the

utilization of those /48s within those end sites. It is an address

utilization of those /56s within those end sites. It is an address

allocation utilization ratio and not an address assignment

utilization ratio.

In accordance with the recommendations of [RFC 3194], this document

This document adopts an HD-Ratio of 0.94 as the utilization

adopts an HD-Ratio of 0.8 as the utilization threshold for IPv6

threshold for IPv6 address space allocations.

address space allocations.

The following table provides equivalent absolute and percentage

address utilization figures for IPv6 prefixes, corresponding to an

HD-Ratio of 0.8

HD-Ratio of 0.94

P 48-P Total /48s Threshold Util%

P 56-P Total /56s Threshold Util %

48 0 1 1 100.0%

56 0 1 1 100.0

47 1 2 2 87.1%

55 1 2 2 95.9

46 2 4 3 75.8%

54 2 4 4 92.0

45 3 8 5 66.0%

53 3 8 7 88.3

44 4 16 9 57.4%

52 4 16 14 84.7

43 5 32 16 50.0%

51 5 32 26 81.2

42 6 64 28 43.5%

50 6 64 50 77.9

41 7 128 49 37.9%

49 7 128 96 74.7

40 8 256 84 33.0%

48 8 256 184 71.7

39 9 512 147 28.7%

47 9 512 352 68.8

38 10 1024 256 25.0%

46 10 1,024 676 66.0

37 11 2048 446 21.8%

45 11 2,048 1,296 63.3

36 12 4096 776 18.9%

44 12 4,096 2,487 60.7

35 13 8192 1351 16.5%

43 13 8,192 4,771 58.2

34 14 16384 2353 14.4%

42 14 16,384 9,153 55.9

33 15 32768 4096 12.5%

41 15 32,768 17,560 53.6

32 16 65536 7132 10.9%

40 16 65,536 33,689 51.4

31 17 131072 12417 9.5%

39 17 131,072 64,634 49.3

30 18 262144 21619 8.2%

38 18 262,144 124,002 47.3

29 19 524288 37641 7.2%

37 19 524,288 237,901 45.4

28 20 1048576 65536 6.3%

36 20 1,048,576 456,419 43.5

27 21 2097152 114105 5.4%

35 21 2,097,152 875,653 41.8

26 22 4194304 198668 4.7%

34 22 4,194,304 1,679,965 40.1

25 23 8388608 345901 4.1%

33 23 8,388,608 3,223,061 38.4

24 24 16777216 602249 3.6%

32 24 16,777,216 6,183,533 36.9

23 25 33554432 1048576 3.1%

31 25 33,554,432 11,863,283 35.4

22 26 67108864 1825677 2.7%

30 26 67,108,864 22,760,044 33.9

21 27 134217728 3178688 2.4%

29 27 134,217,728 43,665,787 32.5

20 28 268435456 5534417 2.1%

28 28 268,435,456 83,774,045 31.2

19 29 536870912 9635980 1.8%

27 29 536,870,912 160,722,871 29.9

18 30 1073741824 16777216 1.6%

26 30 1,073,741,824 308,351,367 28.7

17 31 2147483648 29210830 1.4%

25 31 2,147,483,648 591,580,804 27.5

16 32 4294967296 50859008 1.2%

24 32 4,294,967,296 1,134,964,479 26.4

15 33 8589934592 88550677 1.0%

23 33 8,589,934,592 2,177,461,403 25.3

14 34 17179869184 154175683 0.9%

22 34 17,179,869,184 4,177,521,189 24.3

13 35 34359738368 268435456 0.8%

21 35 34,359,738,368 8,014,692,369 23.3

12 36 68719476736 467373275 0.7%

20 36 68,719,476,736 15,376,413,635 22.4

11 37 137438953472 813744135 0.6%

19 37 137,438,953,472 29,500,083,768 21.5

10 38 274877906944 1416810831 0.5%

18 38 274,877,906,944 56,596,743,751 20.6

9 39 549755813888 2466810934 0.4%

17 39 549,755,813,888 108,582,451,102 19.8

8 40 1099511627776 4294967296 0.4%

16 40 1,099,511,627,776 208,318,498,661 18.9

7 41 2199023255552 7477972398 0.3%

15 41 2,199,023,255,552 399,664,922,315 18.2

6 42 4398046511104 13019906166 0.3%

14 42 4,398,046,511,104 766,768,439,460 17.4

5 43 8796093022208 22668973294 0.3%

13 43 8,796,093,022,208 1,471,066,903,609 16.7

4 44 17592186044416 39468974941 0.2%

12 44 17,592,186,044,416 2,822,283,395,519 16.0

11 45 35,184,372,088,832 5,414,630,391,777 15.4

10 46 70,368,744,177,664 10,388,121,308,479 14.8

9 47 140,737,488,355,328 19,929,904,076,845 14.2

8 48 281,474,976,710,656 38,236,083,765,023 13.6

7 49 562,949,953,421,312 73,357,006,438,603 13.0

6 50 1,125,899,906,842,620 140,737,488,355,328 12.5

5 51 2,251,799,813,685,250 270,008,845,646,446 12.0

4 52 4,503,599,627,370,500 518,019,595,058,136 11.5

8. Appendix B: Background information

8.1. Background

The impetus for revising the 1999 Provisional IPv6 policy started

with the APNIC meeting held in Taiwan in August 2001. Follow-on

discussions were held at the October, 2001 RIPE and ARIN meetings.

During these meetings, the participants recognized an urgent need for

more detailed, complete policies. One result of the meetings was the

skipping to change at line 782

skipping to change at line 799

allocation policies could also result in the adoption of practices

that lead to premature exhaustion of the address space.

It should be noted that the 128-bit address space is divided into

three logical parts, with the usage of each component managed

differently. The rightmost 64 bits, the Interface Identifier

[RFC2373], will often be a globally-unique IEEE identifier (e.g., mac

address). Although an “inefficient” way to use the Interface

Identifier field from the perspective of maximizing the number of

addressable nodes, the numbering scheme was explicitly chosen to

simplify Stateless Address Autoconfiguration [RFC2462].

simplify Stateless Address Autoconfiguration [RFC2462]. The middle

bits of an address indicate the subnet ID.

The middle 16 bits of an address indicate the subnet ID. Per [RFC

3177, RIRs-on-48s], this field will often be inefficiently utilized,

but the operational benefits of a consistent width subnet field were

deemed to be outweigh the drawbacks.

The decisions to inefficiently utilize the bits to the right of /48

were made under the knowledge and assumption that the bits to the

left of /48 would be managed prudently and that if done so, will be

adequate for the expected lifetime of IPv6 [RFC3177].

8.4. Acknowledgment

The initial version of this document was produced by The JPNIC IPv6

policy drafting team consisting of Akihiro Inomata, Akinori Maemura,

Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and

Toshiyuki Yamasaki. Special thanks goes out to this team, who worked

over a holiday in order to produce an initial document quickly.

An editing team was then organized by representatives from each of

End of changes. 28 change blocks.

107 lines changed or deleted

115 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/