IPv6 Address Assignment to End Sites
draft-ietf-v6ops-3177bis-end-sites-01

Internet Engineering Task Force                            Thomas Narten
Internet-Draft                                                       IBM
Intended Status: BCP                                        Geoff Huston
Expires: July 3, 2011                                              APNIC
Obsoletes: 3177                                              Lea Roberts
                                                     Stanford University
                                                         January 3, 2011

                   IPv6 Address Assignment to End Sites

                <draft-ietf-v6ops-3177bis-end-sites-01.txt>

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on July 3, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 1]
INTERNET-DRAFT                                         November 23, 2010

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

   RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
   in most cases. The Regional Internet Registries (RIRs) adopted that
   recommendation in 2002, but began reconsidering the policy in 2005.
   This document obsoletes the RFC 3177 recommendations on the
   assignment of IPv6 address space to end sites.  The exact choice of
   how much address space to assign end sites is an issue for the
   operational community. The IETF's role in this case is limited to
   providing guidance on IPv6 architectural and operational
   considerations. This document reviews the architectural and
   operational considerations of end site assignments as well as the
   motivations behind the original 3177 recommendations. Moreover, the
   document clarifies that a one-size-fits-all recommendation of /48 is
   not nuanced enough for the broad range of end sites and is no longer
   recommended as a single default.

   This document obsoletes RFC 3177.
Contents

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

   1.  Introduction.............................................    3

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

   3.  Other RFC 3177 considerations............................    6

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

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 2]
INTERNET-DRAFT                                         November 23, 2010

   5.  Summary..................................................    7

   6.  Security Considerations..................................    8

   7.  IANA Considerations......................................    8

   8.  Acknowledgments..........................................    8

   9.  Normative References.....................................    8

   10.  Informative References..................................    8

   11.  Author's Address........................................    9

1.  Introduction

   There are a number of considerations that factor into address
   assignment policies. For example, to provide for the long-term health
   and scalability of the public routing infrastructure, it is important
   that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out
   an excessive amount of address space could result in premature
   depletion of the address space. This document focuses on the (more
   narrow) question of what is an appropriate IPv6 address assignment
   size for end sites. That is, when end sites request IPv6 address
   space from ISPs, what is an appropriate assignment size.

   RFC 3177 [RFC3177] called for a default end site IPv6 assignment size
   of /48. Subsequently, the Regional Internet Registries (RIRs)
   developed and adopted IPv6 address assignment and allocation policies
   consistent with the RFC 3177 recommendations [RIR-IPV6]. In 2005, the
   RIRs began discussing IPv6 address assignment policy again. Since
   then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE] and RIPE [RIPE-
   ENDSITE] have revised the end site assignment policy to encourage the
   assignment of smaller (i.e., /56) blocks to end sites.

   This document obsoletes RFC 3177, updating its recommendations in the
   following ways:

     1) It is no longer recommended that /128s be given out. While there
        may be some cases where assigning only a single address may be
        justified, a site by definition implies multiple subnets and
        multiple devices.

     2) RFC 3177 specifically recommended using prefix lengths of /48,
        /64 and /128. Specifying a small number of fixed boundaries has
        raised concerns that implementations and operational practices
        might become "hard-coded" to recognize only those fixed

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 3]
INTERNET-DRAFT                                         November 23, 2010

        boundaries (i.e., a return to "classful addressing"). The actual
        intention has always been that there be no hard-coded boundaries
        within addresses, and that CIDR continues to apply to all bits
        of the routing prefixes.

     3) This document moves away from the previous recommendation that a
        single default assignment size (e.g., a /48) makes sense for all
        end sites in the general case. End sites come in different
        shapes and sizes, and a one-size-fits-all approach is not
        necessary or appropriate.

   This document does, however, reaffirm an important assumption behind
   RFC 3177:

        A key principle for address management is that end sites always
        be able to obtain a reasonable amount of address space for their
        actual and planned usage, and over time ranges specified in
        years rather than just months. In practice, that means at least
        one /64, and in most cases significantly more. One particular
        situation that must be avoided is having an end site feel
        compelled to use IPv6-to-IPv6 Network Address Translation or
        other burdensome address conservation techniques because it
        could not get sufficient address space.

   This document does not make a formal recommendation on what the exact
   assignment size should be.  The exact choice of how much address
   space to assign end sites is an issue for the operational community.
   The IETF's role in this case is limited to providing guidance on IPv6
   architectural and operational considerations. This document provides
   input into those discussions.  The focus of this document is to
   examine the architectural issues and some of the operational
   considerations relating to the size of the end site assignment.

2.  On /48 Assignments to End Sites

   Looking back at some of the original motivations behind the /48
   recommendation [RFC3177], there were three main concerns. The first
   motivation 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 often difficult or even
   impossible -- unless one is willing to pay a (significantly)
   increased fee for what is often considered to be a "higher grade" of
   service.  (It should be noted that increased ISP charges to obtain a

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 4]
INTERNET-DRAFT                                         November 23, 2010

   small number of additional addresses cannot usually be justified by
   the real per-address cost levied by RIRs, but additional addresses
   are frequently only available to end users as part of a different
   type or "higher grade" of service, for which an additional charge is
   levied. The point here is that the additional cost is not due to the
   RIR fee structures, but to business choices ISPs make.) An important
   goal in IPv6 is to significantly change the default and minimal end
   site assignment, from "a single address" to "multiple networks" and
   to ensure that end sites can easily obtain address space.

   A second motivation behind the original /48 recommendation was to
   simplify the management of an end site's addressing plan in the
   presence of renumbering (e.g., when switching ISPs).  In IPv6, a site
   may simultaneously use multiple prefixes, including one or more
   public prefixes from ISPs as well as Unique Local Addresses [ULA-
   ADDRESSES]. In the presence of multiple prefixes, it is significantly
   less complex to manage a numbering plan if the same subnet numbering
   plan can be used for all prefixes. That is, for a link that has (say)
   three different prefixes assigned to it, the subnet portion of those
   prefixes would be identical for all assigned addresses.  In contrast,
   renumbering from a larger set of "subnet bits" into a smaller set is
   often painful, as it it can require making changes to the network
   itself (e.g., collapsing subnets). Hence renumbering a site into a
   prefix that has (at least) the same number of subnet bits is more
   straightforward, because only the top-level bits of the address need
   to change. A key goal of the RFC 3177 recommendations 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.

   A third motivation behind the /48 recommendation was to better
   support network growth common at many sites. In IPv4, it is usually
   difficult (or impossible) to obtain public address space for more
   than a few months worth of projected growth. Thus, even slow growth
   over several years can lead to the need to renumber into a larger
   address blocks. With IPv6's vast address space, end sites can easily
   be given more address space (compared with IPv4) to support expected
   growth over multi-year time periods.

   While the /48 recommendation does simplify address space management
   for end sites, it has also been widely criticized as being wasteful.
   For example, a large business (which may have thousands of employees)
   would by default receive the same amount of address space as a home
   user, who today typically has a single (or small number of) LANs and

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 5]
INTERNET-DRAFT                                         November 23, 2010

   a small number of devices (dozens or less).  While it seems likely
   that the size of a typical home network will grow over the next few
   decades, it is hard to argue that home sites will make use of 65K
   subnets within the foreseeable future. At the same time, it might be
   tempting to give home sites a single /64, since that is already
   significantly more address space compared with today's IPv4 practice.
   However, this precludes the expectation that even home sites will
   grow to support multiple subnets going forward. Hence, it is strongly
   intended that even home sites be given multiple subnets worth of
   space by default. Hence, this document still recommends giving home
   sites significantly more than a single /64, but does not recommend
   that every home site be given a /48 either.

   A change in policy (such as above) would have a significant impact on
   address consumption projections and the expected longevity for IPv6.
   For example, changing the default assignment from a /48 to /56 (for
   the vast majority of end sites, e.g, home sites) would result in a
   savings of up to 8 bits, reducing the "total projected address
   consumption" by (up to) 8 bits or two orders of magnitude. (The exact
   amount of savings depends on the relative number of home users
   compared with the number of larger sites.)

   The above-mentioned RFC3177 goals can easily be met by giving home
   users a default assignment of less than /48, such as a /56.

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 consideration.

   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 be 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.

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 6]
INTERNET-DRAFT                                         November 23, 2010

