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

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

 



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) this would not solve a real problem,

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

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

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


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux