Subject: Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric)

From: Geoff Huston <[email-masked]>
Date: Sun, 04 Jun 2006 10:39:26 +1000

At 01:33 PM 3/06/2006, Steven Blake wrote:
>I am concerned about the conclusion reached in this document (that HD
>ratios > 0.8 and closer to 0.94 should be considered when making address
>allocations to larger providers).

This is a topic of interest both to the IETF and to regional addressing 
policy fora, and some care needs to be taken in reaching an understanding 
of relative roles.

As compared to your opening statement relating to the conclusion of this 
document, I must correct you  by noting that this document makes NO 
specific recommendation as to an optimal HD Ratio value to be used in the 
context of a threshold address utilization efficiency metric. This document 
provides a refinement to the work reported in RFC1715, RFC 3177 and RFC 
3194 that recommended the use of an HD Ratio of 0.8 for assessment of 
threshold address utilization efficiencies in an address allocation 
context. The refinement proposed in this document is, and I quote:

   "This study concludes that consideration should be given to the
    viability of specifying a higher HD-Ratio value as representing a
    more relevant model of internal network structure, internal routing
    and internal address aggregation structures in the context of IPv6
    network deployment."

Your representation as to the document's conclusions is simply not 
supported by the document itself.

>  I believe that:
>
>(1) this would not solve a real problem,

I must disagree with this perspective.

This document observes that there is a body of opinion and some evidence 
that suggests  that the conclusions and recommendations in RFC1715 and 
3177, using a metric defined in RFC3194, may not be altogether appropriate 
in the context of deployment of public Internet infrastructure. I am of the 
view, that yes, this is a topic worthy of some further study and associated 
reporting of this perspective.

>(2) it is risky to infer too much from existing network design
>     practice when considering future provider networks that may
>     be much larger, and

As this document concludes by pointing out that this is an area for further 
study it is hard to see where this comment and the document differ 
substantively.

>(3) there is a better solution to the alleged problem.

This document does not represent a "solution". Whether you believe that 
there is a "better" address utilization threshold efficiency metric than 
the HD Ratio, or not, is not exactly the major point of this document. This 
document points out that there is a body of evidence that suggests that use 
of an HD Ratio of 0.8 is a poor metric and that its is an area for further 
study to determine what an appropriate metric may be.

As to where such a study may be conducted, my above observation about the 
relative roles of the IETF and regional addressing policy fora was intended 
to illustrate the perspective that such a topic may well be best conducted 
not in the IETF but in these addressing policy fora. Accordingly, I 
strongly suspect that the remainder of your comments may well be best 
presented in these fora rather than the IETF.

regards,

     Geoff

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Geoff Huston <[email-masked]>
Date: Sun, 04 Jun 2006 15:34:58 +1000

At 02:52 PM 4/06/2006, Steven Blake wrote:
>Geoff,
>I don't understand why you think my paraphrase of your document's
>conclusions (including the quoted text above) is unfair or inaccurate.

I am pointing out (again) that the document did not recommend the adoption 
of any particular HD ratio value. It is possible that it may be of some 
value at this point to read through the document once more in order to 
appreciate precisely what is in the document and also to appreciate what is 
not in the document, as your comments relating to overall address 
consumption and sending "messages" to providers, wrong or otherwise, appear 
to be based on material that is simply not contained in this document. It 
is not altogether clear to me how your comments are to be considered in the 
context of an IETF last call on this particular document in the context of 
the IETF process.

regards,

      Geoff

---

From: Steven Blake <[email-masked]>
Date: Sun, 04 Jun 2006 00:52:55 -0400

Geoff,

What is the concern that would make such consideration (of specifying a
higher HD ratio) worthwhile?  I assume that it is address allocation
inefficiency with HD = 0.80, as suggested in your comments on Figure 4,
and the implied risk (which you have described in much more detail
elsewhere) that IPv6 unicast address space is a resource at plausible
risk of being exhausted at some point in the future, without changes to
the HD ratio.  Am I mistaken?

