Search Engines/IP restrictions/policy changes

There are several web-systems vendors that are working on methods to handle
SSL and other traditional non-HTTP1.1 compatible protocols, via load
balancing devices.  I am not implying that we should force webhosting
providers (or other services-providers) into vendor-specific solutions.  But
I think it is important to support the idea of host-header compatibility.
Customers of webhosting providers typically "own" the URL, not the IP
address.  The URL is something that can be utilized in embedded programming
and it allows for scalability and modification of infrastructure that is not
otherwise available if the IP address is embeded into software (as an
example).  And for the webhosting provider that indicated (in a previous
email) that I was biased against the webhosting community, please realize
that I am very neutral with respect to these policy discussions.  In fact,
the concept of URL based services-hosting is somewhat detrimental to my
company's core business: Colocation.  Think about it, if you base everything
on names, it is no problem (effectively) for you to leave my company (as a
colocation provider) and for you to go to one of our competitors.  If you
are embedding (or even just implementing large, complex hosting solutions)
IP addresses in your configurations and infrastructure, or even
software...You are going to be MUCH more inclined to remain at my facility.
So, be assured that my perspective on this topic is very much fucused on the
idea of conservation of usage.

Clayton Lambert
Exodus Communications


-----Original Message-----
From: bross at ogre.atlanta.netrail.net
[mailto:bross at ogre.atlanta.netrail.net]On Behalf Of Brandon Ross
Sent: Thursday, September 07, 2000 2:35 PM
To: Ted Pavlic
Cc: Clayton Lambert; 'Charles Scott'; policy at arin.net
Subject: Re: Search Engines/IP restrictions/policy changes


On Thu, 7 Sep 2000, Ted Pavlic wrote:

> > > 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?
>
> I'm speaking specifically about SSL and TLS. HTTP/1.1 supports name-based
> hosting, of course. However it is not currently very possible to support
> name-based secure hosting.

Ahh, gotcha.  Like I said before, when I read webhosting, I read HTTP.

> ARIN gave these references with respect to secure webhosting:
>
> http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-https-03.txt
>
> http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-http-upgrade-05.txt
>
> http://info.internet.isi.edu/in-notes/rfc/files/rfc2246.txt
>
> Two of those are EXPIRED IETF **DRAFTS** which should never be used for
> reference. Those particular drafts suggest a way for name-based hosting to
> exchange the name-based information BEFORE the TLS handshake and then
switch
> to TLS once the host has been established.

I completely agree that it is quite inappropriate to reference ID's at
all, regardless of whether or not they are current.  ARIN folks, you
should seriously consider removing those links!

> That's why I think that there needs to be some abstraction layer between
the
> actual services that name-base hosting affects and TCP. An easy way for
web
> servers, FTP servers, load balancers, etc. to see exactly where the
traffic
> is going. Unfortunately, without sending bytes and bytes and bytes of
> variable length information, it's almost as if we need another set of IPs
on
> top of IP. <sigh> Send one IP with a four-byte OIP (Other-IP) which looks
up
> on some server somewhere and ends up resolving the 20-byte name. :)

<sigh> is right.

> > > 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.
>
> I didn't mean to sound like I was talking down to you; I apologize if it
> seemed like I was.

Didn't take it that way, sorry if my reply seemed like I thought that you
seemed to be talking down to me.  ;-)

> Considering a great deal of cable subscribers stay on-line 24/7 or
> close-to-it, I think it would be difficult for providers to keep a less
> than 1 to 1 ratio of IPs to customers.

I think that's a misconception.  Whenever I've visited non-technical
friends at home, I've always found that if they aren't using their PC,
they turn it off.  I would be willing to bet that at least half of them
are turned off at any particular time.

> That's why I thought that handing out 10./8 or 172.16./16 (or both!)
> using the existing DHCP would be a decent idea.  The only thing the
> cable providers would have to worry about is the latency doing the NAT,
> and that could be taken care of a number of ways.  People who wanted
> static IPs could easily be setup with one-to-one NAT. Just like when
> dial-up ISPs were told to use dynamic addresses, this sort of conversion
> involves EXISTING technology... and I don't really think would require
> that much effort to convert.

I completely agree, but I'm agnostic of the method they use to go dynamic.

> Note that the local DSL providers in my area actually provide STATIC IPs
to
> their customers, from what I remember. I have to wonder if that's within
the
> current regulations.

I would hope not, but I suspect there isn't a policy on it, there
certainly isn't a documented one I can find.

> > 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.
>
> Still -- remember that in ARIN's policy changes not only are they forcing
> webhosting providers to move to name-based hosting, but they are expanding
> the largest block an ISP (like @Home) can allocate at one time from /14 to
> /13. To me it looks like they're taking the IPs (even though they probably
> can't free up THAT many from webhosting, IMO) from webhosting providers
and
> giving them to cable ISPs.

I really don't see it that way.  It's not like we're out of addresses yet.
I do see it as focusing efforts in the wrong priority order, however.

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