<!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>