ARIN: No More IP's For IP-Based Virtual Hosts 249
Mike writes: "ARIN (the guys who hand out IP addresses) has a policy change where they will no longer allocate IP addresses for IP-based virtual hosting. They are expecting everyone to move to name-based hosting now. ARIN is solicting comments to their public policy mailing list: ppml@arin.net. What do you guys think? Is name based virtual hosting ready for prime time?"
host header is fine.. unless.... (Score:4)
Host header, as dirty a word as it is, seems to work fine (we use Micro$oft IIS, ugh) - oh. there's one sticking point. You cant use bundle per-virtual-server anonymous FTP access on the domain name to clients. This minor problem aside, I think it's a good thing. The number of borign web sites we have wasting IP addresses haunts me every time I open that address database...
IPv4 is the reason for this, I'll wager (Score:4)
I predict IPv6 sees a return to ip-based virtual hosting.
Name based hosting isn't a bad idea though, since most people use a browser that supports it nowadays.
Re:what does this mean? (Score:4)
Yes and no. (Score:5)
I think moving to name-based virtual servers is a good idea in general, but the https problem needs to be resolved first.
Alex
A few problems (Score:2)
Secure websites need IP's however.... (Score:3)
My letter to Arin:
Sure you can do web hosting with named virtual hosts, several hundred sites per IP, and it works fine. But what happens when sites start hosting more and more SSL secured websites (i.e. https://store.example.org/)? SSL works at the transport layer, you cannot host multiple domains off of one IP address. Will an exemption be made for this (i.e. I need a CIDR because I want to host a lot of secure websites?). Making it harder for people to implement SSL secured websites will only hurt the Internet, making it a much less secure place to do business, and ultimately stifle growth (well a little bit anyways). Thank you for your consideration.
Kurt Seifried, Senior Analyst
SecurityPortal, your focal point for security on the net
http://www.securityportal.com/ [securityportal.com]
IP-based virtual hosting still needed (Score:3)
For example, the hosting provider I work for sets up dedicated Apache installations for each customer -- and this policy gets hailed as heavenlike by our customers, since they're free to install any extensions they could possibly need (or even completely switch servers). With current technology, it's tricky at best to implement something like this with name-based virtual hosts. We would need to run our private address space internally and then have a HTTP-level metaserver to distribute the HTTP/1.1 name-based queries to the right servers.
Also gone are access lists on the router level. Dedicated ftp/smtp servers listening on the same IP as the site. I could go on forever.
To the credit of both ARIN and RIPE (ARIN's equivalent in Europe), they seem to be on top of this. If a company DOES use a single Apache for a thousand sites, I think it's justified to ask them to use less than a thousand IP numbers. However, this is a grey issue, and the organizations have been understanding in situations where there really is a need for IP-based virtual hosting.
IP numbers are not assigned for administrative ease, and that's ok. But the issue of name-based or IP-based virtual hosting isn't about convenience yet. It's still about functionality.
Re:IPv4 is the reason for this, I'll wager (Score:1)
SSL? (Score:2)
As far as I understand SSL, you must use virtual interfaces to host SSL web servers. How does the policy change affect these servers?
Also, TLS is supposed to fix that. Which browsers implement TLS correctly?
© Copyright 2000 Kristian Köhntopp
Does this work with old clients? (Score:1)
Re:Yes and no. (Score:1)
No, because of SSL (Score:5)
In other words, a secure site requires an unique IP address.
So as a general policy it's pretty dumb, unless exceptions are made for secure sites, and from the announcement it doesn't seem so.
Really? (Score:1)
RIPE has done this for years (Score:3)
The fact is that the Host: header has been a part of HTTP for a very long time now, and the number of HTTP clients which don't support it is trivially small - certainly not enough to justify the vast acrages of IP space it eats up. IP virtual hosting is an idea who's time has gone.
Are you sure?... (Score:2)
Re:Yes and no. (Score:1)
I traced it to the fact that we are using name-based virtual hosting: In our Intel 7110 SSL accelerators (nice hardware, but one nasty lingering bug) one cannot assign 2 SSL certificates to one IP address in the mapping table. I expect the same to happen when using software SSL under Apache/mod_ssl or anything else.
So now I'll have to somehow pull those 2 cobranded sites out of name-based hosting and into IP-based, add to the DNS tables, modify the Cisco LocalDirector tables, and fix the Intel 7110 mappings. That's going to be ugly.
IMHO for large ISPs that use a lot of SSL, name-based hosting is not an option. Also consider the fact that Verisign has finally simplified somewhat the process by which one can request massive numbers of SSL certificates, and with the new SSL hardware accelerators that came onto the market it becomes rather easy to aggregate all those certificates and manage them from one central point.
They should reconsider their expectations that everyone move to name-based hosting. For some it's not an option.
Re:Does this work with old clients? (Score:5)
This means that all requests from your browser to websites will look something like this:
GET
Host: mydomain.dom
<nl>
This is kind of similar to using a proxy; you need to tell your browser to use a proxy. The browser will then send 'absolute URLs' instead of 'relative URLs' as in my example above. That way, the proxy knows which server you are really trying to reach.
I think that name-based virtual hosting is a great thing (I run 3 domains off my single IP).
Unfortunately, I can only run 1 SSL-capable secure website on that same IP address since the SSL handshake needs to complete before the request is interpreted at the HTTP level.
And I have another issue: I want to run a "reverse proxy" (multiple physical webservers, possibly running different OS's) with name-based virtual hosting. I haven't found a way of doing that [with Apache] yet.
--
Greetings,
Ed.
IPv4 adresses running out (Score:1)
Re:Yes and no. (Score:3)
Where I work right now, SSL is one of the biggest problems, we have 5 servers here running host-header based virtual hosting, but we have had to set aside relatively large chunks of our IP space to cater for the customers who want SSL.
To top this off, the SSL-hosting IPs can only do one thing each, and cannot be accelerated by our caching system
So
I would love to do name based SSL hosting
Not as bad as it seems... (Score:2)
Anyway. This policy isn't near as bad as it seems. True, SSL websites require their own IP address, since SSL certificates are bound to both name and IP, and the SSL handshake verifies the certificate before it exchanges hostname data. But, the majority of websites out there are name-based. I host 5 websites on my one machine. My roommate hosts 7 on his. I know of companies with -thousands- of sites on one machine, one IP. HTTPS gets moved to a separate box (which it would be anyway, for security reasons), with IP aliases. So this doesn't affect daily operations near as much as people think it does.
Of course, FTP is also affected. But it isn't something that can't be overcome by coders. I mean hell, it should be as simple as it was to introduce name based virtual hosting for webservers. Or, just move your ftp files into HTTP, since most people just click links inside IE/Netscape/etc.
As someone who has a request for a
Re:Yes and no. (Score:1)
By the way is this really a problem? Wouldn't you want a dedicated server anyway to host your site if it has to hanlde confidencial data? I don't like the idea of a Web-shop running on a 100+ site web-hotel, storing my credit card number - SSL or no SSL
Sorry but... (Score:3)
Virtual hosting maybe ok for general public web-pages, a.k.a. a step-up from geocities. But for people who provide web servicing to many different entities which all wish to have either SSH/FTP access to the web servers and SSL services this provides a problem. I currently provide services to only a few people but I plan to get a larger subnet within a year, the people I provide services for wish to have these services and in most cases the ability to do reverse lookup for security reasons. Being denied additional IP-space because of a reason such as web-hosting methods, seems to be slightly ludicrous.
we've been doing it for years now (Score:1)
Sure. We're running almost all of our webhostings off name-based virtual servers now.
The only thing where you don't have a clean solution are secure servers, as the SSL authentication comes before the server is told which virtual host the client wanted to reach.
It's really time that ARIN catches up with RIPE on its IP address preservation policy.
Re:Does this work with old clients? (Score:2)
It's fairly simple - the browser request makes a GET, then follows by passing a series of headers:
GET / HTTP/1.0
Host: hostname.domain.tld
User-agent: Mozilla
<blank line to terminate request>
Then expects the return from the server.
So, when you run off to http://slashdot.org/comments.pl, it's performing:
GET /comments.pl HTTP/1.0
Host: slashdot.org
User-agent: Mozilla
<blank line to terminate request>
Both HTTP 1.0 and 1.1 implement this, if you want to read the RFC 1945 [ietf.org] and RFC 2068 [ietf.org] for information on HTTP 1.0 and 1.1 respectively.
Re:Does this work with old clients? (Score:2)
You are correct (Score:1)
The link to the article explains the policy changes in better detail.
-Mike
No Problem (Score:1)
ftp (Score:2)
However, the command for name-based virtual hosting in FTP is not even in an RFC yet (it is included in the latest drafts for a new RFC though, along with MLST).
However, even when that RFC is passed, it will take a while until it is implemented in servers and clients (and a change IS required on both sides).
Patches for wu-ftp and the netkit ftp client exist (sample implementations...) - but I can't see a certain large company that refuses to open-source any of their products implementing something just because it's an RFC or because it would make sense... And while that company controls one of the most commonly used ftp clients...
Err... not the nature of the problem... (Score:1)
Verisign certificates are assigned to what they refer to as a Common Name. A Common Name is pretty much just an FQDN. (www.foo.bar)
The SSL session is begun before the hostname is known. The problem then becomes that the webserver has to know what certificate to present before it ascertains the hostname request from the client. If the Common Name in the certificate presented differs from the portion of the URL between the
It can be done through either IP based virtual SSL hosts or name-based virtual SSL hosts on differing ports.
-Nev
Re:Yes and no. (Score:1)
Re:Yes and no. (Score:2)
> you want a dedicated server anyway to host your
> site if it has to hanlde confidencial data? I
> don't like the idea of a Web-shop running on a
> 100+ site web-hotel, storing my credit card
> number - SSL or no SSL
well, you can either secure the system hosting this "web-hotel" completely and partition all the users, or you can arrange to store the confidential details on a specially designed and secured repository outside of that server
or, you can pay us a lot of money and we (and most of the other ISPs in the world) will build, install and host a dedicated server for you
This is a good point, but you have to choose to do something that is feasible, sensible and cost effective. You have to make a decision about which trade-off's to accept. (just like anything else really)
They're only talking about WEB hosting... (Score:1)
Certainly not. (Score:3)
What you have to realize is that while virtual based IP adresses are useful in some cases, they are in fact, not secure. The cases that spring to mind where IP-based virtual hosts would be useful would be for DNS server(s). Say Company X can only afford a single rackmount unit. They could configure their box, with virtual interfaces (eth0:1 etc under Linux, or equivalents under NT or other operating systems), and use one box for running 2 name daemons, each bound to different "virtual" IP adresses. But for webhosting?
For Webhosting, it actually makes sense to make use of Site proxying such as Apache provides. Typically, how this would be set up is this:You'd have a Firewall/proxy box sitting on a single legal (routable) IP adress. You'd run Linux, BSD, or (insert any other operating system), and use that box to "NAT" (Network Address Translation) to seperate boxes behind that box - or even virtual interfaces on the same box - which would, undoubtedly, use non-routable addresses (illegal IPs). This way, you could have Apache proxying your site from 197.x.x.y (your legal IP), to the illegal IP running on your "internal" box.
So when a user types in "www.foo.com", it hits 197.x.x.y, where Apache is running, and Apache, with the VirtualHost directive (VirtualHost 197.x.x.y), uses the "ProxyPass" Function to redirect the request to the site in question, running possibly on your internal box. So you could go to www.foo.com:80(default), which would really go to 192.168.2.10:8080, running a Zope Server, and www.foo2.com:80, would, possibly go to another box running Apache on 192.168.2.11:80 - whatever you want, literally.I think this is where Arin wants administrators to start going, and I've been doing it for ages. It works well, and for that - the authors of Apache, Linux, and the many open source utilities that support those Applications must be commended. If you aren't doing this, try it. It's quite brilliant. The way it all fits together, is an echo of the very thoughts that inhabit the minds of the thousands of individuals using - and not using, (but perhaps, subconciously using, or wanting to use) these systems. For the code itself is like a Christmas present. Yes, a year - two years. 10,000 years. In the blink of an eye, the coding time. Think about the implications of 10,000 years of coding tiem in one blink of an eye! Indeed, we live in strange times.
Re:Yes and no. (Score:1)
AussiePenguin
Melbourne, Australia
ICQ 19255837
Re:Sorry but... (Score:1)
-Nev
Re:Yes and no. (Score:1)
We really do need a standard to hack into SSL to say what hostname it wants.
AussiePenguin
Melbourne, Australia
ICQ 19255837
How to do it with Apache... (Score:3)
I just set it up for all my hosted pages, and it works beautifully. It took less than 10 minutes.
In Belgium and EU in general, we have no choice. (Score:3)
When I started publishing web page here (I live in Belgium, EU), every vHost had his own IP.
In the meantime, I moved my web pages to web hostings to Jumpline [jumpline.net], who give an excellent service and an IP per domain name. It was a lot cheaper service thant EU's one at the time.
A few days ago, I had the discussion with 3 of the most important ISP in Belgium: for some reason, I wanted to vhost my pages in Belgium again (the price is now roughly the same than in the US). My idea didn't last: name-based hosting is the rule here, and they looked at me as if I was a martian when I told them I wanted my own IP by vHost.
In a more general context, I'd really like to see an quick adoption of IPv6: more and more ISP's here rely on NAT (whith all the problems it can give) and host hundreds of sites by IP.
That's definitely not a Good Thing.
Just my thoughts
Stefano
--
X.509 certificate cis ritical for link security... (Score:2)
The only thing preventing this is the certificate: that way, a compromised host on the path cannot pretend to be the server, as it wouldn't have the necessary certificate to do pretend to be the server.
Re:Finally this madness ends. (Score:2)
NAT is evil. Kill it before it multiplies.
NAT breaks end-to-end transparency and IPSEC. If you want a firewall, buy or build a real firewall.
Re:Finally this madness ends. (Score:2)
Use NAT. Then you've got some sort of a "firewall" at the same time.
NOOOOOOOOOOOOOO!!!!! NO! NO! Please don't use NAT. It sucks! It sucks! Aaaaaarggggggh.
Sorry about that. Seriously, though: NAT is not a security measure. It can imply some firewall functionality because there are many things a NAT-box just can't do, but that doesn't make it any less "security by obscurity".
NAT has been causing me so many problems this last year. It's nothing more than a clever but nasty hack to keep IPv4 up and running. So is name-based virtual hosting, really.
We really need to move to IPv6 and be done with all this nonsense.
Re:RIPE has done this for years (Score:2)
Actual statistics show a huge number of strange hosts like MSIE-2.x and 3.0 and other similar abnormalities. It is strange but true. There are lots of people with NT4.0 with no service packs applied and IE not installed out there. There is a lot of software like junkbuster that reports an IE when asked for browser as well. The actual percentage depends on the target site but it can go as high as 20% of apparently non-host compliant browsers.
Also, you are mixing RIPE general policy with host policy. RIPE is assuming this stance on all addresses. You have to justify anything above /31 by default with them. If you are a big ISP they may raise this so called assignment window but not by much. This is quite different compared to the US.
And yes you can get IPs for virtual hosts from them. You just need to know how to write your requests.
Re:Next down the road... (Score:2)
It's time for the Internet community at large to make a decision: are we going to keep applying these little fixes at the bottom end of the totem pole, such as requiring Name Based virtual hosts, or are we actually going to fix the problem? We can fix it short-term by reallocating some of these huge grants made long before the Internet became popular (which is politically sensitive to do), or we can fix it for a good long while by migrating to IPv6.
My box talks IPv6, how about yours?
---
These stories are sad (Score:2)
Why is this sad?
It's sad because there shouldn't be any virtual shortages.
Whether this is a bureaucratic, technological, societal or other failure is debatable.
In this particular case name-based hosting may be a perfectly valid workaround, but that's not the point.
The point is that if we allow these shortages to continue, then the internet and related technologies will miss alot of their potential. It will simply be another case where only a few can afford access to scarce (virtual) resources.
And that really will be sad.
Dosn't affect me. (Score:2)
To conserve IP space I use a l4 switch to shunt port traffic to different virtual servers, so all a domain's services may be on the same IP, but split over different boxes. So hosting virtual www IPbased is simply a side effect.
--Dan
Re: No, because of SSL (Score:3)
What about high-traffic Web sites? (Score:2)
Just a small point: if you have a Web site that will be handling tons of traffic, and need multiple IP addresses just to handle the large number of TCP connections, how is the new rule going to affect that? I'm in particular thinking about sites that use multiple servers with traffic distributors.
Or is this supposed to fall in the ill-defined "list of exceptions"?
Re:Does this work with old clients? (Score:2)
Squid in accelerator mode should do this. You will have to tell it to use the host header though.
37% of browsers use HTTP/1.1, the rest use 1.0 (Score:3)
And I think that this means that the net is not ready to abandon IP-based hosting.
Re: No, because of SSL (Score:2)
Would you trust such a site? It's possible that some user seeing a ":portnum" part in the URL would consider (or at least fear, which is more than enough) the site to be a forgery and leave for safer harbours.
Will someone please think of the shell providers!! (Score:3)
Also this will probably come down hard on ISPs like Demon Internet [demon.net] who give static ips to dialup users. This was a bugger originally since they used to use smtp for mail delivery which wasn't easy on Macs and Windows, but still a very nice feature.
How to take what you need (Score:2)
It's no problem. When I need an IP address, I'll start doing business as 123.45.67.89, trademark it, and sue the current holder of the address for trademark violation and petition the court to order the holder to turn the address over to me.
For crying out loud, there is an infinite supply of integers; we shouldn't be squabbling over them. Bring on bigger address fields already.
By the way, do corporations report their IP address allocations as assets? E.g., the early network participants got big chunks of space. Digital Equipment Corporation (since purchased by Compaq) had all IP addresses 16.*.*.*. That has some economic value now. Maybe the tax assessors would like to take a look.
Name-based hosting (Score:2)
If you're setting up a NameVirtualHost setup, and you're truly worried about people hitting the wrong site with an older browser, then you set up a bogus "primary" site on your system (primary meaning, the one that you get if the client browser doesn't indicate the name of the host it's looking for) that contains nothing but links to the names of NameVirtualHosts that exist there. For an example of this, you could look at this site [165.254.158.24] which I've linked here by its IP address instead of its name.
--
Re:A few problems (Score:2)
Things this fucks up (jails, monitoring, etc.) (Score:2)
* jails. For some customers, we provide a virtual OS "jail" using FreeBSD. This basically assigns a new copy of FreeBSD to an IP, with it's own
This very nicely keeps sites with "suspicious" cgi's and such from effecting other sites on the same server, as well as lets them maintain accounts. Takes some disk space however.
* traffic monitoring. Nothing like just watching trafshow to see who is eating up what
* Intrusion Detection. With snort, your only going to see that "Yes, they tried to sploit my webserver", not which of the 100,000 virtuals on it. This actually isn't too bad, you can always read the tcpdumps.
* Virtual ftp sites. Luckilly, theres a new RFC which allows you to do "host based" ftp serving. I haven't seen anything support it yet.
* DoS attacks. If you host some "contreversial" sites such as www.godhatesfags.com, it's good to know why when someone tries to force an OC3 worth of UDP packets down your T1... If your weak, you can just remove the IP and hope it stops
* SSL stuff. What we did to get around this for now is a secure.ourdomain site, with subdirectories for ordering pages. This of course, doesn't sit well with bigger customers however.
Just some observations.. helixblue
Re:Dosn't affect me. (Score:2)
Don't ask me how they do it, all I am telling you is that your post is innacurate.
Re: No, because of SSL (Score:2)
---
Non-web. (Score:2)
Re:A few problems (Score:2)
Re:37% of browsers use HTTP/1.1, the rest use 1.0 (Score:2)
Re: No, because of SSL (Score:2)
-Chris
Re:RIPE has done this for years (Score:2)
> host policy. RIPE is assuming this stance on
> all addresses. You have to justify anything
> above
> big ISP they may raise this so called
> assignment window but not by much. This is
> quite different compared to the US.
This isn't true. Most RIPE local registries have
assignment windows of at least
/23. You don't need any explicit approval for
these, but you still need the documentation
because they randomly audit your decision making.
Andrew
Re:A few problems (Score:2)
Name-based virtual hosts work because an HTTP 1.1 request includes the hostname. FTP requests don't. It's as simple as that.
Chances are your isp is doing something like I used to have to do, with the ftp server CNAME'd to the web server, and the web server ip based. The reverse works just as well but looks silly.
Most people running a web site don't actually need an ftp server for the public tho, and just use ftp to upload their web page. In that case, they should definately be using name-based virtual hosting, and the isp should be up front and honest and not even bother to tell them they can ftp to their "web server" and just tell them to ftp to web-farm.isp.com or whatever.
The business model this is going to kill is the one wherein the service gives the customer a whole virtual machine. That *Definately* requires an ip per customer.
this problem has already been solved. (Score:4)
But this problem has already been solved: private property and free markets. Just auction IP addresses through a central exchange, all IP addresses, including the sacrosanct class As. You want an IP, or a block of IPs, you pay for them. How much? Who knows, who cares, we'll find out when they go up for sale.
Some regulations are required: don't allow monopolies or cartels; declare IPs fungible to allow central administrators to reallocate or consolidate blocks for routing purposes.
Problem solved.
Problems and prejudices (Score:2)
I wonder how much of their opinion came into play here.
Furthermore, the real problem is not the webhosting allocations, but the host allocations to large, workstation-based networks. I know of more than a few companies who have
It does not make sense to choose a website, ftp site or any other Internet service host over a workstation.
Much to their credit, though, ARIN has actively sought out unused IP space from companies, universities and other organizations assigned A and B space in the past.
Bad idea (Score:2)
Why do people seem to insist that "The Internet == The World Wide Web" anymore?
It reminds me of The Corinthians [slashdot.org] website issue. Just because a guy doesn't have a web page on a domain, or that page hasn't been updated for a while, The Powers That Be consider the domain unused. (May not be the exact case with this example, but in general that seems to be the opinion anymore.)
Seems like nowadays, if you're NOT running a high-profile website on your domain, you just aren't officially "using it."
EMail? What's that? FTP? CVS? Telnet? SSH? Huh?
-=-=-=-=-
What about non-anonymous FTP? (Score:2)
<O
( \
XGNOME vs. KDE: the game! [8m.com]
Re:proftpd can work with virtual hosts (Score:2)
Read the FAQ [proftpd.net].
-=-=-=-=-
Re:Does this work with old clients? (Score:2)
Protection from DDOS? Not likely. (Score:2)
It seems like if that machine was ever subjected to a dDos or went down for some reason
A well-designed Distributed Denial Of Service is impossible to distinguish from normal heavy site traffic <cough>Slashdot effect</cough>.
<O
( \
XGNOME vs. KDE: the game! [8m.com]
Re:Finally this madness ends. (Score:2)
Re:IP-based virtual hosting still needed (Score:2)
Also, reconfiguring and restarting an Apache with one site is a few orders of magnitude less critical an operation than doing the same with an Apache that handles 1000 sites.
On a sidenote, security is always a compromise in shared-server solutions. But a shared HTTP server is, IMHO, one step worse.
Re: No, because of SSL (Score:2)
for https://your.domain.com:65220/
as they would for
the number of ports available doesn't
provide the kind of scale needed (hundreds
of thousands or millions of sites for large
ISP's); and client firewall issues make port-based
solutions unacceptable.
Re:A few problems (Score:2)
I guess it's only a problem for anonymous ftp servers.
Re:A few problems (Score:2)
It's only after posting my message that I realized this single issue with name based v-hosts and FTP. I can't say that I feel this is a big deal. Anonymous FTP is typically read only, in which case, why do you absolutely have to use FTP in the first place?
As far as the ISP telling you to use web-farm-isp.com instead of your own domain name - it's simply a convienience thing. I can (hopefully) remember my own domain name. I have no interest in remember the often obscure name they have for the server that actually host my domain name.
Re:Will someone please think of the shell provider (Score:2)
Also as a demon customer (although i use blueyonder hi-speed at my flat, BT at my parents and Lineone on my mobile) actually we just keep demon for email
Which cert does it send out? (Score:2)
<O
( \
XGNOME vs. KDE: the game! [8m.com]
SSL can use renegotiation (Score:3)
Re:this problem has already been solved. (Score:2)
IP addresses deal with the essential functionment of the internet, this CANNOT be taken lightly and certainly not put in the dirty hands of capitalism. It would like handing the internet over to a couple of corporations, which would, essentially, rule the world. It is absolutely vital that IP addresses allocations remain in the hands of an INDEPENDENT non-profit organization.
Domain names do not affect the way the internet works. There can always be a near infinite amount of domain names available. You can't compare auctioning domains and auctioning IP blocks, that's just crazy!@
Dangerous precedent (Score:2)
Like companies being required to use NAT, even if they don't want to and want each machine to have an Internet routable IP. Like ISPs that serve residential customors via DSL or cable modem being required to tell their customers they can not be on the net more that 8 hours a day average. Why would they do that? Because even if you have dynamic IPs you don't get any savings of IPs if everyone is holding on to them 24/7. Or even just telling ISPs they have to put all residential customers on NAT. Each ISP would get IPs for themselves, but home customers would only get "private" 10.x.y.z IPs (of course they can't serve content then, but it is likely that neither the ISPs nor ARIN would be at all upset about that.)
Re:These stories are sad (Score:3)
Here is what they want:
Make it so only the rich and powerful can get resources (such as IP addresses). Make it so residential customers aren't allowed to host content, even if their ISP doesn't mind, since their ISP will have beeen ordered to use NAT and hence the customers lack an Internet routable address to host off. No more pesky speech from the masses. Shift information transfer totally from bottom-up to top-down.
Along those lines, eventually, make it so the shortage is so bad the government comes in and requires mandatory FCC licenses at thousands/millions of dollars each and strict regulations on who can use them and how. The justification would be "scarce resources". Does that sound totally unbelievable? Well, if it does, you need to look at the early history of radio. Used to be free, now it is extremely regulated and restricted.
Re:37% of browsers use HTTP/1.1, the rest use 1.0 (Score:4)
Re:Yes and no. (Score:2)
2. Regardless of #1, I think ARIN will understand if you use IP-Virtual for HTTPS sites..
3. If you are providing entire (virtual or real) servers to customers, as opposed to just simple webhosting, this doesn't apply either.
All this effects is sites providing plain virtual webhosting service, that still havent migrated to name virtual hosting - listing that use of IP addresses will no longer carry as much weight as if you had assigned those IP's to dynamic dialup ports, or assigned small blocks of them to many customers.
As far as IPv6, its a neat idea, but there are lots of things to stumble over before it can be implemented.. It also seems that IPv6 is suffering from 'death by committee' - too many people have added too many overcomplications..
Workarounds for protocols other than HTTP are bad! (Score:2)
If that were the case and the only protocol running on the Internet that would require something like virtual hosting was HTTP, then we'd be all set.
For those of you who don't understand what this is all about, think of HTTP like this:
1) Your machine connects to an IP
2) Your machine then tells the IP what webserver it wants to be talking to *BY NAME*
3) Webserver fires back the appropriate content
If every single protocol on the planet had the client identify the server *BY NAME* this wouldn't be a big deal; however, they don't. Very few protocols do this.
Mail delivery does. POP3 and IMAP don't; though. Neither does FTP. Any protocol that requires reverse lookups to return a specific hostname is problematic if you are attempting to have one ip with many names (e.g. ident) Oh, and as many have mentioned SSL certs are tied to IP *AND* NAME so they have to be vhosted by IP.
The only current ways around this seem to be passing the server name with the user name. There are virtual ftp servers, virtual POP3 servers, etc. that allow for this. E.g. the user bob trying to access the mail server mail.foo.com to recieve his email would pass the username as bob:mail.foo.com. Or when logging into a virtual ftp server, the username would be bob:ftp.foo.com.
For most users this is a terrible inconvienience and anyone who works tech support at a large virtual hosting provider, I'm sure would agree. It's a tech support nightmare. For the majority of lusers out there, logging into 'mail.foo.com' as 'bob' makes life a helluva lot easier than logging into 'mail.foo.com' as 'bob:mail.foo.com' to check mail for the address 'bob@foo.com'
Perhaps providers of the world could go back on ARIN calling this move 'anti-competitive.' For most providers, it probably removes the ability to market a certain service - IP based virtual hosting - a step in between virtual hosting and dedicated server services that is ideal for midsize hosting accounts.
Grrrrr.......
~GoRK
Potential problems even with HTTP (Score:2)
2) IP based virtual hosting prevents unnecessary headaches for administrators of medium size sites that must endure access problems to named hosts due to misconfigured client proxies, firewalls, DNS servers, or web browsers. Also extremely old browsers - THEY ARE OUT THERE PEOPLE - even if their numbers are very very few.
3) DNS is introduced as another point of failure in the entire system. Without proper DNS resolution there would be absolutely *NO WAY* for a website to be accessed if it were on a named host even if you knew the IP. (at least without a bunch of fiddling around) The other problem to consider is what site could potentially be brought up using the IP number of your named host? Your hosting provider's site? Someone else's site maybe? Someone else's PORN site?? -- THis poses a tremendous problem for businesses who cannot afford dedicated server solutions. Pretty much every virtual server on servint.net's network is porn. Imagine if you had a legitimate business site on one of these named virtual hosts and DNS broke, so you accessed the site by IP and got a PORN site! Bad karma!
Try it - see if your favorite website is name vhosted. nslookup the IP and use it as the URL! You'll be shocked.
~GoRK
RTFA!! (Score:2)
It doesn't say you can't get allocations for other IP-based services.
Re:Secure websites need IP's however.... (Score:2)
Assuming that you're misinformed rather than being a troll, SSL needs the signature to prevent a man-in-the-middle attacks, or any hosts masquerading as another host. Think about it. You're going to amazon.com to buy books. I poisoned your DNS so that www.amazon.com points to my domain, and I act as a proxy for the real amazon.com until you're ready to make a purchase. When you do, through my SSL server, without the certificate, and I log your credit card information for my future use.
With certificates, you can be reasonably sure that the www.amazon.com is the real amazon.com and not my little false fpos thing. Without it, well, it opens things up for all sorts of interesting attacks.
--
Re:IPv4 is the reason for this, I'll wager (Score:2)
IPv4 has 1/4 of itself free! (Score:2)
Now, I will agree that some of the first allocations should be redone and forced to be returned. (MIT and some others have a class A space, or 16 million machines worth.)
There really isn't as severe shortage of IP's as everyone makes it out to be.
Where is IPv6 (Score:2)
Then, at the every least, some of the people on the internet might have a good reason to drive the adoption of IPV6.
Re:Protection from DDOS? Not likely. (Score:2)
From my experience of being slashdotted, there are plenty of script kiddies who turn up with DOSes around the same time legit visitors do.
--
My name is Sue,
How do you do?
Now you gonna die!
Re:A few problems (Score:2)
Like that's a secure approach.
--
My name is Sue,
How do you do?
Now you gonna die!
Re:Not as bad as it seems... (Score:2)
HTTP 1.0 didnt have a slot for it. How many servers run HTTP 1.1 compliant code? And how many are still running HTTP 1.0?
Yes, it's a semi-major undertaking. But it's not much different than adding Host: header to the HTTP protocol. It just has to be pushed.
Re:Thank God (Score:2)
Re:Will someone please think of the shell provider (Score:2)
Bandwidth Limiting (Score:2)
Re:No kidding, all shortages are artificial. (Score:2)
By that point they're going to have to find a different transport method rather than electricity or light anyway (who wants ping times of 2 years, anyway? hurry up with the quantum physics research.) and if they can do that, implemention IPv12 shouldn't be too much of a problem at that point
--
HTTP 1.0, 1.1 usages? (Score:3)
Is that more modern browsers trying to be friendly, or is that people who actually *can't see* the NamedVirtualHost stuff?
Re:Dosn't affect me. (Score:2)
Re:IPv4 is the reason for this, I'll wager (Score:2)
Any IP request has an IP address (32 bits) which uniquely identifies a network device and a port number (16 bits) Which uniquely identifies a service. So there are 4 billion x 65 thousand = a lot of possiblilities.
You can use the port number to route to different servers as you suggest but since certain port numbers are associated with certain services HTTP=80, FTP=21, Telnet=23 etc, you only get granularity on the order of services at the IP level. Some protocols, such as HTTP, have the client send the DNS name of the host it requests which then allows you to virtualize based on the (effectively infinite) DNS namespace. To do more than this requires client cooperation such as requesting an HTTP session on an alternate port. But this is impossible in the world of firewalls where it is quite common for only port 80 connections to be allowed.
There are other problems with the current form of IP addresses such as the difficulty of making a routing table since adjacent IP addresses may be in completely different geographical locations.
IPv6 is the solution and it contains the concept of global and local portions of the IP address similar to what you proposed as well as a mindbogglingly big address space (128 bits) and other features. Search Google [google.com] for more info.
--