IAB/IESG Recommendations on IPv6 Address Allocations to Sites
RFC 3177
| Document | Type |
RFC - Informational
(September 2001; No errata)
Obsoleted by RFC 6177
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3177 (Informational) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group IAB
Request for Comments: 3177 IESG
Category: Informational September 2001
IAB/IESG Recommendations on IPv6 Address Allocations to Sites
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document provides recommendations to the addressing registries
(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address
blocks to end sites. In particular, it recommends the assignment of
/48 in the general case, /64 when it is known that one and only one
subnet is needed and /128 when it is absolutely known that one and
only one device is connecting.
The original recommendations were made in an IAB/IESG statement
mailed to the registries on September 1, 2000. This document refines
the original recommendation and documents it for the historical
record.
1. Introduction
There have been many discussions between IETF and RIR experts on the
topic of IPv6 address allocation policy. This memo addresses the
issue of the boundary in between the public and the private topology
in the Internet, that is, how much address space should an ISP
allocate to homes, small and large enterprises, mobile networks and
transient customers.
This document does not address the issue of the other boundaries in
the public topology, that is, between the RIRs and the LIRs.
This document was developed by the IPv6 Directorate, IAB and IESG,
and is a recommendation from the IAB and IESG to the RIRs.
IAB & IESG Informational [Page 1]
RFC 3177 IAB/IESG Recommendations on IPv6 Addresses September 2001
2. Background
The technical principles that apply to address allocation seek to
balance healthy conservation practices and wisdom with a certain ease
of access. On one hand, when managing a potentially limited
resource, one must conserve wisely to prevent exhaustion within an
expected lifetime. On the other hand, the IPv6 address space is in
no sense as limited a resource as the IPv4 address space, and
unwarranted conservatism acts as a disincentive in a marketplace
already dampened by other factors. So from a market development
perspective, we would like to see it be very easy for a user or an
ISP to obtain as many IPv6 addresses as they really need without a
prospect of immediate renumbering or of scaling inefficiencies.
The IETF makes no comment on business issues or relationships.
However, in general, we observe that technical delegation policy can
have strong business impacts. A strong requirement of the address
delegation plan is that it not be predicated on or unduly bias
business relationships or models.
The IPv6 address, as currently defined, consists of 64 bits of
"network number" and 64 bits of "host number". The technical reasons
for this are several. The requirements for IPv6 agreed to in 1993
included a plan to be able to address approximately 2^40 networks and
2^50 hosts; the 64/64 split effectively accomplishes this.
Procedures used in host address assignment, such as the router
advertisement of a network's prefix to hosts [RFC2462], which in turn
place a locally unique number in the host portion, depend on this
split. Subnet numbers must be assumed to come from the network part.
This is not to preclude routing protocols such as IS-IS level 1
(intra-area) routing, which routes individual host addresses, but
says that it may not be depended upon in the world outside that zone.
The 64-bit host field can also be used with EUI-64 for a flat,
uniquely allocated space, and therefore it may not be globally
treated as a subnetting resource. Those concerned with privacy
issues linked to the presence of a globally unique identifier may
note that 64 bits makes a large enough field to maintain excellent
random-number-draw properties for self-configured End System
Designators. That alternative construction of this 64-bit host part
of an IPv6 address is documented in [RFC3041].
While the IETF has also gone to a great deal of effort to minimize
the impacts of network renumbering, renumbering of IPv6 networks is
neither invisible nor completely painless. Therefore, renumbering
should be considered a tolerable event, but to be avoided if
reasonably feasible.
IAB & IESG Informational [Page 2]
Show full document text