I've read your arguments elsewhere that we are at risk of allocating
a /1 - /4 worth of space in the next 60 years under current polices. I
don't find your arguments convincing, and further, I'm not convinced
that this would pose some sort of catastrophe, rather than the
achievement of a steady state.  And even if it is a real risk, then a
switch to /56 allocations for residential/SOHO is a preferable solution
to increasing HD, because we don't know what the design for an internet-
sized IGP would look like.

I am concerned that this document sends the wrong message to providers,
and I fear that their likely reaction to the perceived risk of tighter
allocation policies by the RIRs with be more harmful to the IPv6
internet that the potential risk of address space exhaustion.

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Sun, 04 Jun 2006 00:52:55 -0400

Geoff,

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Fri, 02 Jun 2006 23:33:16 -0400

I am concerned about the conclusion reached in this document (that HD
ratios > 0.8 and closer to 0.94 should be considered when making address
allocations to larger providers).  I believe that:

1. To begin, the following number of /48 site prefixes can be allocated
out of 2000::/3, for various values of the HD ratio:

HD       0.80    0.85   0.90     0.94

/48s     68.7e9  327e9  1.56e12  5.42e12

Note that for HD = 0.80, that is > 6 site allocations per-person, when
the world reaches peak population of ~10e9 around 2050.  Recall that
site allocations are not permanent, so they can be recycled as the
population "rolls over".

Assuming that 6 site allocations per-person is insufficiently
conservative, then consider the scenario where the RIRs issue maximum
size allocations of /16.  There are 2^13 possible /16s under 2000::/3.
If half of these /16s are utilized at HD = 0.80, and the other half are
empty, then 2000::/3 could accommodate 208e9 /48s (632e9 for HD = 0.85).
 
We could quadruple these numbers while only allocating approximately
half of the total available IPv6 address space.  Under these assumptions
we could very easily imagine a future internet supporting > 800e9
subscriber sites (80 per-person!), while still holding to the HD = 0.80
allocation policy (2.53e12 for HD = 0.85).

Of all the challenges that will have to be solved to realize such a
large internet, IPv6 address exhaustion should be the least of our
worries.

2.  Assume that the previous assumptions are unwarranted, 68.7e9 is the
maximum number of /48 site allocations that can be supported with 
HD = 0.80, and that this number of sites is insufficient.  Note that the
number of possible providers cannot grow by more than an order of
magnitude from today's number, for a variety of economic and logistical
reasons (and some would argue that the number has already peaked).  In a
world with tens or hundreds of billions of subscriber sites, the largest
providers may have more than a billion subscribers.

Consider a future (large? medium-sized?) provider serving 2^28 = 268e6
subscriber sites.  The following is the allocation size needed by this
provider for a range of HD values:

Efficiency       Allocated prefix
----------       ----------------

100% efficiency  /20
HD = 0.80        /13.0
HD = 0.85        /15.1
HD = 0.90        /16.9
HD = 0.94        /18.2

For HD = 0.94, there are ~2 bits of slack to allocate for internal
hierarchy, less than 1 bit per-level assuming four levels of
provider-internal hierarchy (<= 50% utilization efficiency/level).

Is it reasonable to assume that such a large network can be engineered
and maintained with only two bits of allocation slack, without frequent
renumberings?  Experience from existing networks which are typically
much smaller might not hold for much larger networks.

3. /48 site allocations are massive overkill for residences and SOHOs.
Assume 10e9 organizations (~1 per-person) needing four /48 allocations
each (for multi-homing).  Assume that the remaining hundreds of billions
of residence/SOHO sites can function with /56 site allocations.
2000::/3 can accommodate these 40e9 /48s plus an additional 2.89e12 /56s
with HD = 0.80 (with no tricks, such as the max /16 assignments
suggested above).

A /56 allocation is more or less equivalent to an IPv4 /16 allocation
(256 Class C subnets).  I will be delighted if my residential provider
ever offers me a /60 IPv6 allocation.

Being unnecessarily conservative with address allocations to providers
will only increase the chance that they will be unnecessarily
conservative with address allocations to subscribers.

Regards,

// Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 5 Jun 2006 20:12:28 +0200

> (1) this would not solve a real problem,

