[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 3177) 00 01 02 03 04 05 draft-ietf-v6ops-3177bis-end-sites

INTERNET-DRAFT                                             Thomas Narten
                                                                     IBM
<draft-narten-ipv6-3177bis-48boundary-01.txt>               Geoff Huston
                                                                   APNIC
                                                             Lea Roberts
                                                     Stanford University
                                                           March 6, 2006

                   IPv6 Address Allocation to End Sites

               <draft-narten-ipv6-3177bis-48boundary-01.txt>


Status of this Memo

   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.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft expires in six months.


Abstract

   RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
   in most cases. The Regional Internet Registries (RIRs) adopted those
   recommendations in 2002 and they have been in effect ever since.
   This document revisits and updates the IAB/IESG recommendations on
   the assignment of IPv6 address space to end sites.  The exact choice
   of how much address space to assign end sites is a policy issue under
   the purview of the RIRs, subject to IPv6 architectural



draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 1]

INTERNET-DRAFT                                             March 6, 2006


   considerations. This document reviews those architectural
   considerations and reiterates that changing the /48 recommendation is
   one of policy, and has minimal impact on the IPv6 architecture and on
   IETF Standards.

   This document obsoletes RFC 3177 and reclassifies it as historic.

   Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    2

   2.  On /48 Assignments to End Sites..........................    3

   3.  Other RFC 3177 considerations............................    4

   4.  Impact on IPv6 Standards.................................    4
      4.1.  RFC3056: Connection of IPv6 Domains via IPv4 Clouds.    4
      4.2.  IPv6 Multicast Addressing...........................    4

   5.  Security Considerations..................................    5

   6.  IANA Considerations......................................    5

   7.  Acknowledgments..........................................    5

   8.  Normative References.....................................    5

   9.  Informative References...................................    5

   10.  Author's Address......................................    6


1.  Introduction

   RFC 3177 [RFC3177] called for a default end site IPv6 assignment size
   of /48. Subsequently, the RIRs developed and adopted IPv6 address
   assignment and allocation policies consistent with the RFC 3177
   recommendations [RIR-IPV6]. Additional history and discussion of IPv6
   address policy and its long-term implications can be found in
   [IPV6-HISTORY].

   This document performs two functions:

     1) It revisits the RFC 3177 recommendations and concludes that the
        default IPv6 assignment size could be changed from /48 to some
        other value (e.g., /56) with essentially no impact on existing



draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 2]

INTERNET-DRAFT                                             March 6, 2006


        IPv6 standards or implementations.

     2) It obsoletes RFC 3177 and reclassifies it historic.


2.  On /48 Assignments to End Sites

   Looking back at some of the original motivations behind the /48
   recommendation [RFC 3177], one overriding concern was to ensure that
   end sites could easily obtain sufficient address space without having
   to "jump through hoops" to do so. For example, if someone felt they
   needed more space, just the act of asking would at some level be
   sufficient justification.  As a comparison point, in IPv4, typical
   home users are given a single public IP address (though even this is
   not always assured), but getting any more than one address is
   typically significantly more expensive either in terms of the
   justification effort needed to obtain additional addresses, or in the
   actual monthly service cost. (It should be noted that an end-user
   additional "cost" for obtaining more than one address is difficult to
   justify by the actual effective per-address cost charged by the RIRs,
   but providing additional addresses is frequently only available as
   part of a different type or "higher grade" of service, for which an
   additional charge is levied.)  Thus, an important goal in IPv6 is to
   significantly change the default and minimal end site assignment,
   from "a single address" to "multiple networks".

   In IPv6, a site may have multiple prefixes in use, including multiple
   public prefixes from ISPs and site local addresses [SITE-LOCAL].
   Thus, another concern is that managing the addressing plan for a site
   is simplified if the same subnet numbering scheme can be used for all
   prefixes. In particular, renumbering from a larger set of "subnet
   bits" into a smaller set is particularly painful, as it it can
   require making changes to the network itself (e.g., collapsing
   links). In contrast, renumbering a site into a prefix that has the
   same number (or more) of subnet bits is more straightforward, because
   only the top-level bits of the address need to change. Thus, another
   goal of the RFC 3177 recommendation is to ensure that upon
   renumbering, one does not have to deal with renumbering into a
   smaller subnet size.

   It should be noted that similar arguments apply to the management of
   zone files in the DNS. In particular, managing the reverse (ip6.arpa)
   tree is simplified when all links are numbered using the same subnet
   ids.

   The above concerns were met by the original /48 recommendation, but
   could also be realized through a more conservative approach. A key
   goal, however, is to avoid the need for a site to renumber into a



draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 3]

INTERNET-DRAFT                                             March 6, 2006


   smaller number of subnet bits when adding a new prefix.


3.  Other RFC 3177 considerations

   RFC3177 suggested that some multihoming approaches (e.g., GSE) might
   benefit from having a fixed /48 boundary. This no longer appears to
   be a significant issue. There is no such requirement coming out of
   the IETF multi6 or shim6 efforts.

   RFC3177 argued that having a "one size fits all" default assignment
   size reduced the need for customers to continually or repeatedly
   justify usage of existing address space in order to get "a little
   more".  Likewise, it also reduces the need for ISPs to evaluate such
   requests. Given the large amount of address space in IPv6, there is
   plenty of space to grant end sites enough space to consistent with
   reasonable growth projections over multi-year time frames. Thus, it
   remains highly desirable to provide end sites with enough space (on
   both initial and subsequent assignments) to last several years.
   Fortunately, this goal can be achieved in a number of ways and does
   not require that all end sites receive the same default size
   assignment.


4.  Impact on IPv6 Standards


4.1.  RFC3056: Connection of IPv6 Domains via IPv4 Clouds

   RFC3056 [RFC 3056] describes a way of generating IPv6 addresses from
   an existing public IPv4 address. That document describes an address
   format in which the first 48 bits concatenate a well-known prefix
   with a globally unique public IPv4 address. The "SLA ID" field is
   assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To
   facilitate transitioning from an RFC3056 address numbering scheme to
   one based on a prefix obtained from an ISP, an end site would be
   advised to number out of the right most bits first, using the left
   most bits only if the size of the site made that necessary.

   Similar considerations apply to other documents that allow for a
   subnet id of 16 bits, including [SITE-LOCAL].


4.2.  IPv6 Multicast Addressing

   Some IPv6 multicast address assignment schemes embed a unicast IPv6
   prefix into the multicast address itself [RFC3306]. Such documents do
   not assume a particular size for the subnet id per se, but do assume



draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 4]

INTERNET-DRAFT                                             March 6, 2006


   that the IPv6 prefix is a /64. Thus, the relative size of the subnet
   id has no direct impact on multicast address schemes.


5.  Security Considerations

   This document has no known security implications.


6.  IANA Considerations

   This document makes no requests to IANA.


7.  Acknowledgments

   This document was motivated by and benefited from numerous
   conversations held during the ARIN XV and RIPE 50 meetings in April-
   May, 2005.


8.  Normative References



9.  Informative References

   [HUSTON-RIPE] "Report from the ARIN XV IPv6 Roundtable"
                    http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-
                    wed-ipv6-roundtable-report.pdf

   [IPV6-HISTORY] Issues Related to the Management of IPv6 Address
                    Space, draft-narten-iana-rir-
                    ipv6-considerations-00.txt

   [RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE
                    Document ID: ripe-267, Date: 22 January 2003
                    http://www.ripe.net/ripe/docs/ipv6policy.html;
                    APNIC:
                    http://www.apnic.net/docs/policy/ipv6-address-
                    policy.html

   [RFC 3056] "Connection of IPv6 Domains via IPv4 Clouds," B.
                    Carpenter, K.  Moore, RFC 3056, February 2001.

   [RFC 3306] "Unicast-Prefix-based IPv6 Multicast Addresses," B.
                    Haberman, D.  Thaler, RFC 3306, August 2002.




draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 5]

INTERNET-DRAFT                                             March 6, 2006


   [RFC 3177] IAB/IESG Recommendations on IPv6 Address Allocations to
                    Sites.  IAB, IESG. September 2001.

   [SITE-LOCAL] RFC 4193 "Unique Local IPv6 Unicast Addresses," R.
                    Hinden, B. Haberman, RFC 4193, October 2005.



10.  Author's Address

   Thomas Narten
   IBM Corporation
   3039 Cornwallis Ave.
   PO Box 12195 - BRQA/502
   Research Triangle Park, NC 27709-2195

   Phone: 919-254-7798
   EMail: narten@us.ibm.com

   Geoff Huston
   APNIC

   EMail: gih@apnic.net

   Rosalea G Roberts
   Stanford University, Networking Systems
   241 Panama Street
   Pine Hall, room 175B
   Stanford, CA  94305-4102

   Email: lea.roberts@stanford.edu
   Phone: +1-650-723-3352


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of



draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 6]

INTERNET-DRAFT                                             March 6, 2006


   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.














draft-narten-ipv6-3177bis-48boundary-01.txt                     [Page 7]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/