Search Engines/IP restrictions/policy changes

[Ted Pavlic]

> Like I said.  In that case it wasn't so much the technology that was the
> problem, it was the support.

My argument now is that changing to name-based and suggesting webhosting
providers use technology which has expired in IETF DRAFT form is not
appropriate because the technology just isn't ready.

When the conversion was needed to be made from static to dynamic IPs, the
technology DID exist and it was just a matter of upgrading to it.

> This is no different than the conversion to dynamic dialup IPs.  There
> were several older clients in the market that didn't support dynamic IPs,
> they were instantly obsoleted by the change and technical support had to
> handle the load.  The server support exists for plan old HTTP, the set of
> server software that doesn't support it will be obsoleted by the change.
> That's a normal effect of working in technology, if you don't continue to
> improve and adapt, you won't be around long.

I just have to argue that the "web" is made up of much more than just HTTP.
My "web" consists of HTTP, HTTPS, FTP, and all of the enhancements to each
one of those (like FrontPage and the various schemes which help make web
servers run more smoothly).

If HTTP servers don't support HTTP/1.1, I definitely think that those
servers should be upgraded. However, even the most upgraded HTTP server is
not going to support SSL, which seems to be a very important thing in
modern-day web commerce, with name-based hosting. That same server is going
to require a great deal of extra work to support FTP and FrontPage and who
knows what else.

A webhosting provider with thousands of clients all who have varying needs
is crippled by having to switch to name-based hosting.

Necessity is the mother of invention... and I do agree that there needs to
be more invention on the Internet to support the great IP needs... but I do
not think it is right for ARIN to create sudden necessity. I feel it would
be better for ARIN to work with the IETF to develop new technologies which
make this conversion possible and *THEN* force the changeover. Right now it
feels like ARIN is pushing webhosting providers over the edge of a cliff and
only giving a parachute to those who specifically ask for one and have good
enough reasons as to why they need help to keep from perishing after the
fall.

> > * How about FrontPage Server Extensions?
> > * How about SSL?
> Those sound like perfectly reasonable and acceptable exceptions to the
> policy.  (Actually if I had my way, and if what I understand about
> FrontPage is accurate, I have little sympathy, when a protocol is designed
> outside of the standards process it deserves to be broken.  Of course, I
> fully understand the business constraints behind it and know that that's
> not a reasonable course of action).

I agree that FrontPage doesn't (in theory) deserve much influence in this
matter. Microsoft and Ready-To-Run software have done a horrible job with
that software. Without name-based webhosting FrontPage causes a plethora of
problems. I've been on MS and RTR's tails for years about this software, but
I'm often only placated by a VP or ignored completely.

However -- as you say you understand how impossible it would be for me to
say to my users that I just can't support FrontPage anymore as it doesn't
meet ARIN standards. Rather than MS getting a great deal of complaints, I'm
sure I would.

I'd upgrade completely to WebDAV, but that would force my users to resort to
make their websites independent of the FrontPage extensions, which would
still be a bad idea.

> > * What about the damage this does to load balance infrastructures
already in
> > place?
> They can adapt.  There are many load balancing devices on the market that
> can look deeper into a TCP session and load balance, traffic shape, or
> traffic redirect based on this sort of information.  Again, progress can't
> be made without breaking a few things at some point.

That's true. Really I think IP (even v6) needs to be modified to make these
sorts of things a lot more doable. Another layer of abstraction which would
carry host information could be added which would make all TCP and UDP
services avialable on a name-based level.

Already policy routing exists, but I think that even policy routing needs to
be able to look closer at a packet to decide exactly what kind of packet it
is. I don't think that processing the current information being passed on
the Internet could be done fast enough to provide efficient name-based load
balancing/etc.

A standard needs to be made for name-based transactions. Rather than making
HTTP/1.1 smarter and dragging the rest of the services along with it, it
would be better to reform the whole Host-to-Host transport layer to allow
all applications protocols to be able to work on a name-based paradigm.

> > * What about non-HTTP/1.1 compliant browsers?
> They just need an upgrade.  It should be easy enough to identify a
> non-compliant browser and send an informational page sending the user to
> an upgrade site.

It is easy enough -- and that's being done. Apache's "ServerPath" virtual
host matching provides a temporary solution that allows those browsers to
browse those websites without sending "Host:" tags as long as that website
doesn't link to any absolute or "/...." pages. Every link must be VERY
relative.

> > And, as you said, ARIN has been pretty vague about what "exceptions"
are.
> Yes, but I think they have to be.  As soon as exceptions are documented,
> all of a sudden everyone needs the exception.

I just don't feel much research was done. ARIN should have been able to
provide more information.

The thing is -- medium-to-large ISPs will survive the ARIN changes. Those
medium-to-large ISPs can afford the research and development necessary to
provide grade-A web hosting. Smaller and less experienced ISPs will suffer.

Like an Internet tax, I feel that the ARIN policy changes may have been too
much influenced by those interested in the proliferation of big business and
the death of small business.

> > Every cable provider I have used and evaluated has used DHCP, but they
are
> > giving out real Internet addresses which makes no sense to me.
> I should be a bit more clear.  Yes, they use DHCP, but as of the last time
> I checked (and it was admittedly a while ago) they assigned the same
> address to a customer all the time.

My current cable provide often provides the same IP to each user, but that's
just the nature of DHCP.

Once a user's DHCP lease is up, they release their IP and ask for a new one.
Usually at that time they get the same IP back. That's just one of the fun
things about DHCP.

I know of many people who use dynamic DNS updates to advertise their new IPs
whenever they get one. That allows them to have named websites on the
Internet without paying for a static IP (even though this is against cable
policy).

> To pick on the largest, @Home, according to whois, is allocated
> 35 /16's.  According to their web page they just passed 2 million
> subscribers in August.  If my math is correct, that's almost 2.3 million
> addresses in all.  To your point, the largest of the web hosting
> companies, Verio, has about half a million web sites.  Assuming they are
> all hosted on individual IPs, if some sort of dynamic addressing at @Home
> saved only half of their allocation, that's twice as good as requiring
> Verio to put ALL of their web sites behind a single IP, which seems quite
> unlikely because of the exceptions you've mentioned.

You're right -- 35 /16's is just under 2.3 million addresses.

And expanding on your point, a GREAT deal of the webhosting providers who
are affected by the ARIN changes provide *MUCH* less than the 500k websites
you mentioned Verio provides. Will it really provide many more addresses to
the world to pick on the webhosting providers?

Further expanding... @Home is a large provider, but is one of MANY. There is
a greater threat to IPv4 addresses being wasted by providers like @Home than
there is being wasted by webhosting providers.

I should hope issues like these are brought up in October.

All the best --
Ted