A little foresight never hurt anyone. If IPv4 space had been given  
out using today's policies from the start, that would have given us a  
decade or so more time with IPv4.

>     practice when considering future provider networks that may

I agree.

> out of 2000::/3, for various values of the HD ratio:

You assume that all address space given out will actually be used to  
address customers. That's unlikely, especially as address blocks get  
larger: when the blocks get larger, both the likelihood of it all  
being used (for your favorite defintion of "all") decreases, along  
with the likelihood of enough of it being used so that it can't be  
reclaimed.

I think we're going to see this with IPv4 too. Today, some 10% of all  
allocations/assignments account for some 90% of the address space  
used, with block sizes in the million range. For instance, France  
Telecom got a /9 earlier this year. If they somehow fail to connect  
millions of customers in the forseeable future, a very big chunk of  
those 8 million+ addresses are going to be left sitting on a shelf  
where they can't be used by anyone else.

[...]

> large internet, IPv6 address exhaustion should be the least of our

I agree that we shouldn't impose stricter policies than necesssary,  
but allowing people to waste one address bit out of every five  
between their prefix length and /48 is completely unnecessary. You  
lose a maximum of one digit (bit in our universe) per aggregation  
level so 80% = lose 20% of your address bits means assuming a level  
of aggregation for every four address bits. In other words, creating  
an aggregate that covers 16 routes. That's fairly ridiculous. An  
aggregate per 1024 or _maybe_ 256 routes makes sense. That would be  
91% or 86%.

But I see no reason why people requesting a prefix shorter than, say,  
a /28, wouldn't be able to provide insight into their _actual_  
internal address aggregation.

And yes, we should limit the maximum block sizes people can get. The  
risks increase as blocks get larger while the benefit of having a  
single large block rather than several small ones decrease. At some  
point, it's not worth it anymore.

> Note that the
> reasons (and some would argue that the number has already peaked).

That's economics which is much, much harder to predict than  
technology, which we have a hard enough time with anyway.

> In a

Under one prefix? Yeah right.

> ever offers me a /60 IPv6 allocation.

/56 is a very bad prefix size, as it's still way too large for SOHO  
use, and for people needing more it's both small enough to grow out  
of after some time, but big enough to be really inconvenient to  
reengineer into a /48. (Which is more than simply renumber.)

Having to choose between /60 and /48 would be much better than having  
to choose between /64 and bigger in general, as it removes the "will  
I ever need a second subnet" consideration, the average allocation  
size goes down and moving to a /48 after having grown out of a /60  
isn't too painful.

> conservative with address allocations to subscribers.

It's also really helpful if all ISPs use the same subnet sizes. For  
instance, I can set up my routes as DHCPv6 prefix delegation clients,  
so they can be reconfigured with new address prefixes automatically  
when changing ISPs, but I still need to put the subnet bits (and  
therefore the subnet size) in the configuration by hand, so having to  
change that defeats the purpose of the exercise.

---

From: [email-masked]
Date: Mon, 5 Jun 2006 19:40:20 +0000

> decade or so more time with IPv4.

	one should remember that when IP blocks were first handed out,
	there was the expectation that there would be very few networks
	with 10s or 100s of thousands of hosts (pre A/B/C/D split)
	which is a shadowy reflection of todays "IPv6 aggreagates to Tier1"
	model...  kind of spooky eh? 

	modern delegation policy follows the CIDR construct, which strives
	to only delegated the amount of space that will actually be used...
	if this were more strict, then the RIRs would have significantly
	larger free pool from which to make delegations... but it would 
	wreck havoc on the iten of a single, global routing system..   

	granted, these are gross generalizations, but the trends are there.

--bill

---

From: [email-masked]
Date: Mon, 5 Jun 2006 19:40:20 +0000

--bill

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Jun 2006 14:16:59 +0100

> size goes down and moving to a /48 after having grown out of a /60  

There's a certain appeal to this, to have to renumber before your
network grows too big.  Interesting suggestion.
 
> change that defeats the purpose of the exercise.

Which was the point of /48 pervasively?

-- 
Tim/::1