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!