[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process- revised

[William Herrin]

On Wed, Dec 16, 2009 at 8:32 PM, David Farmer <farmer at umn.edu> wrote:
> Well where I think it leaves us, we should define some basic needs basis,
> some common sense requirements that entitles you to increasing amounts of
> address space.  One thing I like about your proposal is that it eliminates
> the detailed usage based justifications of IPv4 and the HD-Ratio concept we
> tried to replace it with currently in IPv6.  Have you ever tried to explain
> HD-Ratios to a pointy haired boss or an accountant?
>
> But, what is wrong with some common sense limits?
>
> Like;
>
> 1. If you need any addresses you get a /56;
>
> 2. You don't need a /48 unless you have at least 256 host;
>
> That could be one host in each of the 256 subnets that a /56 gives you, or
> 256 hosts in a single subnet.
>
> 3. You don't need a /40 unless you have more than one site;
>
> 4. If you reasonably expect to support more that 100 sites you probably
> should have a /32;
>
> 5. You don't need anything more that a /32 unless you are supporting a big
> bunch of sites, like 10,000 or more.

Hi David,

Wherever possible you want to think in terms of simplified
classification vectors.

If the vector is single/multihomed then the only thing I should have
to do to change the class I'm in is add another ISP. I shouldn't have
to pay more for the addresses. I shouldn't have to change the number
of hosts I deploy.

If the vector is cash I spend as a reflection of the value I assign to
my network, then the only thing I should have to do to reach the next
class is spend more money.

If you want to look at host counts then that should be a separate
vector. The only thing I should have to do to reach the next class is
deploy more machines. I shouldn't have to spend more money or
multihome.

Think about this. If you limit the money=value vector based on a host
count vector, you cut high value services off at the knees. Case and
point: DNS. Each DNS root is one server or a small cluster of servers.
Stick it in the same class as a home hobbyist with both a DSL and a
cable modem? Ouch.

Caution: adding additional vectors has a price. The number of
allocation pools set aside can be multiplicative. 5 payment classes
plus 2 ISP-count classes takes 10 pools. Add 5 host count levels and
you have to set aside 50 pools!

What are some of the problems with using host count as a
classification vector and then tying the prefix length to the host
count instead of the payment?

1. If you use it in addition to a payment classification vector, you
might not save any addresses space. You'll have to set aside a lot of
additional allocation pools, large parts of which will sit idle.

2. If you use it instead of a less technically-bound value vector like
money spent, you skew the classification system against high-value
low-host-count services. The DNS roots are an extreme case but server
farms also suffer.

3. How do you determine what sort of host count is fair? HD-ratio is a
mess but it was adopted because its about as close to fair as we were
able to agree on along the host count classification vector. Also, at
a technical level IPv6 addressing is structured along the idea of
64-bit subnets rather than variable size subnets accommodating 128-bit
hosts. If we want to think about host count as a classification
vector, maybe we should couch it in terms of LAN count instead.

4. Complexity. Counting hosts can be hard in a classical ISP scenario
where you may not have any idea how many hosts live with each customer
yet they consume your address space and count towards your
classification. Counting money is comparably easy: a check was
received. It didn't bounce.

5. It may not be necessary. The largest, most expensive possible
allocation under 103 consumes the same percentage of the IPv6 address
space as the smallest routeable allocation in IPv4. Think about the
implications to that.


Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004