4.  Impact on IPv6 Standards

4.1.  RFC3056: Connection of IPv6 Domains via IPv4 Clouds

   RFC3056 [RFC3056] 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 [ULA-ADDRESSES].

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
   that the IPv6 prefix is a /64. Thus, the relative size of the subnet
   id has no direct impact on multicast address schemes.

5.  Summary

   The exact choice of how much address space to assign end sites is an
   issue for the operational community.  The RFC 3177 [RFC3177]
   recommendation to assign /48s as a default is not a requirement of
   the IPv6 architecture; anything of length /64 or shorter works from a
   standards perspective.  However, there are important operational
   considerations as well, some of which are important if users are to
   share in the key benefit of IPv6: expanding the usable address space
   of the Internet.  The IETF recommends that any policy on IPv6 address
   assignment policy to end sites take into consideration:

      - it should be easy for an end site to obtain address space to
        number multiple subnets (i.e., a block larger than a single /64)
        and to support reasonable growth projections over long time
        periods (e.g., a decade or more).

      - the default assignment size should take into consideration the
        likelihood that an end site will have need for multiple subnets
        in the future and avoid the IPv4 practice of having frequent and

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 7]
INTERNET-DRAFT                                         November 23, 2010

        continual justification for obtaining small amounts of
        additional space

      - Although a /64 can (in theory) address an almost unlimited
        number of devices, sites should be given sufficient address
        space to be able to lay out subnets as appropriate, and not be
        forced to use address conservation techniques such as using
        bridging. Whether or not bridging is an appropriate choice is an
        end site matter.

      - assigning a longer prefix to an end site, compared with the
        existing prefixes the end site already has assigned to it, is
        likely to increase operational costs and complexity for the end
        site, with insufficient benefit to anyone.

      - the operational considerations of managing and delegating the
        reverse DNS tree under ip6.arpa on nibble vs. non-nibble
        boundaries should be given adequate consideration

6.  Security Considerations

   This document has no known security implications.

7.  IANA Considerations

   This document makes no requests to IANA.

8.  Acknowledgments

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

9.  Normative References

10.  Informative References

   [APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment
                    and utilisation requirement policy,"
                    http://www.apnic.net/policy/proposals/prop-031

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 8]
INTERNET-DRAFT                                         November 23, 2010

   [ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and
                    utilisation requirement",
                    http://www.arin.net/policy/proposals/2005_8.html

   [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

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

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

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

   [RIPE-ENDSITE] "Proposal to Amend the IPv6 Assignment and Utilisation
                    Requirement Policy", 2005-8,
                    http://ripe.net/ripe/policies/proposals/2005-08.html

   [ROUTE-SCALING] "Routing and Addressing Problem Statement", draft-
                    narten-radir-problem-statement-05.txt

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

11.  Author's Address

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

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

   Geoff Huston
   APNIC

   EMail: gih@apnic.net

draft-ietf-v6ops-3177bis-end-sites-01.txt                       [Page 9]
INTERNET-DRAFT                                         November 23, 2010

   Rosalea G Roberts
   Stanford University, Networking Systems
   P.O. Box 19131
   Stanford, CA  94309-9131

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

draft-ietf-v6ops-3177bis-end-sites-01.txt                      [Page 10]