<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>FW: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2712.300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>All,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I have send this to this lists as the global-v6
lists does not seem to be working.</FONT></DIV>
<DIV><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV><FONT face=Arial size=2>Stuart</FONT></DIV>
<DIV style="FONT: 10pt arial">----- Original Message -----
<DIV style="BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A
title=stuart.prevo@btinternet.com
href="mailto:stuart.prevo@btinternet.com">Stuart Prevost</A> </DIV>
<DIV><B>To:</B> <A title=stu@prevost.net
href="mailto:stu@prevost.net">stu@prevost.net</A> </DIV>
<DIV><B>Sent:</B> Friday, January 11, 2002 7:32 PM</DIV>
<DIV><B>Subject:</B> Re: [GLOBAL-V6] New draft available: IPv6 Address
Allocation and Assignment Global Policy</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT face=Arial size=2><FONT
color=#000080>Dear all,</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT color=#000080>Please find enclosed comments
on new draft enclosed in text below.</FONT></FONT></DIV>
<DIV><FONT face=Arial color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Arial color=#000080 size=2>I an unable to attend the RIPE
meeting next week in Amsterdam, but Paul Mylotte will comment on the comments in
this mail at the meeting.</FONT></DIV>
<DIV><FONT face=Arial color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Arial color=#000080 size=2>Regards,</FONT></DIV>
<DIV><FONT face=Arial color=#000080 size=2>Stuart</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>
IPv6 Address Allocation and Assignment Global Policy</FONT> <BR><FONT face=Arial
size=2>
Draft of December, 22 2001</FONT> <BR><FONT face=Arial
size=2>
Version 2001-12-22</FONT> <BR><FONT face=Arial
size=2>
APNIC</FONT> <BR><FONT face=Arial
size=2>
ARIN</FONT> <BR><FONT face=Arial
size=2>
RIPE - NCC</FONT> </DIV>
<UL><BR>
<P><FONT face=Arial size=2>Status of this Memo</FONT> </P>
<P><FONT face=Arial size=2> This document specifies "Internet best
current practices" for the</FONT> <BR><FONT face=Arial size=2>
Internet community, and requests discussion and suggestions for</FONT>
<BR><FONT face=Arial size=2> improvements. Distribution of
this document is unlimited as long as</FONT> <BR><FONT face=Arial
size=2> its contents remain unchanged.</FONT> </P>
<P><FONT face=Arial size=2> Comments on this document should be
sent to the global-v6 mailing</FONT> <BR><FONT face=Arial size=2>
list:</FONT> </P>
<P><FONT face=Arial size=2> To post:
<global-v6@lists.apnic.net>.</FONT> <BR><FONT face=Arial
size=2> To subscribe: <U>
</U></FONT><U><FONT face=Arial color=#0000ff size=2><</FONT></U><A
href="http://www.apnic.net/net_comm/lists/"><U></U><U></U><U><FONT face=Arial
color=#0000ff
size=2>http://www.apnic.net/net_comm/lists/</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> <BR><FONT face=Arial
size=2> Archives:</FONT><U> <FONT face=Arial
color=#0000ff size=2><</FONT></U><A
href="http://www.apnic.net/mailing-lists/global-v6"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.apnic.net/mailing-lists/global-v6</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> </P>
<P><FONT face=Arial size=2> Contents</FONT> </P>
<P><FONT face=Arial size=2> Status of this
Memo.......................................... 1</FONT> </P>
<P><FONT face=Arial size=2> 1.
Introduction.............................................
2</FONT> <BR><FONT face=Arial size=2> 1.1.
Overview............................................
2</FONT> <BR><FONT face=Arial size=2> 1.2.
Current Status......................................
3</FONT> </P>
<P><FONT face=Arial size=2> 2.
Definitions..............................................
4</FONT> <BR><FONT face=Arial size=2> 2.1.
Autonomous System (AS)..............................
5</FONT> <BR><FONT face=Arial size=2> 2.2.
Internet Registry (IR)..............................
5</FONT> <BR><FONT face=Arial size=2> 2.3.
Internet Assigned Numbers Authority (IANA)..........
5</FONT> <BR><FONT face=Arial size=2> 2.4.
Regional Internet Registry (RIR)....................
6</FONT> <BR><FONT face=Arial size=2> 2.5.
National Internet Registry (NIR)....................
6</FONT> <BR><FONT face=Arial size=2> 2.6.
Local Internet Registry (LIR).......................
6</FONT> <BR><FONT face=Arial size=2> 2.7.
Allocate............................................
6</FONT> <BR><FONT face=Arial size=2> 2.8.
Assign..............................................
6</FONT> <BR><FONT face=Arial size=2> 2.9.
Utilization.........................................
7</FONT> <BR><FONT face=Arial size=2>
2.10.
Site............................................... 7</FONT>
</P>
<P><FONT face=Arial size=2> 3. Goals of IPv6 address space
management................... 7</FONT> <BR><FONT face=Arial
size=2> 3.1.
Goals...............................................
7</FONT> <BR><FONT face=Arial size=2> 3.2.
Uniqueness..........................................
8</FONT> <BR><FONT face=Arial size=2> 3.3.
Registration........................................
8</FONT> <BR><FONT face=Arial size=2> 3.4.
Aggregation.........................................
8</FONT> <BR><FONT face=Arial size=2> 3.5.
Conservation (Stewardship)..........................
9</FONT> <BR><FONT face=Arial size=2> 3.6.
Fairness............................................
9</FONT> <BR><FONT face=Arial size=2> 3.7.
Minimize Overhead...................................
9</FONT> <BR><FONT face=Arial size=2> 3.8.
Conflict of goals...................................
9</FONT> </P>
<P><FONT face=Arial size=2> 4. IPv6 Policy
Principles................................... 10</FONT> <BR><FONT
face=Arial size=2> 4.1. Address space not
to be considered property......... 10</FONT> <BR><FONT face=Arial
size=2> 4.2. Routability not
guaranteed.......................... 11</FONT> <BR><FONT
face=Arial size=2> 4.3. Minimum
Allocation.................................. 11</FONT> <BR><FONT
face=Arial size=2> 4.4. Consideration of
IPv4 Infrastructure................ 12</FONT> </P>
<P><FONT face=Arial size=2> 5. Policies for allocations and
assignments................. 12</FONT> <BR><FONT face=Arial
size=2> 5.1. Consistency of IR address
space management policies. 12</FONT> <BR><FONT face=Arial
size=2> 5.2. Initial
allocation.................................. 12</FONT> <BR><FONT
face=Arial size=2>
5.2.1. Initial allocation criteria....................
12</FONT> <BR><FONT face=Arial
size=2> 5.2.2. Initial
allocation size........................ 13</FONT> <BR><FONT
face=Arial size=2> 5.3. Subsequent
allocation............................... 13</FONT> <BR><FONT
face=Arial size=2>
5.3.1. Subsequent allocation criteria.................
13</FONT> <BR><FONT face=Arial
size=2> 5.3.2.
Utilization Metric............................. 13</FONT>
<BR><FONT face=Arial size=2>
5.3.3. Applied HD-Ratio...............................
14</FONT> <BR><FONT face=Arial
size=2> 5.3.4.
Subsequent Allocation Size..................... 14</FONT>
<BR><FONT face=Arial size=2> 5.4.
LIR-to-ISP allocation............................... 14</FONT>
<BR><FONT face=Arial size=2> 5.5.
Assignment.......................................... 15</FONT>
<BR><FONT face=Arial size=2>
5.5.1. Assignment address space size..................
15</FONT> <BR><FONT face=Arial
size=2> 5.5.2.
Assignment to a site........................... 15</FONT>
<BR><FONT face=Arial size=2>
5.5.3. Assignment of multiple /48s to a single site...
15</FONT> <BR><FONT face=Arial
size=2> 5.5.4.
Assignment to operator's infrastructure........ 15</FONT>
<BR><FONT face=Arial size=2> 5.6. DB
registration..................................... 16</FONT>
<BR><FONT face=Arial size=2> 5.7. Reverse
lookup...................................... 16</FONT> <BR><FONT
face=Arial size=2> 5.8. Validity of
allocations and assignments............. 16</FONT> <BR><FONT
face=Arial size=2> 5.9. Existing IPv6
address space holders................. 17</FONT> </P>
<P><FONT face=Arial size=2> 6. Special
case............................................. 17</FONT>
<BR><FONT face=Arial size=2> 6.1. IX
(Internet Exchange).............................. 17</FONT> </P>
<P><FONT face=Arial size=2> 7.
Acknowledgment...........................................
17</FONT> </P>
<P><FONT face=Arial size=2> 8.
References...............................................
18</FONT> </P>
<P><FONT face=Arial size=2> 9. Appendix
A:.............................................. 19</FONT> </P>
<P><FONT face=Arial size=2>1. Introduction</FONT> </P><BR>
<P><FONT face=Arial size=2>1.1. Overview</FONT> </P>
<P><FONT face=Arial size=2> This document describes policies for
the allocation and assignment of</FONT> <BR><FONT face=Arial
size=2> globally unique Internet Protocol Version 6 (IPv6) address
space. In</FONT> <BR><FONT face=Arial size=2> particular,
[RFC2373, RFC2373bis] designates 2000::/3 to be global</FONT> <BR><FONT
face=Arial size=2> unicast address space that IANA may
allocate. In accordance with</FONT> <BR><FONT face=Arial
size=2> [RFC2928, RFC2373bis, IAB-Request], IANA has assigned
initial ranges</FONT> <BR><FONT face=Arial size=2> of global
unicast IPv6 address space from the 2001::/16 address block</FONT> <BR><FONT
face=Arial size=2> to the existing RIRs. This document
concerns the initial and</FONT> <BR><FONT face=Arial size=2>
subsequent allocations of the 2000::/3 unicast address space, for</FONT>
<BR><FONT face=Arial size=2> which RIRs formulate allocation
policies. Because end sites will</FONT> <BR><FONT face=Arial
size=2> generally be given /48 allocations [RFC 3177,
RIRs-on-48s], the</FONT> <BR><FONT face=Arial size=2> particular
emphasis of this document is on policies relating the bits</FONT> <BR><FONT
face=Arial size=2> within 2000::/3 to the left of the /48
boundary. However, since some</FONT> <BR><FONT face=Arial size=2>
end sites will receive /64 and /128 allocations, all bits to the left</FONT>
<BR><FONT face=Arial size=2> of /64 are in scope.</FONT> </P>
<P><FONT face=Arial size=2> This document updates and replaces all
the guidelines and procedures</FONT> <BR><FONT face=Arial size=2>
of the existing Provisional IPv6 Policies [RIRv6-Policies] based on</FONT>
<BR><FONT face=Arial size=2> over two years of experience with the
1999 policy. The Provisional</FONT> <BR><FONT face=Arial
size=2> IPv6 Policy document will be obsoleted with the adoption
of this</FONT> <BR><FONT face=Arial size=2> document.</FONT> </P>
<P><FONT face=Arial size=2> Address policies should be globally
uniform and formulated in a</FONT> <BR><FONT face=Arial size=2>
bottom-up manner through consensus processes at regional and global</FONT>
<BR><FONT face=Arial size=2> levels. Address policies must be
determined with well-balanced</FONT> <BR><FONT face=Arial size=2>
consideration given to not only technical constraints and the</FONT> <BR><FONT
face=Arial size=2> expectations of the Internet community, but
also to the operational</FONT> <BR><FONT face=Arial size=2> needs
of ISPs and end users. Furthermore, the policies should be</FONT>
<BR><FONT face=Arial size=2> reviewed whenever necessary in
accordance with changes in the</FONT> <BR><FONT face=Arial size=2>
external environment or operational experience of the relevant</FONT>
<BR><FONT face=Arial size=2> communities.</FONT> </P>
<P><FONT face=Arial size=2> Policies described in this document
are global in nature and are</FONT> <BR><FONT face=Arial size=2>
intended to be followed in each registry. However, adoption of
this</FONT> <BR><FONT face=Arial size=2> document does not
preclude local variations in each region or area.</FONT> </P>
<P><FONT face=Arial size=2> This policy is also considered an
interim policy in the sense that</FONT> <BR><FONT face=Arial
size=2> there is still little experience with allocating IPv6
addresses. As</FONT> <BR><FONT face=Arial size=2> experience
from implementing the policy is gained, some aspects of</FONT> <BR><FONT
face=Arial size=2> the policy will likely need review and
updating.</FONT> </P><BR>
<P><FONT face=Arial size=2>1.2. Current Status</FONT> </P>
<P><FONT face=Arial size=2> The APNIC meeting held in Taiwan in
August 2001 discussed policies</FONT> <BR><FONT face=Arial size=2>
relating to IPv6 address allocation and assignment and reached a</FONT>
<BR><FONT face=Arial size=2> certain consensus. Afterward,
similar suggestions were made at a</FONT> <BR><FONT face=Arial
size=2> RIPE meeting held in October 2001 and an ARIN meeting held
in the</FONT> <BR><FONT face=Arial size=2> same month.
Various discussions were held at these meetings, with</FONT> <BR><FONT
face=Arial size=2> consensus identified on a number of
points. This document makes a</FONT> <BR><FONT face=Arial
size=2> proposal based upon the results of discussions at these
meetings.</FONT> </P>
<P><FONT face=Arial size=2> In all of these meetings, the
participants recognized an urgent need</FONT> <BR><FONT face=Arial
size=2> for more detailed, complete policies in the Asia Pacific
Region</FONT> <BR><FONT face=Arial size=2> governing global IPv6
address space management. It was generally</FONT> <BR><FONT face=Arial
size=2> recognized that discussion about policies for IPv6
allocation and</FONT> <BR><FONT face=Arial size=2> assignment will
not easily come to an end, but there is a consensus</FONT> <BR><FONT
face=Arial size=2> that such discussion should be summed up
quickly to establish interim</FONT> <BR><FONT face=Arial size=2>
policies. Accordingly, this document should be considered as a
time-</FONT> <BR><FONT face=Arial size=2> limited public document
that describes the most reasonable solution</FONT> <BR><FONT face=Arial
size=2> available at present that has been obtained through
these</FONT> <BR><FONT face=Arial size=2> discussions. This
document will therefore be duly updated as the</FONT> <BR><FONT face=Arial
size=2> Internet environment of IPv6 progresses, and it is
expected that</FONT> <BR><FONT face=Arial size=2> updates will
occur relatively frequently in the coming years.</FONT> </P>
<P><FONT face=Arial size=2> This document does not provide details
of discussions concerning</FONT> <BR><FONT face=Arial size=2>
individual policy issues, however the following sources provide</FONT>
<BR><FONT face=Arial size=2> background information which may be
of interest:</FONT> </P>
<P><FONT face=Arial size=2> Meeting results:</FONT><U> <FONT
face=Arial color=#0000ff size=2><</FONT></U><A
href="http://www.apnic.net/meetings/12/results/"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.apnic.net/meetings/12/results/</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> <BR><FONT face=Arial
size=2> </FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A
href="http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> <BR><FONT face=Arial
size=2> </FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A
href="http://www.arin.net/minutes/ARIN_VIII/PPM.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.arin.net/minutes/ARIN_VIII/PPM.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> </P>
<P><FONT face=Arial size=2> Presentation Materials:</FONT>
<BR><FONT face=Arial size=2> </FONT><U> <FONT face=Arial
color=#0000ff size=2><</FONT></U><A
href="http://www.apnic.net/meetings/12/docs/prop_new_ipv6_policy.ppt"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.apnic.net/meetings/12/docs/prop_new_ipv6_policy.ppt</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> <BR><FONT face=Arial
size=2> </FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A
href="http://www.apnic.net/meetings/12/docs/ipv6principles-dist.ppt"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.apnic.net/meetings/12/docs/ipv6principles-dist.ppt</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> <BR><FONT face=Arial
size=2> </FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A
href="http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> <BR><FONT face=Arial
size=2> </FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A
href="http://www.arin.net/minutes/ARIN_VIII/PPM.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.arin.net/minutes/ARIN_VIII/PPM.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U> </P><BR>
<P><FONT face=Arial size=2>2. Definitions</FONT> </P>
<P><FONT face=Arial size=2> [note: some of these definitions will
be replaced by definitions from</FONT> <BR><FONT face=Arial
size=2> other RIR documents in order to be more
consistent.]</FONT> </P>
<P><FONT face=Arial size=2> The following terms and their
definitions are of particular</FONT> <BR><FONT face=Arial size=2>
importance to the understanding of the goals, environment, and</FONT>
<BR><FONT face=Arial size=2> policies described in this
document.</FONT> </P>
<P><FONT face=Arial size=2> Responsibility for management of IPv6
address spaces is distributed</FONT> <BR><FONT face=Arial size=2>
globally in accordance with the hierarchical structure shown below.</FONT>
</P><BR>
<P><FONT face=Arial
size=2>
+--------+</FONT> <BR><FONT face=Arial
size=2>
| IANA |</FONT> <BR><FONT face=Arial
size=2>
+--------+</FONT> <BR><FONT face=Arial
size=2>
|</FONT> <BR><FONT face=Arial
size=2>
+-----------+-----------+</FONT> <BR><FONT face=Arial
size=2>
|
| |</FONT>
<BR><FONT face=Arial
size=2>
+--------+ +--------+ +--------+</FONT> <BR><FONT face=Arial
size=2>
| RIR | | RIR | |
RIR | Regional Internet</FONT> <BR><FONT face=Arial
size=2>
+--------+ +--------+ +--------+ Registries</FONT> <BR><FONT
face=Arial
size=2>
|</FONT> <BR><FONT face=Arial
size=2>
+-----------+--+--------+</FONT> <BR><FONT face=Arial
size=2>
|
| |</FONT>
<BR><FONT face=Arial
size=2>
| +-----+
+-----+</FONT> <BR><FONT face=Arial
size=2>
| | NIR | |
NIR | National Internet</FONT> <BR><FONT face=Arial
size=2>
| +-----+
+-----+ Registries</FONT> <BR><FONT face=Arial
size=2>
|
| |</FONT>
<BR><FONT face=Arial
size=2>
+--------+ +--------+ +--------+</FONT> <BR><FONT
face=Arial
size=2>
|LIR/ISP | |LIR/ISP | |LIR/ISP | Local
Internet</FONT> <BR><FONT face=Arial
size=2>
+--------+ +--------+ +--------+
Registries</FONT> <BR><FONT face=Arial
size=2>
|
| |</FONT>
<BR><FONT face=Arial
size=2>
+---------+
| |</FONT>
<BR><FONT face=Arial
size=2>
|
|
| |</FONT>
<BR><FONT face=Arial
size=2>
+-------+ +----+ +----+
+----+</FONT> <BR><FONT face=Arial
size=2>
|EU(ISP)| | EU | | EU |
| EU | End users</FONT> <BR><FONT face=Arial
size=2>
+-------+ +----+ +----+
+----+</FONT> </P><BR><BR>
<P><FONT face=Arial size=2>2.1. Autonomous System (AS)</FONT> </P>
<P><FONT face=Arial size=2> Autonomous Systems are the unit of
routing policy in the world of</FONT> <BR><FONT face=Arial size=2>
exterior routing, and are specifically applicable to protocols like</FONT>
<BR><FONT face=Arial size=2> BGP [RFC1771].</FONT> </P><BR>
<P><FONT face=Arial size=2>2.2. Internet Registry (IR)</FONT> </P>
<P><FONT face=Arial size=2> An Internet Registry (IR) is an
organization that is responsible for</FONT> <BR><FONT face=Arial
size=2> distributing IP address space to its members or customers
and for</FONT> <BR><FONT face=Arial size=2> registering those
distributions. IRs are classified according to</FONT> <BR><FONT
face=Arial size=2> their primary function and territorial scope
within the hierarchical</FONT> <BR><FONT face=Arial size=2>
structure depicted in the figure above.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.3. Internet Assigned Numbers Authority
(IANA)</FONT> </P>
<P><FONT face=Arial size=2> The Internet Assigned Numbers
Authority (IANA) has responsibility for</FONT> <BR><FONT face=Arial
size=2> management of the entire IP address space used on the
Internet.</FONT> <BR><FONT face=Arial size=2> Actual assignment
operations are performed by organizations under</FONT> <BR><FONT face=Arial
size=2> IANA. Rather than allocating or assigning address
space to</FONT> <BR><FONT face=Arial size=2> operational networks,
the IANA delegates responsibility for large</FONT> <BR><FONT face=Arial
size=2> blocks of address space to Regional Internet Registries,
for</FONT> <BR><FONT face=Arial size=2> management at the regional
level.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.4. Regional Internet Registry (RIR)</FONT>
</P>
<P><FONT face=Arial size=2> Regional Internet Registries (RIRs)
are established and authorized by</FONT> <BR><FONT face=Arial
size=2> respective regional communities, and recognized by the
IANA to serve</FONT> <BR><FONT face=Arial size=2> and represent
large geographical regions. The primary role of RIRs</FONT> <BR><FONT
face=Arial size=2> is to manage and distribute public Internet
address space within</FONT> <BR><FONT face=Arial size=2> their
respective regions. Currently, there are three RIRs: APNIC,</FONT>
<BR><FONT face=Arial size=2> RIPE NCC, and ARIN.
Preparations are being made to establish LACNIC</FONT> <BR><FONT face=Arial
size=2> and AfriNIC.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.5. National Internet Registry (NIR)</FONT>
</P>
<P><FONT face=Arial size=2> A National Internet Registry (NIR) is
an IR that primarily allocates</FONT> <BR><FONT face=Arial size=2>
address space to its members, which are Local Internet Registries</FONT>
<BR><FONT face=Arial size=2> (LIRs). NIR members are
generally Internet Service Providers (ISPs)</FONT> <BR><FONT face=Arial
size=2> organized at a national level. A NIR is constituted
from ISPs, but</FONT> <BR><FONT face=Arial size=2> the NIR itself
does not function as an ISP. NIRs are expected to</FONT> <BR><FONT
face=Arial size=2> remain neutral to the interests of ISPs of
their constituency. NIRs</FONT> <BR><FONT face=Arial size=2>
exist mostly in the Asia Pacific Region.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.6. Local Internet Registry (LIR)</FONT>
</P>
<P><FONT face=Arial size=2> A Local Internet Registry (LIR) is an
IR that primarily assigns</FONT> <BR><FONT face=Arial size=2>
address space to the users of the network services that it provides.</FONT>
<BR><FONT face=Arial size=2> LIRs are generally ISPs, whose
customers are primarily end users and</FONT> <BR><FONT face=Arial
size=2> possibly other ISPs.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.7. Allocate</FONT> </P>
<P><FONT face=Arial size=2> To allocate means to distribute
address space to IRs for the purpose</FONT> <BR><FONT face=Arial
size=2> of subsequent distribution by them.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.8. Assign</FONT> </P>
<P><FONT face=Arial size=2> To assign means to designate address
space that an IR distributes</FONT> <BR><FONT face=Arial size=2>
part or all of to an end user for the purpose of actual deployment in</FONT>
<BR><FONT face=Arial size=2> that end user's or ISP's own
network. Address space is also</FONT> <BR><FONT face=Arial
size=2> designated as assigned if the IR uses it for the purpose
of</FONT> <BR><FONT face=Arial size=2> addressing their own
network. Assignments are made only for specific</FONT> <BR><FONT
face=Arial size=2> purposes demonstrated by specific organizations
and are not be sub-</FONT> <BR><FONT face=Arial size=2> allocated
or sub-assigned to other parties.</FONT> </P>
<P><FONT face=Arial size=2> In this hierarchical structure, IANA
allocates address space to RIRs</FONT> <BR><FONT face=Arial
size=2> for the purpose of redistribution. RIRs then
allocate address space</FONT> <BR><FONT face=Arial size=2> to NIRs
or LIRs in their respective regions (or in some cases to NIRs</FONT> <BR><FONT
face=Arial size=2> which further allocate the space to LIRs within
their own countries).</FONT> <BR><FONT face=Arial size=2> Each NIR
allocates address space to LIRs in its own country. When an</FONT>
<BR><FONT face=Arial size=2> RIR or NIR allocates address space to
an LIR, it also delegates to</FONT> <BR><FONT face=Arial size=2>
the LIR the authority to assign addresses to end users.</FONT> </P><BR>
<P><FONT face=Arial size=2>2.9. Utilization</FONT> </P>
<P><FONT face=Arial size=2> Unlike IPv4, IPv6 generally assigns a
/48 to each end site. The</FONT> <BR><FONT face=Arial size=2>
actual utilization of any particular /48, when compared to IPv4 ,</FONT>
<BR><FONT face=Arial size=2> will be extremely low. In IPv6, the
"utlization" that is of interest</FONT> <BR><FONT face=Arial
size=2> refers to the bits to the left of the /48.</FONT> </P>
<P><FONT face=Arial size=2> Throughout this document, the term
utilization refers to the</FONT> <BR><FONT face=Arial size=2>
allocation of /48s to end sites, and not the utilization of those</FONT>
<BR><FONT face=Arial size=2> /48s within those end sites.</FONT>
</P><BR>
<P><FONT face=Arial size=2>2.10. Site</FONT> </P>
<P><FONT face=Arial size=2> A site is defined as an end user
(subscriber) who has a business</FONT> <BR><FONT face=Arial
size=2> relationship with a provider that involves that provider
carrying its</FONT> <BR><FONT face=Arial size=2> traffic.
Every end user (subscriber) individually on a contract with</FONT> <BR><FONT
face=Arial size=2> an ISP is considered an entity and is eligible
to receive a /48 IPv6</FONT> <BR><FONT face=Arial size=2>
assignment, regardless of organization or geographical location.</FONT>
</P><BR>
<P><FONT face=Arial size=2>3. Goals of IPv6 address space
management</FONT> </P><BR>
<P><FONT face=Arial size=2>3.1. Goals</FONT> </P>
<P><FONT face=Arial size=2> The goals of address space management
described here reflect the</FONT> <BR><FONT face=Arial size=2>
mutual interest of all members of the Internet community and ensure</FONT>
<BR><FONT face=Arial size=2> that the Internet is able to function
and grow to the maximum extent</FONT> <BR><FONT face=Arial size=2>
possible.</FONT> </P>
<P><FONT face=Arial size=2> Address policies must be determined
with well-balanced consideration</FONT> <BR><FONT face=Arial
size=2> given to not only technical constraints and the
expectations of the</FONT> <BR><FONT face=Arial size=2> Internet
community but also to the operational needs of ISPs and end</FONT> <BR><FONT
face=Arial size=2> users.</FONT> </P>
<P><FONT face=Arial size=2> These goals are essentially the same
as the goals in IPv4 policies</FONT> <BR><FONT face=Arial size=2>
that have been formulated by the Internet community. However,</FONT>
<BR><FONT face=Arial size=2> attention must be paid to the fact
that differences between IPv6 and</FONT> <BR><FONT face=Arial
size=2> IPv4 change the relative priority of elements that must be
considered</FONT> <BR><FONT face=Arial size=2> to attain these
goals.</FONT> </P><BR>
<P><FONT face=Arial size=2>3.2. Uniqueness</FONT> </P>
<P><FONT face=Arial size=2> Every assignment and/or allocation of
address space must guarantee</FONT> <BR><FONT face=Arial size=2>
uniqueness worldwide. This is an absolute requirement for
ensuring</FONT> <BR><FONT face=Arial size=2> that every public
host on the Internet can be uniquely identified.</FONT> </P><BR>
<P><FONT face=Arial size=2>3.3. Registration</FONT> </P>
<P><FONT face=Arial size=2> Every assignment and allocation of
Internet address space must be</FONT> <BR><FONT face=Arial size=2>
registered in a public registry database accessible to all members of</FONT>
<BR><FONT face=Arial size=2> the Internet community.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>Which database is this referring to
? Each RIR database?</FONT> </P>
<P><FONT face=Arial size=2> This is necessary to ensure the
uniqueness of each Internet address</FONT> <BR><FONT face=Arial
size=2> and to provide reference information for Internet
troubleshooting at</FONT> <BR><FONT face=Arial size=2> all levels,
ranging from all RIRs and IRs to end users.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>Are we talking /48s /64s and
/128s?</FONT> </P>
<P><FONT face=Arial size=2> It also reflects the expectation of
the Internet community that all</FONT> <BR><FONT face=Arial
size=2> users of public resources, such as address space, should
be able to</FONT> <BR><FONT face=Arial size=2> check the
conditions of the resources.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>What does "conditions of the
resource" mean?</FONT> </P>
<P><FONT face=Arial size=2>3.4. Aggregation</FONT> </P>
<P><FONT face=Arial size=2> Wherever possible, address space
should be distributed in a</FONT> <BR><FONT face=Arial size=2>
hierarchical manner, according to the topology of network</FONT> <BR><FONT
face=Arial size=2> infrastructure.</FONT> </P>
<P><FONT face=Arial size=2> This is necessary to permit the
aggregation of routing information</FONT> <BR><FONT face=Arial
size=2> and limit the expansion of Internet routing tables.
With its vast</FONT> <BR><FONT face=Arial size=2> address space,
IPv6 makes hierarchical distribution for aggregation</FONT> <BR><FONT
face=Arial size=2> much easier than IPv4.</FONT> </P>
<P><FONT face=Arial size=2> The IPv6 specification creates a huge
address space, and the number</FONT> <BR><FONT face=Arial size=2>
of hosts under internal routing control of an individual autonomous</FONT>
<BR><FONT face=Arial size=2> system is expected to increase
dramatically compared with IPv4. For</FONT> <BR><FONT face=Arial
size=2> example, cellular phones, various electric appliances, and
telemeter</FONT> <BR><FONT face=Arial size=2> sensors, are likely
to become connected to the Internet in addition</FONT> <BR><FONT face=Arial
size=2> to the conventional types of IPv4 hosts. Thus,
hierarchical</FONT> <BR><FONT face=Arial size=2> distributions
must be considered to limit the expansion of routing</FONT> <BR><FONT
face=Arial size=2> tables regarding not only external routing
information advertised in</FONT> <BR><FONT face=Arial size=2> the
Internet default-free zone but also internal routing information</FONT>
<BR><FONT face=Arial size=2> within an autonomous system.
Because internal aggregation is</FONT> <BR><FONT face=Arial
size=2> important, policies should be sensitive to supporting
better internal</FONT> <BR><FONT face=Arial size=2> aggregation
(e.g, through assignment of bigger blocks).</FONT> </P><BR>
<P><FONT face=Arial size=2>3.5. Conservation (Stewardship)</FONT> </P>
<P><FONT face=Arial size=2> Maintaining unnecessary allocations
and assignments or stockpiling</FONT> <BR><FONT face=Arial size=2>
address space with no aggregation merit should be avoided as a matter</FONT>
<BR><FONT face=Arial size=2> of course. Also, efforts must
be made for the efficiency of address</FONT> <BR><FONT face=Arial
size=2> use as much as possible within the bounds of other
constraints.</FONT> </P><BR>
<P><FONT face=Arial size=2>3.6. Fairness</FONT> </P>
<P><FONT face=Arial size=2> All policies and practices relating to
the use of public address</FONT> <BR><FONT face=Arial size=2>
space should apply fairly and equitably to all existing and potential</FONT>
<BR><FONT face=Arial size=2> members of the Internet community,
regardless of their location,</FONT> <BR><FONT face=Arial size=2>
nationality, size or any other factor.</FONT> </P><BR>
<P><FONT face=Arial size=2>3.7. Minimize Overhead</FONT> </P>
<P><FONT face=Arial size=2> It is desirable to minimize the
overhead associated with obtaining</FONT> <BR><FONT face=Arial
size=2> additional address space as a site grows. Overhead
includes the need</FONT> <BR><FONT face=Arial size=2> to go back
to RIRs for additional space too frequently, the overhead</FONT> <BR><FONT
face=Arial size=2> associated with managing address space that
grows through a number of</FONT> <BR><FONT face=Arial size=2>
small successive incremental expansions rather than through fewer,</FONT>
<BR><FONT face=Arial size=2> but larger, expansions, etc.</FONT>
</P></UL>
<DIV><FONT face=Arial color=#000080 size=2>This para talks about trying to
minimize overhead as a site grows, but if a site is allocated a /48 and needs an
additional /48 for expansion then according to 5.5.3</FONT></DIV>
<DIV><FONT face=Arial><FONT size=2><FONT color=#000080>The LIR whose customers
needs an additional /48 request needs to</FONT> <FONT
color=#0000ff>be</FONT> <FONT color=#000080> reviewed at the RIR/NIR
level. Is this really minimizing overhead!!</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#000080 size=2>Maybe this section needs more text
and a reference to 5.5.3?</FONT> </DIV>
<UL><BR>
<P><FONT face=Arial size=2>3.8. Conflict of goals</FONT> </P>
<P><FONT face=Arial size=2> The goals of conservation, aggregation
and minimization of</FONT> <BR><FONT face=Arial size=2>
administrative overhead often conflict with each other. In IPv6</FONT>
<BR><FONT face=Arial size=2> address management, the six goals
described above are given different</FONT> <BR><FONT face=Arial
size=2> priorities from the implicit priorities of IPv4 address
management.</FONT> </P>
<P><FONT face=Arial size=2> IPv6 address management should give
higher priority to aggregation</FONT> <BR><FONT face=Arial size=2>
and lower priority to address conservation, when compared with</FONT>
<BR><FONT face=Arial size=2> current IPv4 management
practices. This does not mean that wasteful</FONT> <BR><FONT face=Arial
size=2> address usage should be tolerated because vast address
space is</FONT> <BR><FONT face=Arial size=2> available.
Instead, emphasis is placed on the need for policies that</FONT> <BR><FONT
face=Arial size=2> place aggregation in higher priority so that
the number of external</FONT> <BR><FONT face=Arial size=2> and
internal routes will be practically limited in the large address</FONT>
<BR><FONT face=Arial size=2> space to ensure stable Internet
operations for a long time to come.</FONT> <BR><FONT face=Arial
size=2> Emphasis on aggregation sometimes leads to somewhat lower
priority on</FONT> <BR><FONT face=Arial size=2> address
conservation because these two goals tend to conflict with</FONT> <BR><FONT
face=Arial size=2> each other.</FONT> </P>
<P><FONT face=Arial size=2> It should be noted that an exclusive
choice between aggregation and</FONT> <BR><FONT face=Arial size=2>
conservation will not be made on the basis of the policies or</FONT> <BR><FONT
face=Arial size=2> judgment of any registry practices in
accordance with these policies.</FONT> </P>
<P><FONT face=Arial size=2> Both aggregation and conservation
should be taken into consideration</FONT> <BR><FONT face=Arial
size=2> in the right balance. In IPv6, the right balance is
generally "more</FONT> <BR><FONT face=Arial size=2> aggregation,
less conservation".</FONT> </P>
<P><FONT face=Arial size=2> The balance between aggregation and
conservation will be reviewed</FONT> <BR><FONT face=Arial size=2>
over time according to various factors, such as operational</FONT> <BR><FONT
face=Arial size=2> experience and address consumption.</FONT> </P>
<P><FONT face=Arial size=2> Some or all of the goals described
here may occasionally be in</FONT> <BR><FONT face=Arial size=2>
conflict with the interests of individual IRs or end users.</FONT> <BR><FONT
face=Arial size=2> Therefore, all IRs evaluating requests for
allocations and</FONT> <BR><FONT face=Arial size=2> assignments
must make judgment, seeking to balance the needs of the</FONT> <BR><FONT
face=Arial size=2> applicant with the needs of the Internet
community as a whole.</FONT> </P>
<P><FONT face=Arial size=2> The policies described in this
document are intended to help IRs</FONT> <BR><FONT face=Arial
size=2> balance these needs in consistent and equitable
ways. Full</FONT> <BR><FONT face=Arial size=2> documentation
of and transparency within the decision making process</FONT> <BR><FONT
face=Arial size=2> must also be maintained in order to achieve
this result.</FONT> </P><BR>
<P><FONT face=Arial size=2>4. IPv6 Policy Principles</FONT> </P>
<P><FONT face=Arial size=2> To address the goals described in the
previous section, the policies</FONT> <BR><FONT face=Arial size=2>
in this document discuss and follow the basic principles described</FONT>
<BR><FONT face=Arial size=2> below.</FONT> </P><BR>
<P><FONT face=Arial size=2>4.1. Address space not to be considered
property</FONT> </P>
<P><FONT face=Arial size=2> It is contrary to the goals of this
document and is not in the</FONT> <BR><FONT face=Arial size=2>
interests of the Internet community as a whole for address space to</FONT>
<BR><FONT face=Arial size=2> be considered freehold
property.</FONT> </P>
<P><FONT face=Arial size=2> The global IPv6 policies in this
document are based upon the</FONT> <BR><FONT face=Arial size=2>
understanding that address space is lease-licensed for use rather</FONT>
<BR><FONT face=Arial size=2> than owned. All Internet Registries
are expected to manage address</FONT> <BR><FONT face=Arial size=2>
space operations correctly in accordance with this principle.</FONT> </P>
<P><FONT face=Arial size=2> According to this policy, IP addresses
will be allocated on a lease-</FONT> <BR><FONT face=Arial size=2>
license basis, with such lease-licenses to be of specific limited</FONT>
<BR><FONT face=Arial size=2> duration of normally one year.
Conditions of a lease-license have</FONT> <BR><FONT face=Arial
size=2> specific conditions applied at the start or renewal of the
lease.</FONT> </P>
<P><FONT face=Arial size=2> Lease-licenses will typically be
renewed automatically at the end of</FONT> <BR><FONT face=Arial
size=2> their duration when the following two conditions are
met:</FONT> <BR><FONT face=Arial size=2> a) The original
basis of the allocation remains valid.</FONT> <BR><FONT face=Arial
size=2> b) Registration requirements relating to that
allocation have been</FONT> <BR><FONT face=Arial
size=2> fulfilled at the time of renewal</FONT>
</P>
<P><FONT face=Arial size=2> However, when a lease-license is
renewed, the new lease-license will</FONT> <BR><FONT face=Arial
size=2> be evaluated under and governed by the applicable resource
allocation</FONT> <BR><FONT face=Arial size=2> and renewal
policies in place at the time of renewal.</FONT> </P></UL>
<DIV><FONT face=Arial color=#000080 size=2>It is not clear what "resource
allocation and renewal policies" are exactly. There is no definition of
them in this document. </FONT></DIV>
<DIV><FONT face=Arial color=#000080 size=2>Sounds like we are moving towards the
way the DNS system works with the renewal of Domain Names.</FONT> </DIV>
<UL>
<P><FONT face=Arial size=2> Changes to the conditions of current
lease-licences shall be subject</FONT> <BR><FONT face=Arial
size=2> to a definite period of notice, except in exceptional
circumstances</FONT> <BR><FONT face=Arial size=2> recognized by a
consensus of the Internet community.</FONT> </P>
<P><FONT face=Arial size=2> As address space is not owned, and
consistent with the desire to</FONT> <BR><FONT face=Arial size=2>
avoid excessive fragmentation of address space, it may become</FONT> <BR><FONT
face=Arial size=2> necessary in extreme circumstances to renumber
assignments. Such</FONT> <BR><FONT face=Arial size=2> renumbering
will only be undertaken after extensive consultation with</FONT> <BR><FONT
face=Arial size=2> the Internet community.</FONT> </P><BR>
<P><FONT face=Arial size=2>4.2. Routability not guaranteed</FONT> </P>
<P><FONT face=Arial size=2> Because IPv6 is fundamentally based
upon aggregatable addresses, its</FONT> <BR><FONT face=Arial
size=2> circumstance differs from IPv4, which contains a number of
non-</FONT> <BR><FONT face=Arial size=2> provider-based
assignments for historical reasons. Nonetheless,</FONT> <BR><FONT
face=Arial size=2> registries are not responsible for routability,
which is affected by</FONT> <BR><FONT face=Arial size=2> the
technical implementation by LIRs/ISPs. RIRs must take steps,</FONT> <BR><FONT
face=Arial size=2> however, to ensure that allocations they make
will not result in</FONT> <BR><FONT face=Arial size=2> excessively
fragmented address space, as that may lead to loss of</FONT> <BR><FONT
face=Arial size=2> routability.</FONT> </P><BR>
<P><FONT face=Arial size=2>4.3. Minimum Allocation</FONT> </P>
<P><FONT face=Arial size=2> As under current IPv4 management
policies, it is proposed that IPv6</FONT> <BR><FONT face=Arial
size=2> policies establish a "minimum allocation" of address
space, which</FONT> <BR><FONT face=Arial size=2> serves to limit
the distribution by Internet Registries of portable</FONT> <BR><FONT
face=Arial size=2> address prefixes.</FONT> </P>
<P><FONT face=Arial size=2> Generally speaking, making minimum
allocation size too small leads to</FONT> <BR><FONT face=Arial
size=2> address fragmentation, and making the size too large
lowers the</FONT> <BR><FONT face=Arial size=2> efficiency of
address use. Discussion about the appropriate size of</FONT> <BR><FONT
face=Arial size=2> allocation needs to be continued in the
future. The interim policies</FONT> <BR><FONT face=Arial
size=2> adopt the following concept:</FONT> </P>
<P><FONT face=Arial size=2> First, a minimum address space (/32)
will be provided by default by</FONT> <BR><FONT face=Arial size=2>
RIR/NIR to LIRs. However, many large providers will quickly
deplete</FONT> <BR><FONT face=Arial size=2> a /32 space and need
to use more address space within a short time.</FONT> <BR><FONT face=Arial
size=2> For this reason, providers requiring space larger than a
/32 may</FONT> <BR><FONT face=Arial size=2> request more address
space, but must provide justification for such a</FONT> <BR><FONT face=Arial
size=2> request.</FONT> </P><BR>
<P><FONT face=Arial size=2>4.4. Consideration of IPv4
Infrastructure</FONT> </P>
<P><FONT face=Arial size=2> Where an existing IPv4 service
provider requests IPv6 space for</FONT> <BR><FONT face=Arial
size=2> eventual transition of existing services to IPv6, the
number of</FONT> <BR><FONT face=Arial size=2> present IPv4
customers may be used as a reason for requesting more</FONT> <BR><FONT
face=Arial size=2> space in justifying IPv6 address space
requests. This is based upon</FONT> <BR><FONT face=Arial
size=2> the implicit assumption that service providers having a
large number</FONT> <BR><FONT face=Arial size=2> of IPv4 customers
are likely to have many customers in IPv6 as well.</FONT> </P>
<P><FONT face=Arial size=2> This assumption should be evaluated
and reviewed on the next occasion</FONT> <BR><FONT face=Arial
size=2> of revising the policies.</FONT> </P><BR>
<P><FONT face=Arial size=2>5. Policies for allocations and
assignments</FONT> </P><BR>
<P><FONT face=Arial size=2>5.1. Consistency of IR address space
management policies</FONT> </P>
<P><FONT face=Arial size=2> All Internet Registries shall adopt
policies that are consistent with</FONT> <BR><FONT face=Arial
size=2> the policies formulated by the Internet community and
described in</FONT> <BR><FONT face=Arial size=2> this
document.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.2. Initial allocation</FONT> </P><BR>
<P><FONT face=Arial size=2>5.2.1. Initial allocation criteria</FONT>
</P>
<P><FONT face=Arial size=2> A requesting organization can receive
an initial allocation by</FONT> <BR><FONT face=Arial size=2>
demonstrating that it has an immediate (i.e., within next three</FONT>
<BR><FONT face=Arial size=2> months) requirement for at least a
/36 prefix. That is, immediately</FONT> <BR><FONT face=Arial
size=2> after the allocation, the organization will have 776 or
more sites in</FONT> <BR><FONT face=Arial size=2> need of address
assignments. 776 is the number of /48 address blocks</FONT> <BR><FONT
face=Arial size=2> that can be assigned out of a /36 address block
to achieve an HD-</FONT> <BR><FONT face=Arial size=2> Ratio of
0.8. The HD-Ratio is an address allocation utilization</FONT> <BR><FONT
face=Arial size=2> metric proposed in RFC 3194 as an adaptation of
the H-Ratio</FONT> <BR><FONT face=Arial size=2> originally defined
in [RFC1715]. (See also Section 5.3.3.)</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>This para now mention 3 months, but
this is too short a time to connect 776 customer sites. It is not obvious what
the new time frame should be, but it should be longer than 3
months.</FONT></P>
<P><FONT face=Arial size=2> [Note: discussion is needed as to
whether justification for need of a</FONT> <BR><FONT face=Arial
size=2> /36 is reasonable initial starting point, or whether the
criteria of</FONT> <BR><FONT face=Arial size=2> an immediate need
to address 776 sites is too high. Note also, that</FONT> <BR><FONT face=Arial
size=2> once a request for an initial allocation has been granted,
the</FONT> <BR><FONT face=Arial size=2> minimum allocation (i.e.,
/32) is provided, even though the requestor</FONT> <BR><FONT face=Arial
size=2> has not justified a need for such a large amount of
space.]</FONT> </P><BR>
<P><FONT face=Arial size=2>5.2.2. Initial allocation size</FONT> </P>
<P><FONT face=Arial size=2> A requesting organization satisfying
the initial allocation criteria</FONT> <BR><FONT face=Arial
size=2> can receive an initial allocation of the minimum /32
address block.</FONT> <BR><FONT face=Arial size=2> Any
organization requesting a larger address block may receive the</FONT>
<BR><FONT face=Arial size=2> necessary size of allocation by
submitting documentation that</FONT> <BR><FONT face=Arial size=2>
reasonably justifies the necessity. For instance, a provider or
an</FONT> <BR><FONT face=Arial size=2> enterprise currently
providing IPv4 address services may apply for</FONT> <BR><FONT face=Arial
size=2> and receive an initial allocation of the size reasonably
judged</FONT> <BR><FONT face=Arial size=2> necessary to provide
all the existing users with IPv6 services. In</FONT> <BR><FONT face=Arial
size=2> this case, the necessary size will be judged on the basis
of the</FONT> <BR><FONT face=Arial size=2> number of existing
users and infrastructure.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>Shouldn't this be that the IPv4
provider should be allocated an initial allocation for its IPv4 customers PLUS
the next 2 years growth, as in 5.3.4. Otherwise we will have the scenario
where an IP v4 provider switches to IPv6, and changes its customers over to
IPv6 and then has to go back to the RIR to request an additional block for its
new IPv6 customers. Suggest that the "2 year rule" should be applied
here also.</FONT></P>
<P><FONT face=Arial size=2> This can be represented by the
following expression:</FONT> </P>
<P><FONT face=Arial size=2> S(0) =
shorter(/32, eval(required prefix size))</FONT> </P>
<P><FONT face=Arial size=2> where (required prefix size) is the
prefix size of applicant</FONT> <BR><FONT face=Arial size=2>
requesting allocation</FONT> </P><BR>
<P><FONT face=Arial size=2>5.3. Subsequent allocation</FONT> </P>
<P><FONT face=Arial size=2> An organization (ISP/LIR) that has
already received an address block</FONT> <BR><FONT face=Arial
size=2> from an RIR/NIR may receive a subsequent allocation in
accordance</FONT> <BR><FONT face=Arial size=2> with the following
policies.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.3.1. Subsequent allocation criteria</FONT>
</P>
<P><FONT face=Arial size=2> Subsequent allocation will be provided
when an organization (ISP/LIR)</FONT> <BR><FONT face=Arial size=2>
satisfies the evaluation threshold of past address utilization in</FONT>
<BR><FONT face=Arial size=2> terms of the number of sites in units
of /48 assignments. The HD-</FONT> <BR><FONT face=Arial
size=2> Ratio is used to assess the utilization of the existing
address block</FONT> <BR><FONT face=Arial size=2> as described
below.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.3.2. Utilization Metric</FONT> </P>
<P><FONT face=Arial size=2> In general, HD-Ratio [RFC3194] is
expressed as follows:</FONT> <BR><FONT face=Arial
size=2>
Log (number of allocated objects)</FONT> <BR><FONT face=Arial
size=2>
HD = ------------------------------------------------</FONT> <BR><FONT
face=Arial
size=2>
Log (maximum number of allocatable objects)</FONT> <BR><FONT face=Arial
size=2> where the objects are IPv6 site addresses (/48s) assigned
from an</FONT> <BR><FONT face=Arial size=2> IPv6 prefix of length
P.</FONT> </P>
<P><FONT face=Arial size=2> The utilization threshold T, expressed
as a number of individual /48</FONT> <BR><FONT face=Arial size=2>
prefixes to be allocated from IPv6 prefix P, can be calculated as:</FONT>
<BR><FONT face=Arial
size=2>
((48-P)*HD)</FONT> <BR><FONT face=Arial
size=2>
T = 2</FONT> <BR><FONT face=Arial size=2> Thus, the
utilization threshold for an organization requesting</FONT> <BR><FONT
face=Arial size=2> subsequent allocation of IPv6 address block is
specified as a</FONT> <BR><FONT face=Arial size=2> function of the
prefix size and target HD ratio. This utilization</FONT> <BR><FONT face=Arial
size=2> refers to the allocation of /48s to end sites, and not
the</FONT> <BR><FONT face=Arial size=2> utilization of those /48s
within those end sites. It is an address</FONT> <BR><FONT face=Arial
size=2> allocation utilization ratio and not an address
assignment</FONT> <BR><FONT face=Arial size=2> utilization
ratio.</FONT> </P>
<P><FONT face=Arial size=2>5.3.3. Applied HD-Ratio</FONT> </P>
<P><FONT face=Arial size=2> A desirable HD-Ratio for evaluation is
thought to lie between 0.80</FONT> <BR><FONT face=Arial size=2>
and 0.85, with the actual value needing to be determined as</FONT> <BR><FONT
face=Arial size=2> experience is gathered from implementation of
this policy. An HD-</FONT> <BR><FONT face=Arial size=2>
ratio of 0.8 is adopted for this interim policy. The value may change</FONT>
<BR><FONT face=Arial size=2> in response to implementation
experience.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.3.4. Subsequent Allocation Size</FONT> </P>
<P><FONT face=Arial size=2> The size of an "n"-th time subsequent
allocation S(n) is found as:</FONT> </P>
<P><FONT face=Arial
size=2> S(n) =
shorter(S(n-1)-1, eval(two_years_req))</FONT> <BR><FONT face=Arial
size=2> where S(n-1)-1 represents one bit shorter prefix address
block size</FONT> <BR><FONT face=Arial size=2> of the previous
allocated address block size, and eval(two_years_req)</FONT> <BR><FONT
face=Arial size=2> represents the evaluation of two-year demands
of the requesting</FONT> <BR><FONT face=Arial size=2>
organization.</FONT> </P>
<P><FONT face=Arial size=2> In other words, an organization
(ISP/LIR) satisfying the criteria can</FONT> <BR><FONT face=Arial
size=2> receive at least one bit shorter prefix
automatically.</FONT> </P>
<P><FONT face=Arial size=2> If an organization needs more address
space, it needs to demonstrate</FONT> <BR><FONT face=Arial size=2>
its two-year demand to an RIR/NIR. Then, the RIR/NIR evaluates it and</FONT>
<BR><FONT face=Arial size=2> allocates the address prefix enough
to satisfy its two-year</FONT> <BR><FONT face=Arial size=2>
requirements.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.4. LIR-to-ISP allocation</FONT> </P>
<P><FONT face=Arial size=2> There is no specific policy for an
organization (ISP/LIR) to allocate</FONT> <BR><FONT face=Arial
size=2> address space to subordinate ISPs. Each LIR
organization may develop</FONT> <BR><FONT face=Arial size=2> its
own policy for subordinate ISPs to encourage optimum utilization</FONT>
<BR><FONT face=Arial size=2> of the total address block allocated
to the LIR. However, the LIR is</FONT> <BR><FONT face=Arial
size=2> required to keep track of all /48s assignments, including
assignments</FONT> <BR><FONT face=Arial size=2> made by its
subordinate ISPs to end users, and report the assignment</FONT> <BR><FONT
face=Arial size=2> status to RIR/NIR so that the HD-Ratio can be
evaluated when a</FONT> <BR><FONT face=Arial size=2> subsequent
allocation becomes necessary.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>Here the text implies that the LIR
should keep track of all subordinate allocations, which means that if an LIR
allocates a block to a subordinate ISP then the LIR needs to keep track of all
the /48s that the subordinate ISP allocates to its own customers. Then,
when the LIR requests a larger allocation, that same LIR needs to report these
allocations to RIR/NIR so that the RIR/NIR can then calculate the subsequent
allocation. However, earlier in "3.3. Registration" it says that
"Every assignment and allocation of Internet address space must be registered
in a public registry database accessible to all members of the Internet
community"</FONT></P>
<P><FONT face=Arial color=#000080 size=2>It also talks about registration in
5.6 see below.</FONT> <BR><FONT face=Arial color=#000080 size=2>This
registration question needs clarifying - the document contradicts
itself.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>Currently in IPv4, addresses are
registered in either a public database or in the LIR's own database, thus
allowing a mixture. Thus, if we need to keep our customer information private,
we can keep it "off" a public database, but if the customer does want to be
seen in the public database then we can enter it. Suggest the same
principle needs to be applied to IPv6.</FONT></P>
<P><FONT face=Arial size=2>5.5. Assignment</FONT> </P>
<P><FONT face=Arial size=2> This section describes the assignment
policy.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.5.1. Assignment address space size</FONT>
</P>
<P><FONT face=Arial size=2> Address space following the 64th bit
is the IETF boundary [RFC2460].</FONT> <BR><FONT face=Arial
size=2> Address space following the 48th bit is a policy boundary,
with IETF</FONT> <BR><FONT face=Arial size=2> recommendations
[RFC3177] and RIR agreement [RIRs-on-48] recommending</FONT> <BR><FONT
face=Arial size=2> the assignment of:</FONT> </P>
<P><FONT face=Arial size=2> - /48 in the general case,
except for very large subscribers</FONT> <BR><FONT face=Arial
size=2> - /64 when it is known that one and only one subnet
is needed by</FONT> <BR><FONT face=Arial size=2>
design</FONT> <BR><FONT face=Arial size=2> - /128 when it is
absolutely known that one and only one device is</FONT> <BR><FONT face=Arial
size=2> connecting.</FONT> </P>
<P><FONT face=Arial size=2> RIRs/NIRs are not concerned about
which address size an LIR/ISP</FONT> <BR><FONT face=Arial size=2>
actually assigns. Accordingly, RIRs/NIRs will not request the</FONT>
<BR><FONT face=Arial size=2> detailed information on user networks
as they did in IPv4, except for</FONT> <BR><FONT face=Arial
size=2> the cases described in Section 4.4. and for the purposes
of measuring</FONT> <BR><FONT face=Arial size=2> utilization as
defined in this document.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.5.2. Assignment to a site</FONT> </P><BR>
<P><FONT face=Arial size=2>5.5.3. Assignment of multiple /48s to a
single site</FONT> </P>
<P><FONT face=Arial size=2> When a single site requires an
additional /48 address block, it can</FONT> <BR><FONT face=Arial
size=2> request the assignment with documentation or materials
that justify</FONT> <BR><FONT face=Arial size=2> the
request. Requests for multiple or additional /48s will be</FONT>
<BR><FONT face=Arial size=2> processed and reviewed (i.e.,
evaluation of justification) at the</FONT> <BR><FONT face=Arial
size=2> RIR/NIR level.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.5.4. Assignment to operator's
infrastructure</FONT> </P>
<P><FONT face=Arial size=2> An organization (ISP/LIR) may assign a
/48 per PoP as the service</FONT> <BR><FONT face=Arial size=2>
infrastructure of an IPv6 service operator. Each assignment to a
PoP</FONT> <BR><FONT face=Arial size=2> is regarded as one
assignment regardless of the number of users using</FONT> <BR><FONT face=Arial
size=2> the PoP. On the other hand, a separate assignment
can be obtained</FONT> <BR><FONT face=Arial size=2> for the
in-house operations of the operator.</FONT> </P>
<P><FONT face=Arial size=2>5.6. DB registration</FONT> </P>
<P><FONT face=Arial size=2> When an organization in reciept of an
IPv6 address allocation makes</FONT> <BR><FONT face=Arial size=2>
IPv6 address assignments, it must register assignment information in</FONT>
<BR><FONT face=Arial size=2> a public database (initially a
database maintained by an RIR/NIR,</FONT> <BR><FONT face=Arial
size=2> which may be replaced by a distributed database for
registering</FONT> <BR><FONT face=Arial size=2> address management
information in future). Information is registered</FONT> <BR><FONT
face=Arial size=2> in units of assigned /48 networks. When
an organization assigns an</FONT> <BR><FONT face=Arial size=2>
address space larger than a /48 to another organization, it must</FONT>
<BR><FONT face=Arial size=2> monitor if this organization has
registered address utilization</FONT> <BR><FONT face=Arial size=2>
information in a public database.</FONT> </P>
<P><FONT face=Arial color=#000080 size=2>This para talks about an organization
(LIR) assigning an address space larger than a /48 to another
organization. In this case it implies that the other organization (NOT
THE LIR) must register its /48's in a public database and that the LIR must
ensure that the other organization has done this. But section 3.3
implies that every allocation be an a public database, and section 5.4 implies
that it is not.</FONT></P>
<P><FONT face=Arial size=2> RIR/NIRs will use registered data to
calculate the HD-Ratio at the</FONT> <BR><FONT face=Arial size=2>
time of application for subsequent allocation and to check for</FONT>
<BR><FONT face=Arial size=2> changes in assignments over
time.</FONT> </P>
<P><FONT face=Arial size=2> Each registry shall handle personal
information with ultimate care.</FONT> <BR><FONT face=Arial
size=2> Concrete methods of protecting personal data shall be in
accordance</FONT> <BR><FONT face=Arial size=2> with privacy
policies of each RIR/NIR (e.g., assign providers as</FONT> <BR><FONT
face=Arial size=2> tech-c or admin-c, divide an address in the
middle, etc.).</FONT> </P><BR>
<P><FONT face=Arial size=2>5.7. Reverse lookup</FONT> </P>
<P><FONT face=Arial size=2> When an RIR/NIR delegates IPv6 address
space to an organization, it</FONT> <BR><FONT face=Arial size=2>
also delegates the right to manage the reverse lookup zone that</FONT>
<BR><FONT face=Arial size=2> corresponds to the allocated IPv6
address space. Each organization</FONT> <BR><FONT face=Arial
size=2> should properly manage its reverse lookup zone. When
making an</FONT> <BR><FONT face=Arial size=2> address assignment,
the organization must delegate to an assigned</FONT> <BR><FONT face=Arial
size=2> organization, upon request, the right to manage the
reverse lookup</FONT> <BR><FONT face=Arial size=2> zone that
corresponds to the assigned address.</FONT> </P><BR>
<P><FONT face=Arial size=2>5.8. Validity of allocations and
assignments</FONT> </P>
<P><FONT face=Arial size=2> An allocation or assignment of address
space is valid only so long as</FONT> <BR><FONT face=Arial size=2>
the original criteria on which the allocation or assignment was based</FONT>
<BR><FONT face=Arial size=2> continues to be valid.</FONT> </P>
<P><FONT face=Arial size=2> If an allocation or assignment is made
for a specific purpose, but</FONT> <BR><FONT face=Arial size=2>
the original purpose or original justification no longer applies, the</FONT>
<BR><FONT face=Arial size=2> allocation or assignment shall become
invalid.</FONT> </P>
<P><FONT face=Arial size=2> If an allocation or assignment is
based on information that is found</FONT> <BR><FONT face=Arial
size=2> to be false or incomplete, the allocation or assignment
shall become</FONT> <BR><FONT face=Arial size=2> invalid.</FONT>
</P>
<P><FONT face=Arial size=2> Invalid allocations shall be returned
to the appropriate IR.</FONT> </P>
<P><FONT face=Arial size=2>5.9. Existing IPv6 address space
holders</FONT> </P>
<P><FONT face=Arial size=2> Once the policies described in this
document have been adopted, an</FONT> <BR><FONT face=Arial size=2>
organization already receiving an allocation according to the</FONT> <BR><FONT
face=Arial size=2> "PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION
POLICY DOCUMENT"</FONT> <BR><FONT face=Arial size=2>
[RIRv6-Polices] is immediately eligible to having its allocation</FONT>
<BR><FONT face=Arial size=2> expanded to a /32 address block. The
/32 address block will contain</FONT> <BR><FONT face=Arial size=2>
the already allocated smaller address block (one or multiple /35</FONT>
<BR><FONT face=Arial size=2> address blocks in many cases) that
was already reserved by the RIR</FONT> <BR><FONT face=Arial
size=2> for a subsequent allocation to the organization. Requests
for</FONT> <BR><FONT face=Arial size=2> additional space beyond
the minimum /32 size will be evaluated as</FONT> <BR><FONT face=Arial
size=2> discussed elsewhere in the document.</FONT> </P><BR>
<P><FONT face=Arial size=2>6. Special case</FONT> </P>
<P><FONT face=Arial size=2> Special considerations will be given
to the cases described below,</FONT> <BR><FONT face=Arial size=2>
with no regard to the provision of this document. Individual RIRs are</FONT>
<BR><FONT face=Arial size=2> currently discussing policies for
these cases independent of this</FONT> <BR><FONT face=Arial
size=2> document.</FONT> </P><BR>
<P><FONT face=Arial size=2>6.1. IX (Internet Exchange)</FONT> </P>
<P><FONT face=Arial size=2> An IX is a point at which ISPs connect
with one another. It requires</FONT> <BR><FONT face=Arial
size=2> ISP-independent addresses.</FONT> </P><BR>
<P><FONT face=Arial size=2>7. Acknowledgment</FONT> </P>
<P><FONT face=Arial size=2> The initial version of this document
was produced by The JPNIC IPv6</FONT> <BR><FONT face=Arial size=2>
global policy drafting team consisting of Akihiro Inomata, Akinori</FONT>
<BR><FONT face=Arial size=2> Maemura, Kosuke Ito, Kuniaki Kondo,
Takashi Arano, Tomohiro Fujisaki,</FONT> <BR><FONT face=Arial
size=2> and Toshiyuki Yamasaki. Special thanks goes out to this
team, who</FONT> <BR><FONT face=Arial size=2> worked over a
holiday in order to produce an initial document</FONT> <BR><FONT face=Arial
size=2> quickly.</FONT> </P>
<P><FONT face=Arial size=2> An editing team was then organized by
representatives from each of</FONT> <BR><FONT face=Arial size=2>
the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas</FONT>
<BR><FONT face=Arial size=2> Narten, Chair of ARIN's IPv6 WG, and
David Kessens, Chair of RIPE-</FONT> <BR><FONT face=Arial size=2>
NCC's IPv6 WG).</FONT> </P>
<P><FONT face=Arial size=2> The editing team would like to
acknowledge the contributions to this</FONT> <BR><FONT face=Arial
size=2> document of Takashi Arano, John Crain, Steve Deering,
Kosuke Ito,</FONT> <BR><FONT face=Arial size=2> Richard Jimmerson,
David Kessens, Mirjam Kuehne, Anne Lord, Jun</FONT> <BR><FONT face=Arial
size=2> Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Paul Wilson
and</FONT> <BR><FONT face=Arial size=2> Wilfried Woeber.</FONT>
</P>
<P><FONT face=Arial size=2>8. References</FONT> </P>
<P><FONT face=Arial size=2> [RFC1715] "The H Ratio for Address
Assignment Efficiency", C.</FONT> <BR><FONT face=Arial
size=2>
Huitema.</FONT> <BR><FONT face=Arial
size=2>
November 1994, RFC 1715.</FONT> </P>
<P><FONT face=Arial size=2> [RFC1771] "A Border Gateway Protocol 4
(BGP-4)", Y. Rekhter, T. Li.</FONT> <BR><FONT face=Arial
size=2>
March</FONT> <BR><FONT face=Arial
size=2>
1995, RFC 1771.</FONT> </P>
<P><FONT face=Arial size=2> [IAB-Request] "Email from IAB to
IANA", [XXX need better reference].</FONT> <BR><FONT face=Arial
size=2> See IAB
Minutes, Dec. 12, 1998,</FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A href="ftp://ftp.iab.org/in"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>ftp://ftp.iab.org/in</FONT></U><U></U></A><U><FONT face=Arial
color=#0000ff size=2>></FONT></U><FONT face=Arial size=2>-</FONT> <BR><FONT
face=Arial size=2>
notes/IAB/IABmins/IABmins.981208,</FONT><U> <FONT face=Arial color=#0000ff
size=2><</FONT></U><A href="ftp://ftp.iab.org/in"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>ftp://ftp.iab.org/in</FONT></U><U></U></A><U><FONT face=Arial
color=#0000ff size=2>></FONT></U><FONT face=Arial size=2>-</FONT> <BR><FONT
face=Arial size=2>
notes/IAB/IABmins/IABmins.990112.</FONT> </P>
<P><FONT face=Arial size=2> [RFC2373] "IP Version 6 Addressing
Architecture", R. Hinden, S.</FONT> <BR><FONT face=Arial
size=2> Deering.
July 1998, RFC 2373.</FONT> </P>
<P><FONT face=Arial size=2> [RFC2373bis]
draft-ietf-ipngwg-addr-arch-v3-07.txt.</FONT> </P>
<P><FONT face=Arial size=2> [RFC2460] "Internet Protocol, Version
6 (IPv6) Specification", S.</FONT> <BR><FONT face=Arial
size=2> Deering,
R. Hinden. December 1998, RFC 2460.</FONT> </P>
<P><FONT face=Arial size=2> [RFC2780] "IP Version 6 Addressing
Architecture", R. Hinden, S.</FONT> <BR><FONT face=Arial
size=2> Deering.
July 1998. RFC 2373.</FONT> </P>
<P><FONT face=Arial size=2> [RFC2928] "Initial IPv6 Sub-TLA ID
Assignments", R. Hinden, S.</FONT> <BR><FONT face=Arial
size=2> Deering,
R. Fink, T. Hain. September 2000, RFC 2928.</FONT> </P>
<P><FONT face=Arial size=2> [RFC3177] "IAB/IESG Recommendations on
IPv6 Address". IAB, IESG.</FONT> <BR><FONT face=Arial
size=2> September
2001, RFC 3177.</FONT> </P><BR>
<P><FONT face=Arial size=2> [RFC3194] "The H-Density Ratio for
Address Assignment Efficiency An</FONT> <BR><FONT face=Arial
size=2> Update on
the H ratio", A. Durand, C. Huitema. November 2001,</FONT> <BR><FONT
face=Arial size=2>
RFC 3194.</FONT> </P>
<P><FONT face=Arial size=2> [RIRs-on-48]</FONT><U> <FONT
face=Arial color=#0000ff size=2><</FONT></U><A
href="http://www.arin.net/minutes/bot/bot08152001.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.arin.net/minutes/bot/bot08152001.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U><FONT face=Arial size=2>,
XXX</FONT> <BR><FONT face=Arial
size=2> fill
in.</FONT> </P>
<P><FONT face=Arial size=2> [RIRv6-Policies]</FONT> <BR><FONT
face=Arial
size=2> </FONT><U>
<FONT face=Arial color=#0000ff size=2><</FONT></U><A
href="http://www.arin.net/regserv/ipv6/ipv6guidelines.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.arin.net/regserv/ipv6/ipv6guidelines.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U><FONT face=Arial
size=2>,</FONT> <BR><FONT face=Arial
size=2> </FONT><U>
<FONT face=Arial color=#0000ff size=2><</FONT></U><A
href="http://www.ripe.net/ripe/docs/ripe-196.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.ripe.net/ripe/docs/ripe-196.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U><FONT face=Arial
size=2>,</FONT> <BR><FONT face=Arial
size=2> </FONT><U>
<FONT face=Arial color=#0000ff size=2><</FONT></U><A
href="http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html"><U></U><U></U><U><FONT
face=Arial color=#0000ff
size=2>http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html</FONT></U><U></U></A><U><FONT
face=Arial color=#0000ff size=2>></FONT></U><FONT face=Arial
size=2>.</FONT> </P>
<P><FONT face=Arial size=2>9. Appendix A:</FONT> </P>
<P><FONT face=Arial size=2> In accordance with the recommendations
of "The Host-Density Ratio for</FONT> <BR><FONT face=Arial size=2>
Address Assignment Efficiency: An update on the H ratio" [RFC 3194],</FONT>
<BR><FONT face=Arial size=2> it is proposed in this draft to adopt
an HD-Ratio of 0.8 as the</FONT> <BR><FONT face=Arial size=2>
utilization threshold for IPv6 address space allocations.</FONT> </P>
<P><FONT face=Arial size=2> The following table provides
equivalent absolute and percentage</FONT> <BR><FONT face=Arial
size=2> address utilization figures for IPv6 prefixes,
corresponding to an</FONT> <BR><FONT face=Arial size=2> HD-Ratio
of 0.8</FONT> </P>
<P><FONT face=Arial size=2>
P 48-P
Total /48s
Threshold Util%</FONT> </P>
<P><FONT face=Arial size=2>
48
0
1
1 100.0%</FONT> <BR><FONT face=Arial
size=2>
47
1
2
2 87.1%</FONT> <BR><FONT face=Arial
size=2>
46
2
4
3 75.8%</FONT> <BR><FONT face=Arial
size=2>
45
3
8
5 66.0%</FONT> <BR><FONT face=Arial
size=2>
44
4
16
9 57.4%</FONT> <BR><FONT face=Arial
size=2>
43
5
32
16 50.0%</FONT> <BR><FONT face=Arial
size=2>
42
6
64
28 43.5%</FONT> <BR><FONT face=Arial
size=2>
41
7
128
49 37.9%</FONT> <BR><FONT face=Arial
size=2>
40
8
256
84 33.0%</FONT> <BR><FONT face=Arial
size=2>
39
9
512
147 28.7%</FONT> <BR><FONT face=Arial
size=2> 38
10
1024
256 25.0%</FONT> <BR><FONT face=Arial
size=2> 37
11
2048
446 21.8%</FONT> <BR><FONT face=Arial
size=2> 36
12
4096
776 18.9%</FONT> <BR><FONT face=Arial
size=2> 35
13
8192
1351 16.5%</FONT> <BR><FONT face=Arial
size=2> 34
14
16384
2353 14.4%</FONT> <BR><FONT face=Arial
size=2> 33
15
32768
4096 12.5%</FONT> <BR><FONT face=Arial
size=2> 32
16
65536
7132 10.9%</FONT> <BR><FONT face=Arial
size=2> 31
17
131072
12417 9.5%</FONT> <BR><FONT face=Arial
size=2> 30
18
262144
21619 8.2%</FONT> <BR><FONT face=Arial
size=2> 29
19
524288
37641 7.2%</FONT> <BR><FONT face=Arial
size=2> 28
20
1048576
65536 6.3%</FONT> <BR><FONT face=Arial
size=2> 27
21
2097152
114105 5.4%</FONT> <BR><FONT face=Arial
size=2> 26
22
4194304
198668 4.7%</FONT> <BR><FONT face=Arial
size=2> 25
23
8388608
345901 4.1%</FONT> <BR><FONT face=Arial
size=2> 24
24
16777216
602249 3.6%</FONT> <BR><FONT face=Arial
size=2> 23
25
33554432
1048576 3.1%</FONT> <BR><FONT face=Arial
size=2> 22
26
67108864
1825677 2.7%</FONT> <BR><FONT face=Arial
size=2> 21
27
134217728
3178688 2.4%</FONT> <BR><FONT face=Arial
size=2> 20
28
268435456
5534417 2.1%</FONT> <BR><FONT face=Arial
size=2> 19
29
536870912
9635980 1.8%</FONT> <BR><FONT face=Arial
size=2> 18
30
1073741824
16777216 1.6%</FONT> <BR><FONT face=Arial
size=2> 17
31
2147483648
29210830 1.4%</FONT> <BR><FONT face=Arial
size=2> 16
32
4294967296
50859008 1.2%</FONT> <BR><FONT face=Arial
size=2> 15
33
8589934592
88550677 1.0%</FONT> <BR><FONT face=Arial
size=2> 14
34
17179869184
154175683 0.9%</FONT> <BR><FONT face=Arial
size=2> 13
35
34359738368
268435456 0.8%</FONT> <BR><FONT face=Arial
size=2> 12
36
68719476736
467373275 0.7%</FONT> <BR><FONT face=Arial
size=2> 11
37
137438953472
813744135 0.6%</FONT> <BR><FONT face=Arial
size=2> 10
38
274877906944
1416810831 0.5%</FONT> <BR><FONT
face=Arial size=2>
9
39
549755813888
2466810934 0.4%</FONT> <BR><FONT
face=Arial size=2>
8 40
1099511627776
4294967296 0.4%</FONT> <BR><FONT
face=Arial size=2>
7 41
2199023255552
7477972398 0.3%</FONT> <BR><FONT
face=Arial size=2>
6 42
4398046511104
13019906166 0.3%</FONT> <BR><FONT
face=Arial size=2>
5 43
8796093022208
22668973294 0.3%</FONT> <BR><FONT
face=Arial size=2>
4 44
17592186044416
39468974941 0.2%</FONT> </P>
<P><FONT face=Arial
size=2>DRAFT
[Page 20]</FONT> </P><BR><BR></UL></BODY></HTML>