Internet DRAFT - draft-hain-prefix-consider

draft-hain-prefix-consider



                                                                       
        Internet Draft                                               T. Hain 
        Document: draft-hain-prefix-consider-00.txt                    Cisco 
        Expires: September 2005                                   April 2005 
         
         
                 Considerations for prefix length assignments in the  
                            Global Unicast Address Format 
      
     Status of this Memo 
      
        This document is an Internet-Draft and is in full conformance with 
        all provisions of Section 10 of RFC2026 [1].  
         
        Internet-Drafts are working documents of the Internet Engineering 
        Task Force (IETF), its areas, and its working groups.  Note that      
        other groups may also distribute working documents as Internet-
        Drafts. 
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other documents 
        at any time.  It is inappropriate to use Internet-Drafts as 
        reference material or to cite them other than as "work in progress." 
         
        The list of current Internet-Drafts can be accessed at 
             http://www.ietf.org/ietf/1id-abstracts.txt 
        The list of Internet-Draft Shadow Directories can be accessed at 
             http://www.ietf.org/shadow.html. 
         
     IPR Statement 
        "By submitting this Internet-Draft, each author represents that any 
        applicable patent or other IPR claims of which he or she is aware 
        have been or will be disclosed, and any of which he or she becomes 
        aware will be disclosed, in accordance with Section 6 of BCP 79." 
        (See RFC 3978[RFC3978] section 5.1.)  
        All Internet-Drafts must include the following statements near the 
        end of the document:  
        "Copyright (C) The Internet Society (2005).  
         
        This document is subject to the rights, licenses and restrictions 
        contained in BCP 78, and except as set forth therein, the authors 
        retain all their rights."  
         
        "This document and the information contained herein are provided on 
        an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
        REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
        INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
        IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
        THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
         
     Abstract 
         

       
     Hain                    Expires - October 2005                       1 
                                                                             
                  Considerations for prefix length assignments   April 2005 
                      in the Global Unicast Address Format 
      
        This document discusses the issues that should be considered by 
        service providers as they assign address space to customers. It is 
        informational in nature as allocation policies are developed 
        elsewhere. 
         
     Conventions used in this document 
         
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
        "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
        this document are to be interpreted as described in RFC-2119 [2]. 










































          
     Hain                    Expires - October 2005                       2 
                                                                             
                  Considerations for prefix length assignments   April 2005 
                      in the Global Unicast Address Format 
      
      
     Introduction 
         
        Several service providers have expressed concern that a single 
        policy of always allocating a ::/48 to a site is both ambiguous and 
        constraining on their business practice. First the definition of 
        'site' leaves open the question of is this a customer, a customer 
        campus, or a single building (to some degree that language is 
        intentionally ambiguous to allow for any of the above without being 
        restrictive). Then the apparent single value for all customers 
        removes their ability to differentiate levels of service through the 
        amount of address space provided.  
         
      
     History 
         
        The single prefix length policy recommendation was specifically 
        targeted to counter the IPv4 practice of assigning a single address 
        and/or charging customers per active address. Extreme conservation 
        embodied in per address charging is naturally countered by consumers 
        through the use of NAT technologies to conform to the restriction on 
        one hand while achieving their real goal on the other. Since NAT 
        devices introduce an impediment to new application deployment, 
        and/or require operationally complex helper technologies, the 
        community developing IPv6 wanted to ensure that all the effort to 
        provide sufficient address space to remove the need for NAT was not 
        undermined by misguided business practices. While the global policy 
        does allow for the assignment of ::/128 values, this is expected to 
        be rare as the service provider will never know if the receiving 
        device is really a router meaning it should have handed out a 
        minimum of a subnet prefix.  
         
        The ::/48 value was selected in recognition that larger 
        organizations would need a sufficient number of bits for local 
        subnet management, coupled with the realization that even if they 
        were handed out to individuals there would be enough to provide 
        multiple ::/48 prefixes to every person projected to be alive in 
        2050. The intense focus on conservation that has developed among the 
        service providers for managing IPv4 can't seem to adjust to the 
        reality that there are and will be enough ::/48's to cover the need.  
         
     Technical issues to consider 
         
        While any length prefix may be assigned, there are technical reasons 
        to restrict the set. Consistent management oversight of the forward 
        address space assignments and the reverse DNS tree suggest that all 
        assignments should be on nibble boundaries. Choosing other than 
        nibble boundaries ensures that multiple organizations will need to 
        manage the affected DNS reverse zone. 
         
        Assigning individual ::/64 subnet prefixes is likely to lead to 
        discontiguous assignments over time (even in the initial discussions 
          
     Hain                    Expires - October 2005                       3 
                                                                             
                  Considerations for prefix length assignments   April 2005 
                      in the Global Unicast Address Format 
      
        about DOCSIS 3.0 it was clear that multiple subnets per customer 
        were likely due to the differing media types involved). Aggregation 
        per customer simplifies several management issues, so planning ahead 
        by avoiding individual ::/64 prefix assignments will minimize future 
        renumbering.  
          
     Recommendation 
         
        Allocating on nibble boundaries would lead to the choices of ::/48, 
        ::/52, ::/56, ::/60, and ::/64. Future proofing by avoiding the 
        assignment of individual ::/64's would take that off the list. Very 
        large global enterprises are likely to acquire substantial multiples 
        of ::/48 prefixes so they are not a real concern here. For those 
        service providers that believe they absolutely need to differentiate 
        levels of service through address space this leads to a 
        recommendation of: 
        Large businesses            ->      ::/48 
        Medium businesses           ->      ::/52 
        Small business/home office  ->      ::/56 
        Commodity consumer          ->      ::/60 
         
         
     RIR Considerations 
         
        Future versions of the global IPv6 allocation policy could soften 
        the wording around recommended prefix lengths, but really should 
        include the technical discussion about reverse zone alignment.  
         
     Security Considerations 
      
        There are no security issues discussed in this informational 
        document. 
         
     RFC Editor Considerations 
         
        This space left intentionally blank.  
         
     IANA Considerations 
         
        This space left intentionally blank.  
         
         
     Acknowledgments 
        Discussion of these issues have occurred over time at many venues, 
        and unfortunately I don't recall everyone involved.  
         
     Author's Addresses 
        Tony Hain 
        Cisco Systems 
        500 108th Ave. N.E. Suite 400 
        Bellevue, Wa. 98004 
        Email: alh-ietf@tndh.net 
          
     Hain                    Expires - October 2005                       4 
                                                                             
                  Considerations for prefix length assignments   April 2005 
                      in the Global Unicast Address Format 
      
         
     References 
    
 
   1  RFC-2026,  Bradner, S., "The Internet Standards Process -- 
      Revision 3", BCP 9, RFC 2026, October 1996. 
    
   2  RFC-2119,  Bradner, S., "Key words for use in RFCs to Indicate 
      Requirement Levels", BCP 14, RFC 2119, March 1997 
      
    









































          
     Hain                    Expires - October 2005                       5