Search Engines/IP restrictions/policy changes

On Thu, 7 Sep 2000, Ted Pavlic wrote:

> > 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.

I'm not sure exactly what you are referring to, but RFC 2068 in section
5.1.2 certainly seems to describe the method of sending the hostname with
the GET request.  RFC 2068 is on a standards track.  Am I missing
something?

> 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.

Agreed.

> > 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).

So perhaps we have a semantic problem here.  To me, the term "webhosting"
in ARIN's policy means plain HTTP, hot HTTPS, FTP, or anything else, but I
do see your point.  I would suggest re-wording the policy to say HTTP
hosting.

> 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.

Well, part of the problem is that the information needed isn't, and really
can't be, neatly contained in a single packet, you have to capture the
first x packets in a session to capture things like URL and whatnot, which
means doing some TCP spoofing, however the technology is there and is
getting better by the minute.

> > > 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'm well aware of how DHCP works.  The point that I was trying to make is
that, at least the last time I looked, there was a 1 to 1 ratio of IPs to
cable customers, thereby guaranteeing that they would always get the same
address.

> 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?

I do think the savings available by using host based webhosting is
significant, but I'm pointing out that some flavor of dynamically
addressing cable modems would provide even more savings.

> 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 agree, but in all fairness, there are many web hosting companies as
well.  I point out the largest and assume that they come close to
representing the rest of the industry, I could very well be incorrect.

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

I'm sure they will be.  Better yet, go to the meeting and make sure they
are.

Brandon Ross                                                 404-522-5400
EVP Engineering, NetRail                           http://www.netrail.net
AIM:  BrandonNR                                             ICQ:  2269442
Read RFC 2644!