INTERNET-DRAFT Thomas Narten
IBM
<draft-narten-ipv6-3177bis-48boundary-00.txt> Geoff Huston
APNIC
Lea Roberts
Stanford University
July 11, 2005
IPv6 Address Allocation to End Sites
<draft-narten-ipv6-3177bis-48boundary-00.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 on January 11, 2006.
Abstract
This document revisits the IAB/IESG recommendations on the assignment
of IPv6 address space to end sites. Specifically, it indicates that
changing the default end-site assignment for typical home and SOHO
sites from /48 to /56 is consistent with the goals of IPv6 and RFC
3177. Although it is for the RIR community to make adjustments to the
IPv6 address space allocation and end site assignment policies, the
IETF community would be comfortable with RIRs changing the default
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 1]
INTERNET-DRAFT July 11, 2005
assignment size to /56 for smaller end sites. 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............................ 5
4. Security Considerations.................................. 5
5. IANA Considerations...................................... 6
6. Acknowledgments.......................................... 6
7. Normative References..................................... 6
8. Informative References................................... 6
9. Author's Address....................................... 6
1. Introduction
RFC 3177 [RFC3177] called for the default IPv6 assignment size to end
sites being a /48. Subsequently, the RIRs developed and adopted IPv6
address assignment and allocation policies consistent with the RFC
3177 recommendations [RIR-IPV6]. In addition to the /48
recommendation, an HD-Ratio metric [RFC 3194] of .8 was adopted to
determine how much space an LIR can obtain from an RIR, and when an
LIR may go back to an RIR for an additional allocation. Additional
history and discussion of IPv6 address policy and its long-term
implications can be found in [IPV6-HISTORY].
By late 2004, informal discussions began raising the question of
whether the current IPv6 address allocation policies were achieving a
proper balance between conservation and ease of access. In
particular, projections of address space usage over the next 50-100
years under the existing RIR assignment and allocation policies
indicate that one cannot argue that IPv6 has an "infinite supply" of
addresses. Furthermore, there are plausible scenarios where a
significant fraction of the total IPv6 address space could be
consumed in 60 years. For example, projections show a consumption
range of /7 [IPV6-HISTORY] all the way to a /1 (or 1/2 of the entire
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 2]
INTERNET-DRAFT July 11, 2005
IPv6 address space) [HUSTON-RIPE].
Due to the inherent uncertainties in long-term address consumption
rates, and the difficulties that arise when operating in an
environment where address depletion becomes a real concern (i.e., the
current IPv4 experience) it would be prudent for the RIRs to update
and revise the current IPv6 address allocation and assignment
policies to ensure that IPv6 address space remains plentiful across
the next 50-100 years.
This document performs three functions:
1) It revisits the RFC 3177 recommendations and makes the case that
the default IPv6 assignment size for smaller end sites could be
changed from /48 to /56 with essentially no impact on end users.
In addition, there are no impacts on existing IPv6 standards or
implementations.
2) It is a message to the RIR community that the IETF community
would be comfortable with the RIR community revising and
updating its IPv6 assignment policy to change the default end
assignment for small end sites to a /56.
3) It obsoletes RFC 3177 and reclassifies it historic.
2. On /48 Assignments to End Sites
[note: this section was taken mostly verbatim from Section 5.2 of
[IPV6-HISTORY]; future versions will decide how to better split the
text between the two documents, since it is generally not ideal to
have the identical text in multiple documents.]
Per existing policy, the RIRs assume that end site assignments are
/48s, and thus utilization measurements are based on an HD-ratio that
counts numbers of /48 assignments. Granting a /48 to an end site,
allows a site to have up to 65,536 subnets. While that number may
make sense for larger sites, it is hard to imagine a typical home
user requiring so much space. Indeed, the default end site assignment
today is in practice the same for home users and larger businesses.
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 (even this is not
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 3]
INTERNET-DRAFT July 11, 2005
always assured), but getting even a small number more is typically
more expensive either in terms of the effort needed to obtain
additional addresses, or in the actual monthly cost. (It should be
noted that the "cost" of additional addresses cannot be justified by
the actual cost of those addresses as charged by the RIRs, but the
need for additional addresses is sometimes used to imply a different
type or "higher grade" of service, for which some ISPs charge extra.)
Thus, an important goal in IPv6 was to significantly change the
default and minimal end site assignment, from "a single address" to
"multiple networks".
Another concern was that if a site changes ISPs and subsequently
renumbers, 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 easier, 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.
The above concerns were met by the /48 recommendation, but could also
be realized through a more conservative approach. For example, one
can imagine "classes" of network types, with default sizes for each
class. For example:
- a PDA-type device with a low bandwidth WAN connection and one
additional PAN connection - a single network or /64 assignment.
A /64 assignment allows for the addressing of a number of hosts,
each connected to the same PAN (personal area network, e.g.,
Bluetooth) link as the device. This would be appropriate in
deployments where the end device is not expected to provide
connectivity for a larger site, but is intended to provide
connectivity for the device and a small number of additional
devices directly connected to the same PAN as the device.
- home user - expected to have a small number of subnets, e.g.,
less than 10 - a /56 assignment
- small business/organization - one having a small number of
networks, e.g., less than 100 - a /56 assignment
- large business/organization - an organization having more than
100 subnets - a /48.
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
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 4]
INTERNET-DRAFT July 11, 2005
the vast majority of end 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.)
One can, of course, imagine a policy supporting the entire range of
assignments between /48 and /64, depending on the size or type of end
site. However, there are a number of arguments in favor of having a
small number of classes of sizes:
- It becomes easier for end users to identify an assignment size
that is appropriate for them
- It increases the likelihood that there will be agreement among
ISPs on the appropriate assignment sizes for the various
customer classes.
- Having excess flexibility in selecting an appropriate assignment
size for a given customer type can lead to different ISPs
offering different assignment sizes to the same customer. This
is undesirable because it may result in
- an end site needing to renumber into a smaller subnet space
when switching ISPs, or
- it may lead to ISPs attempting to differentiate their
service offerings by offering the most liberal address
assignment policies (to attract customers), defeating the
purpose of having multiple class assignment sizes.
- The operational management of the reverse DNS tree is simplified
if delegations are on nibble boundaries (e.g., /48, /52, /56,
and /64).
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 current IETF multi6 or shim6 efforts.
4. Security Considerations
This document has no known security implications.
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 5]
INTERNET-DRAFT July 11, 2005
5. IANA Considerations
This document makes no requests to IANA.
6. Acknowledgments
This document was motivated by and benefited from numerous
conversations held during the ARIN XV and RIPE 50 meetings in April-
May, 2005.
7. Normative References
8. Informative References
[HUSTON-RIPE] "Report from the ARIN XV IPv6 Roundtable"
http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-
wed-itu-ipv6-proposal.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/index.html#six; 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 3177] IAB/IESG Recommendations on IPv6 Address Allocations to
Sites. IAB, IESG. September 2001.
[RFC 3194] The H-Density Ratio for Address Assignment Efficiency An
Update
on the H ratio. A. Durand, C. Huitema. November
2001.
9. Author's Address
Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 6]
INTERNET-DRAFT July 11, 2005
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
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.
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 7]
INTERNET-DRAFT July 11, 2005
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 (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.
draft-narten-ipv6-3177bis-48boundary-00.txt [Page 8]
