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