ARIN Justified...

The way I read it, Mr. Elliott was not saying that there should be no
list of exceptions -- merely that such a list could never be complete,
so there must be language allowing for other exceptions.  I also believe
it reasonable that there be specifically *disallowed* exceptions.

One of the major complaints about the old policy from many quarters was
that it did not enumerate any of the valid reasons for IP-based
hosting.  With such vagueness, I personally dealt with significant
problems getting appropriate IP space from Exodus for customers of
mine.  The standard reply was, "per ARIN policy, you MUST use name-based
hosting to host multiple web sites on one machine."  (Note that this was
even before the policy was put in force.)  Personnel were also quoted as
saying, "You are allowed one IP address per machine."  I do not know
whether this was specific personnel being too enthusiastic in
enforcement, or the nature of the policy, but a clearly stated ARIN
policy could significantly reduce the suffering that an end-user
organization goes through in trying to acquire appropriate space to deal
with their specific issues.  It is this personal experience that causes
me to be against giving too free of a reign to upstream providers. 
"Maintainer discretion" leads to excessive difficulty for end users, in
some cases.  It should only be applied to additional, non-enumerated
exceptions.


My list of valid exceptions is as follows:

1) SSL sites

2) Those who use IP-based billing software, load balancers and/or
similar tools to measure, control and route bandwidth.

3) Hosters of multi-service sites, where separate customers are, to some
degree, isolated from each other, and where some of the protocols
supported do not have a reasonable analog to HTTP 1.1.  My company
provides such a service.  FTP, POP, Telnet, et. al., and custom services
do not have an HTTP 1.1 analog.  Standard proxies that, to some degree,
mimic this feature do not map directly to our infrastructure, since each
customer is totally isolated from every other customer (processes,
users, chroot jail, etc.).

4) Users of application servers that do not allow for name-based hosting
of multiple web sites.

5) If customer has significant conversion issues to comply with this
policy, allocations can be made, with a commitment to execute a
conversion plan.  Given the large amount of software across an
organization that could potentially be affected, conversion intervals
may have to be measured in years.

6) Other technical or business issues that can reasonably be justified,
either for temporary or permanent justification.

(It's possible that I've left out something, as I do not have all of my
notes in front of me)


Having written these exceptions, I want to make it clear that I still
have several major issues with reinstating this policy, with any
exception list.  They are as follows:

a) Search engines: To ignore search engine issues is unreasonable. 
Perhaps this can be addressed by a well-publisized announcement to the
world that in one year's time, name-based hosting will be a
requirement.  With a specific education campaign directed at search
engine companies and web hosters, this should be adequate to force non
compliant search engines to change.

b) Filtering and blocking software: Again, these issues can't be
ignored.  Unfortunately, the practice recommended for search engines may
not work here, as this software is often written to thwart sites (and
spammers) that are actively trying to bypass filters.  Enacting this
policy may make the task of filtering technically infeasible, which
would represent a significant problem, especially in light of laws
requiring libraries and schools to put filtering software in place.

c) Increased impact of DOS attacks: The issues here can be intractable. 
At the very least, there should be some acceptable ratio of domains to
machines, so that web hosters can compartmentalize the damage caused by
a DOS attack.

*******
d) LACK OF CLEAR EVIDENCE AS TO THE SCOPE OF THE PROBLEM WARRANTING THIS
POLICY:  No one has quantified the size of web hosters' contribution to
the depletion of IPv4 address space.  It is very troubling to me that we
are casting about for easy places to enact policies that will cost
businesses millions of dollars in conversion costs, without doing a
simple analysis of what the new policy might save.  I do not believe the
answer to this question is obvious.

I still firmly believe that there are other places to look that will
recover significantly greater IP space, while imposing lesser costs upon
Internet businesses and using only technology that is fully tested and
functional today.  One valid response from this committee would be to
say that we do not believe now is the right time to enact a stronger web
hosting policy, and that we believe other policies should instead be
investigated, such as a policy to reduce ISP IP usage by forcing the use
of private IPs and NAT.  It is absolutely within the scope of this
committee to make such a statement.  

Shouldn't we go for the biggest consumers of IPv4 space first??
-- 

				     -- Bill Van Emburg
				     	Quadrix Solutions, Inc.
Phone: 732-235-2335, x206		(mailto:bve at quadrix.com)
Fax:   732-235-2336			(http://quadrix.com)
		The eBusiness Solutions Company
-------------------------------------------------------------------
Clayton Lambert wrote:
> 
> Agreed.
> 
> I don't think there should be a "list" of exceptions.  There should be
> maintainer discretion and escalation to ARIN if the service provider (end
> user) feels he is getting the shaft from the ISP.
> 
> If you have a need for addresses, document the need and provide any
> supporting technical justification.  Exodus has a tough policy, but it is
> not restrictive in that we will provide you with the address space that you
> need, it is just that we require the need to be documented beyond an email
> that says "I need a /22 for a network of 75 webservers."  Don't laugh, I get
> stuff like that all the time.
> We have contacted and made recommendations to many large scale vendors in
> the past (and we continue to make efforts in this regard) in support of
> HTTP1.1 support, as well as trying to push them to support efficient IP
> usage.
> 
> So while it may be difficult to get a large and shakely justified block of
> address space, it is not difficult (beyond the documentation requirement) to
> acquire address space that is justified.
> 
> -Clay
> 
> -----Original Message-----
> From: Stephen Elliott [mailto:stephen at hnt.com]
> Sent: Thursday, January 04, 2001 1:47 PM
> To: Clayton Lambert; Virtual IP List
> Subject: Re: ARIN Justified...
> 
> :-)  The reason I mentioned Exodus is because we are a customer of
> Exodus, and in my opinion, the policy is too restrictive.  And the
> statement was directed at the fact that Exodus hosts many companies that
> are in the business of hosting websites, not Exodus as a company.  As I
> have stated in earlier postings, simply clamping down and restricting
> virtual web hosting is not the answer.  Any list of justifications, no
> matter how much thought went into it, will not cover every possible
> reason for needing the IP's.  Documentation is a great thing, just the
> fact that someone has to sit down and write out a list of machines that
> need IP's will deter most people from requesting extra IP's.
> -Stephen
>