Subject: Thoughts on IPv6 Address Assignment to End Sites

From: Fred Baker <[email-masked]>
Date: Fri, 1 Aug 2008 15:23:04 -0700

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Aug 2008 18:31:55 +1200

On 2008-08-02 10:23, Fred Baker wrote:

...
> If I understood Thomas correctly on Thursday, it does not replace 
> RFC 3177. It updates certain parts, perhaps just one, which for clarity 

I just re-read 3177. It's really quite short and the notion of
a standard /48 allocation runs right through it. So I think it makes
more sense in the end to consider that it's completely replaced by
the new document. I'd be happier if the above sentence could read:

The IAB and IESG have agreed that this document replaces RFC 3177.

("updates and replaces" seems redundant.)

There's a paragraph in 3177 that starts:
  "It is not obvious, however, that all edge networks are likely to be
   recursively subnetted..."

I believe that paragraph, suitably tweaked, is worth rescuing and
adding to the draft.

<snip>

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

I don't quite agree about 'incompetent'. If a site was leased
a /48 by ISP A, and then decides to multihome to ISP B, and discovers
that B's pricing structure means that only a /56 is affordable,
then a lot depends on the approach taken to allocations under the /48.
For example, perhaps the IT department decided to use a /56 for each
major building on the company's campus. That was short-sighted perhaps,
but was it incompetent? That's a strong word.

The resulting recommendation to user sites is something like: don't
allocate subnets sparsely within your prefix, but concentrate
them. Or to say it another way: if your ISP gives you a /N prefix,
plan your subnets to fit inside a single /(N+4) or /(N+8), in case
you ever sign up with an ISP that hands out longer prefixes.

I suggest putting some such recommendation into the draft.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 2 Aug 2008 21:06:30 -0700

On Aug 1, 2008, at 11:31 PM, Brian E Carpenter wrote:

> I don't quite agree about 'incompetent'. If a site was leased a /48  
> by ISP A, and then decides to multihome to ISP B, and discovers that  
> B's pricing structure means that only a /56 is affordable, then a  
> lot depends on the approach taken to allocations under the /48.

If the decision process follows that pattern, that is an excellent  
example of incompetence. They decided on a new ISP and went to sign a  
contract, and only then asked what it would cost them to get the  
service they wanted?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Aug 2008 18:14:26 +1200

On 2008-08-03 16:06, Fred Baker wrote:
>> I don't quite agree about 'incompetent'. If a site was leased a /48 by
>> ISP A, and then decides to multihome to ISP B, and discovers that B's
>> pricing structure means that only a /56 is affordable, then a lot
>> depends on the approach taken to allocations under the /48.
> 
> contract, and only then asked what it would cost them to get the service
> they wanted?

Well, they might be on a budget... In any case, let's not argue about
hypothetical incompetence: all I'm really suggesting for the draft
is to suggest that sparse usage of a short prefix is probably not optimal
practice, in case you ever choose to renumber into a longer prefix.

    Brian

---

From: Gert Doering <[email-masked]>
Date: Tue, 5 Aug 2008 20:11:40 +0200

Hi,

> used interchangeably. Should you uniformly use the word "allocation"?

In RIPE land, an "allocation" is given to a provider (usually a RIPE 
member), and end user will only ever receive an "assignment".

This is established terminology here, but I'm not sure how this is used
in other RIR regions.

Since this document talks about "space given to end users", the proper
term for that, *in RIPE land*, would be "assignment".

Gert Doering
        -- RIPE address policy WG chair
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Aug 2008 11:35:14 -0700

> term for that, *in RIPE land*, would be "assignment".

Thanks.

---

From: Roque Gagliano <[email-masked]>
Date: Sat, 9 Aug 2008 15:28:07 -0300

Hi,

> term for that, *in RIPE land*, would be "assignment".

Same here.
Roque Gagliano - LACNIC

---

From: Nathan Ward <[email-masked]>
Date: Mon, 11 Aug 2008 00:44:18 +1200

> This is established terminology here, but I'm not sure how this is  

This is the terminology in the APNIC region, also.

--
Nathan Ward