[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Thoughts on IPv6 Address Assignment to End Sites

Authors:
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 introduction.
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:


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.


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. 


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.


s/size\./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
 assignment.
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. 

or
There were three major motivations behind [RFC3177]'s recommendation that a /48 be allocated to any end site. 


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.
I'm not sure that follows. I would like a /32 for my office. Does the fact that I asked justify giving to me? 


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


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


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

 RFC3056 [RFC3056]


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.


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:
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
      additional space


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
      of devices

                  ^ 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 cognition :-)