[arin-ppml] What is a "host"?

[David Farmer]

On 9/17/10 16:39 CDT, Michael K. Smith - Adhost wrote:
>>
>> Really, counting up the number of things that require an IPv6 link
>> local address is _NOT_ rocket science, nor is it technically complex.
>>
>> Owen
>>
> Nor is it the appropriate concept for creating policy if that is the
> definition.  I have four web servers in a load-balanced pool, each with
> one NIC.   So, as per your definition, they are only 4 hosts.  But, on
> each of those servers, I have multiple /64's assigned, one for each
> customer.  They have to be discrete /64's for the load balancing to
> work.  So far I have provisioned 20 customers, so I have 80 /64's that
> are assigned across 4 NICs.  Does this mean I still only have 4 hosts?
> Although I have 20 customers?  And 80 /64's?
>
> Rather than argue about the definition of host, I would rather the term
> be abandoned all together and something more inclusive be used.  I am
> not misusing addresses in my configuration but none of those allocations
> would be appropriate if "host" is the defining baseline.

I understand all of the issues with word "host".  However, I believe the 
policy intent is clear, but I'm open to suggestions for different 
wording to use.

Beyond that I would like to ask everyone to take a step back and look at 
the over all intent, there are four clauses, and only one of them has to 
be meet;

-----
a. Having a previously justified IPv4 end-user assignment from ARIN or 
one of its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6 
Multihomed and using an assigned valid global AS number, or;

c. By having a network consisting of a total of 1000 or more hosts, or;

d. By providing a reasonable technical justification indicating why IPv6 
addresses from an ISP or other LIR are unsuitable.
----

So, you qualify for IPv6, if;

a. You already have IPv4 space.  Most people would consider it a barrier 
to entry for IPv6 if they already had IPv4 PI and couldn't get IPv6 PI. 
  This is consistent with the current policy and worded identically to 
the new language just implemented in 6.5.1.2.a.

b. You are IPv6 multihomed.  You will in all likelihood consume a route 
table slot anyway so you might as well have your owe IPv6 address space, 
and as much as you need so you only need to consume one route table 
slot. This is new policy, but there seems to have been a consensus for 
this concept and is worded identically to the new language just 
implemented in 6.5.1.2.b.

Lets skip c. for a minute, this is crux of the issue, I'll get back to 
it soon;

d. If you have technical reasons why addresses from an ISP or LIR are 
not suitable then you should be able to get address space.  This is more 
controversial, but there has been some vocal support for this and little 
if any vocal opposition.

Now back to the crux of this issue for this thread, clause c.

Clause c. is intended to set a clear and easy to understand threshold 
for single connected end-users to meet in order to receive an IPv6 
assignment.  It is intended to restate and be based on a minimum block 
size of /20 or 4096 IPv4 addresses from section 4.3.2.1 Single 
Connection, and a 25% immediate utilization of that block from 4.3.3. 
Utilization rate.  Giving you 1024 hosts, which I rounded down to 1000 
hosts.

I considered subnet counts, host counts, combinations of the two, or 
allowing one or the other. There are issues with all of the options.  At 
first I left this out completely, however this too creates an issue. 
So, I decided to go with a host count consistent with the current IPv4 
policy.

What is the issue with leaving it out completely?  Well, clause a. 
allows anyone who has IPv4 addresses to get IPv6 addresses, without 
clause c. a discontinuity is created at the moment of IPv4 run-out. 
Someone with a single connected network of 1000 hosts, who could have 
qualified to received both IPv4 and IPv6, after run-out may not be able 
to receive IPv6 addresses, at least without justifying why addresses 
from an ISP or LIR are not suitable for them.  The moment of IPv4 
run-out is not the right time to have a discontinuity in who can receive 
IPv6 address space.  Personally, I'd be happy to eliminate clause c. 
sometime well after IPv4 run-out has occurred, say a year or more.

What are the options from here;

1. Leave clause c. out completely.  I explained why I think that is a 
bad idea, at least until well after IPv4 run-out.

2. Don't use the word host, how about;

"c. By having a network that makes active uses of a minimum of 1000 IPv6 
addresses, or;"

3. Include IPv4 policy by reference instead of restating it. One of my 
goals in writing this policy was to eliminate direct references to IPv4 
policy in IPv6 policy.  But, you think that is better policy, then how 
about this;

"c. Qualify for an IPv4 assignment from ARIN under IPv4 policy currently 
in effect, or;"

Do you have other suggestions?

While writing this I realized I may have focused on the wrong clause of 
4.3.3. Utilization rate.  Now, I think it is more appropriate to focus 
on the second clause of that policy "A 50% utilization rate within one year"

So I think I prefer replacing clause c. with the following;

"c. By having a network that makes active uses of a minimum of 2000 IPv6 
addresses within 12 months, or;"

What do you think of that language?

Feed back ASAP please, the text has to be frozen soon.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================