<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2712.300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=722300123-15012002><FONT face=Arial color=#0000ff size=2>Dear
Stuart,</FONT></SPAN></DIV>
<DIV><SPAN class=722300123-15012002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=722300123-15012002><FONT face=Arial color=#0000ff size=2>You
appear to be the only one with this problem. I have been receiving mail
from this list with no problem. Are you using the correct email for
posting?</FONT></SPAN></DIV>
<DIV><SPAN class=722300123-15012002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=722300123-15012002><FONT face=Arial color=#0000ff
size=2>Ray</FONT></SPAN></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
owner-ipv6-wg@ripe.net [mailto:owner-ipv6-wg@ripe.net] <B>On Behalf Of
</B>Stuart Prevost<BR><B>Sent:</B> Tuesday, January 15, 2002 4:08
AM<BR><B>To:</B> lir-wg@ripe.net; ipv6-wg@ripe.net<BR><B>Subject:</B> Fw:
[GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global
Policy<BR><BR></FONT></DIV>
<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></BLOCKQUOTE></BODY></HTML>