[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thoughts on IPv6 Address Assignment to End Sites
Some thoughts, none of which are anything I'll go to the mat over.
Chair hat off. My comments are inline with your text.
Before I start though, three meta-comments.
First, the introduction leads me to believe that what I am about to
read could be summarized as "it doesn't have to be a /48". That is
certainly a major thrust, but you have a second important point: "it
shouldn't be a /64". I think you may want to comment on that in the
Second, I think you missed the major motivation for an ISP to care
what you recommend. I will observe in my remarks inline that I subnet
my home in four subnets and could imagine a couple more in many homes.
To my provider, those many subnets show up as two, count them, two
IPv4 addresses of an allocation of up to five, and it works just fine.
I could imagine an ISP dismissing the argument about home subneting
because it is great theory that doesn't correspond with their
experience. But there is a better reason for the *ISP* to enable end
to end addressing of multiple subnets - one that per ArcChart (http://www.arcchart.com/blueprint/show.asp?id=428
) drives their present business. Think about this; if you agree, the
following paragraph may be appropriate text to work in somewhere, or
the basis for such.
The Internet and the businesses of ISPs grew at a fair clip during the
Internet's commercialization phase in the 1990's, but have exploded in
this decade. As much as ISPs complain about their capacity demands, in
the consumer sector this has to be attributed to the development of
popular applications and web sites like BitTorrent and YouTube. The
development of such applications was long hampered by inadequate
broadband deployment and the complexities of NAT and firewall
traversal. It has been overcome by the application developers, who
have also developed sophisticated traversal techniques to circumvent
the restrictions imposed by NATs and firewalls. Enabling the use of
end to end addressing, including LAN segmentation in the SOHO, in part
eases the development and deployment of future applications, which in
turn can be expected to fuel ISP business growth.
Third, I have been the humble recipient of lectures from time to time
on the difference between an prefix allocation and an address or
prefix assignment; Alice allocates prefixes to Bob who in turn assigns
them to networks and the interfaces they contain. Allocations can be
expected to be more or less permanent while the allocation
relationship is maintained, while assignments can change with the
direction of the wind. In this document, the two words appear to be
used interchangeably. Should you uniformly use the word "allocation"?
Turning to your document:
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.
editorial nit; I would break this paragraph here
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 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.
If I understood Thomas correctly on Thursday, it does not replace RFC
3177. It updates certain parts, perhaps just one, which for clarity
should be identified by section number, leaving the rest intact and in
effect. Specifically, it addresses the comments regarding a /48 being
assigned to end sites.
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
Would it be appropriate for this to read "[RFC3177] called for..."?
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
It seems to me here that, in view of the accusation that we were
thinking in "classful" terms in 3177, there would be value in
commenting on the address architecture itself. An example of possible
text might read:
[RFC4291] sets forth the architecture of IPv6 addresses. It recommends
reserving the lower 64 bits for host identification, as common
interface identifiers such as MAC addresses and BCD-encoded E.164
numbers occupy 48-64 bits. The upper 64 bits are used by routing to
locate the interface in the network. They are encoded in a manner
consistent with CIDR [BCP0122], with prefix lengths being determined
entirely by business and operational requirements. Since IPv6
addresses are written using hexadecimal digits, and for reasons
related to human cognition, one could recommend that allocation prefix
lengths be multiples of four bits, but there is no technical
requirement even for this.
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.
You do a paragraph break at the start of the second reason. Should you
break the paragraph here?
Reading your sentence above, and frankly much of this document, I am
reminded that Pekka often tells me that nothing that can can be said
in five words that can't also be said in twenty. Would either of the
following sentences capture the intent of your sentence?
[RFC3177] recommended the uniform allocation of /48s to all end sites
for three main reasons.
There were three major motivations behind [RFC3177]'s recommendation
that a /48 be allocated to any end site.
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.
I'm not sure that follows. I would like a /32 for my office. Does the
fact that I asked justify giving to me?
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.
editorial nit: I generally do not put complete sentences in
parentheses, as a parenthetical comment asks the reader to hold one
thought while the author delivers another. It is one thing to do that
as you do in the the first sentence of the above; a 78 word
parenthetical sentence is asking a lot of a reader whose first
language is English, never mind other readers. Can we make that long
parenthetical sentence part of the main thrust of the paragraph somehow?
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,
"could be identical"; I don't see any reason to presume they would
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
"it" is duplicated
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.
I have heard this argument, and I think it fails pretty dramatically.
In my home, I have four subnets - a delegated prefix in my office, a
prefix for the wired domain, and prefixes for two wireless domains
(something about steel and water in the walls and their effect on
802.11 frequencies). In two income homes, one could easily imagine a
prefix for each office, and one could imagine a separate prefix for
the grandmother's apartment or the pool. Following my reasoning about
hexadecimal digits and human cognition - and your third point below -
that would suggest that SOHO networks be allocated /60s, where SMBs
might get /56s and larger enterprises /52s or /48s. If I am using
five /64 prefixes out of a /48 allocated to me and am forced to
renumber (gasp!) into a /60, it isn't so very hard. I am going to map
the 13 bits of zero into a single bit of zero, and be done.
Where this argument makes sense is a network whose manager has used
O(2^N) prefixes out of a larger allocation, and changes providers to
one that gives him 2^(N-1) prefixes or less. Such an administration
either intended to redesign its network or was incompetent in some way.
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
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.
In these last two sentences, I would comment in the text that home
networks today often have separate wired and wireless LANs and
separated LANs for offices, so the assignment of a /64 doesn't even
meet today's network designs. Don't argue about it not meeting a
future need, as your wishlist isn't an ISP's or RIR's set of
The above-mentioned RFC3177 goals can easily be met by giving home
users a /56 assignment by default.
This comes dangerously close to saying "the size should be /56 in some
cases" - picking a number, which people spoke against Thursday. I
might reword as:
The [RFC3177] goals can be met by allocating edge networks prefixes
that are both commensurate with current need and generous enough for
expected long term growth.
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.
Should you give a reference for GSE?
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
Is this really a "separate" consideration? Didn't you already say this
in section 2?
4. Impact on IPv6 Standards
4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds
would it be sufficient to say "[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.
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:
The following appear to be sentences. Capitalize the opening word and
uniformly terminate with a period?
- 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
I would reword:
The default allocation size should take into consideration the
likelihood that an end site may use multiple subnets, and avoid the
IPv4 practice of forcing frequent and continual justification of small
amounts of space.
Although a /64 can (in theory) address an almost unlimited number
^ given a flat LAN architecture
, 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.
Isn't that said in the previous point?
- 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
This (closing) statement is the first use of the word "nibble" in the
draft, and if left as it stands is a conclusion not supported by the
arguments made. Great reason to include my comment on human