One document matched: draft-narten-ipv6-3177bis-48boundary-04.txt
Differences from draft-narten-ipv6-3177bis-48boundary-03.txt
INTERNET-DRAFT Thomas Narten
IBM
<draft-narten-ipv6-3177bis-48boundary-04.txt> Geoff Huston
APNIC
Lea Roberts
Stanford University
March 10, 2008
IPv6 Address Assignment to End Sites
<draft-narten-ipv6-3177bis-48boundary-04.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 that
recommendation in 2002, but began reconsidering the policy in 2005.
This document revisits and updates 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 a policy issue under
the purview of the RIRs, subject to IPv6 architectural and
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 1]
INTERNET-DRAFT March 10, 2008
operational considerations. This document reviews the architectural
and operational considerations of end site assignments as well as the
motivations behind the original 3177 recommendations. The document
clarifies that changing the /48 recommendation is one of policy, and
has minimal impact on the IPv6 architecture and on IETF Standards.
This document updates and replaces RFC 3177.
Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. On /48 Assignments to End Sites.......................... 3
3. Other RFC 3177 considerations............................ 5
4. Impact on IPv6 Standards................................. 5
4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds. 5
4.2. IPv6 Multicast Addressing........................... 5
5. Summary.................................................. 6
6. Security Considerations.................................. 7
7. IANA Considerations...................................... 7
8. Acknowledgments.......................................... 7
9. Normative References..................................... 7
10. Informative References.................................. 7
11. Author's Address........................................ 8
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.
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 2]
INTERNET-DRAFT March 10, 2008
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. Additional
history and discussion of IPv6 address policy and its long-term
implications can be found in [IPV6-HISTORY].
This document revisits and updates the RFC 3177 recommendations.
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 a policy issue under the purview of the
RIRs, subject to IPv6 architectural and operational considerations.
This document is 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
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
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 3]
INTERNET-DRAFT March 10, 2008
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 possible
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 receive the same amount of address space as a home user, who
today typically has a single LAN and (at most) a small number of
machines. 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.
The above-mentioned RFC3177 goals can easily be met by giving home
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 4]
INTERNET-DRAFT March 10, 2008
users a /56 assignment by default.
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 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 [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
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 5]
INTERNET-DRAFT March 10, 2008
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 a
policy issue under the purview of the RIRs, subject to IPv6
architectural and operational considerations. The RFC 3177
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
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
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 6]
INTERNET-DRAFT March 10, 2008
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-v002.html
[ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and
utilisation requirement",
http://www.arin.net/policy/proposals/2005_8.html
[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
[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.
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 7]
INTERNET-DRAFT March 10, 2008
[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-01.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 - 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
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
draft-narten-ipv6-3177bis-48boundary-04.txt [Page 8]
INTERNET-DRAFT March 10, 2008
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, THE IETF TRUST 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.
Intellectual Property
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-04.txt [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 06:11:13 |