Slashdot Mirror
ARIN: No More IP's For IP-Based Virtual Hosts
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, 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...
they wouldn't have any problem with ip-based virtual hosting if there were more IPs than people know what to do with floating around.
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.
http://www.stu d.ifi.uio.no/~lmariusg/download/artikler/HTTP_tut. html read that, it explains the HTTP protocol. Basically, host header webservers host multiple sites (different domain names, e.g. "http://www.example.com" and "http://www.fred.com") on the same IP address. They distinguish between which site to send to the client based on the HTTP request itself, rather than purely the DNS lookup.
I think moving to name-based virtual servers is a good idea in general, but the https problem needs to be resolved first.
Alex
Will work for bandwidth!
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/
Plain name-based virtual hosting is acceptable for "bulk" or low-end hosting, but there's still plenty of situations where you run into trouble without using separate IPs.
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.
Marko Karppinen
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
I have to say that I don't quite understand how this works, because AFAIK when you make a GET, you just request a file, but don't tell the server the whole URL (or the hostname, for that matter). So how does it know which of the virtual hosts you refer to? Is this a feature of HTTP 1.1? And even if not, could this be a problem with old browsers that assume that there is just one website per IP address and port?
EagerEyes.org: Visualization and Visual Communication
Secure sites can't move to name-based virtual hosting, as site and key selection takes place before a single HTTP header line is sent.
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.
As far as I can tell, it's only due to the limitation of A/PTR resource record mismatches that SSL doesn't work on host-header. The SSL key is actually registered under a domain name, not an IP address.
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.
It does not really seem that they are not giving anymore IP addresses for IP-based virtual hosting. At ARIN, just like at RIPE, they are just _strongly_ discouraging IP-based virtual hosting, in favour of name-based VH. You can see her e for a discussion about IP-based VH at RIPE.
The problem is that the IPv4 adresses are running out, in other parts of the world we have had this policy for years since IP adresses are even harder to get here than in the US. I guess it's about time to start using IPv6...
Somewhere in the heavens... they are waiting.
Personally, I think ARIN needs to go, and NetworkSolutions with it. They've become monstrosities that don't belong on the Internet. They're plagued with bureaucratic crap, slowness, and idiocy that all harm the public Internet of today.
/19 in *pray* *hope*, I can understand this policy. Now, if I can just make sure my announcements wont get filtered.....
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
"To err is human, to forgive is simply not my policy." --root
While some organizations use IP-based webhosting to, in part, justify their requests for IP space, ARIN will no longer accept IP-based hosting as justification for an allocation unless an exception is warranted
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.
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.
I meant to include they will assign for IP-based on exceptions (which I would assume would include SSL). You can do FTP, POP, IMAP, etc... on a virtual host bases (even telnet) but it starts getting tricker (and more limiting).
The link to the article explains the policy changes in better detail.
-Mike
We migrated to name based hosting about 6 months ago - although it's true to say that you still need the IP's for SSL, we still saved around 400 IP addresses, and we're only a small ISP. IPV6 is still far enough away to make the effort to conserve as many IP's as possible and name based hosting helps a great deal. We haven't had any problems or complaints, anyone still using a non HTTP 1.1 compliant browser probably writes with a big slab of rock and a chisel.
I have a much more interesting sig but this space is too small
For www, it's ok by now - all the important browsers (including "telnet server 80" ;) ) support it. (https just requires a policy change in the organizations issuing certificates).
:(
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...
This message is provided under the terms outlined at http://www.bero.org/terms.html
The actual nature of the problem is not "what SSL certificates are for," -- it's that the SSL is done at a lower level than the HTTP headers.
// and /, the user's browser pops up an error, as it should.
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
...which I've always taken to mean HTTP. If you need to have multiple FTP (or whatever) servers, I don't see that this is going to be a problem.
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.
Everything is but a number spoken by itself.
Ah. On time. Its no use handing out hundreds of IPs to nothing. You don't need hundreds of different ip's just to do some hosting. You need one for each SSL-host, and one for the rest. So, if every provider that needs ip's get something like a /28 or a /27 - that should be more than enough. And, you don't need one IP for every workstation at your company neither. Use NAT. Then you've got some sort of a "firewall" at the same time.
/27 or a /28. Have a DMZ for the servers, and place the rest behind NAT.
I can't understand why they've used this long to implement this. No "small" company should need more than a
--
"Rune Kristian Viken" - http://www.nwo.no - arca
We do accounting based on Cisco ip-accounting. With name-based virtual hosting we have to do this based on the webserver logs, giving a difference of about 20 to 40% less, as the IP overhead is not counted.
-- unix is for people without a social life - Patrick van Eijk
I just set it up for all my hosted pages, and it works beautifully. It took less than 10 minutes.
That's funny I see this thread today, since I had a discussion a few days ago with some important ISP here...
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, 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
--
Instant Karma's gonna get you, Gonna knock you right on the head (John Lennon, 1970)
Is the relatively limited amount of current address space the reason for this? And if so, won't the move to IPv6 eliminate this little choke point, thus removing the need for this "fix"?
mas cerveza, por favor politically incorrect stu
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.
What is keeping ARIN from next saying that you can no longer hand out greater than /30 's as an ISP because "Everyone should be able to use NAT" ?
Nat with virtual hosting would be you can forward a single IP TO a single webserver inside the IP range.
I think it's long past time for IPv6.
What about the loss of IP's from people who give EVERY end user their own IP addres ? For normal surfing/webbrowsing user, it's not necessary. Even FTP works through it.
Just something to think about.
Likewise, if you can't justify all the IP's because ARIN forces you to use VH, do you have to return them ? or can you then "un-nat" all your normal user/client machines and use them in that case ? I have a feeling that you are NOT going to see any IP blocks returned. I hope that wasn't ARIN's point in this whole debacle.
CBoy
That is why a certificate is needed, but does it really matter in whose name the certificate is issued? As long as the certificate matches the server, does it matter if the certificate is in the name of "John Doe Retailer inc." or "A Web Hosting Corp"?
Name based hosting will work for most cases. There is about less than 2 percent (if that many) of people that would have a problem viewing name based hosted sites. Ftp that would cause a problem. Quite a few people like the fact they could have an anonymous ftp server. This a why they should start impletementing IPV6 now so everyone could start making the long transion. It might take six years for IPV6 to be fully acceptable after it is implemted. Just my thoughts
With depressing regularity, I see stories related to various virtual "shortages".
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.
"Hey... don't be mean." --Buckaroo Banzai
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
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"?
And I think that this means that the net is not ready to abandon IP-based hosting.
Consider that virtual hosting could be defined much more widely. I wouldn't be surprised if some folks out there are offering a sort of vitual machine for their users, using virtual hosting, and chroot to provide locked down areas for users to work in, plus virtual web hosting and mail.
I used the virtual hosting capabilities of Sendmail, as well as web virtual hosts.
It's not clear to me that sendmail would scale up to having many many virtual hosts. It needs to be tested.
I could never get apache to do the right thing, which I suspect was because of the funny setup I have (my dsl router does NAT). A speculation. Roxen worked for me.
Pin the spig.
It doesn't really matter to us, or anyone else .. it would work the same and still give an encrypted connection ..
.. and of course as someone else posted, without the certificate checking you can mount a "man-in-the-middle" attack.
.. can anyone confirm/disprove this?
but, people would notice, customers _always_ somehow manage to notice the least little thing, all they see is the box that comes up, they wouldn't look at the little padlock that says the connection is encrypted
also, the thought occurs that when you generate the CSR (certificate signing request) it uses the server key, the server key has the servers name in it doesn't it? so the servers _name_ will always be in the certificate, and fail to match with the address that someone typed in to access one of these virtually hosted SSL sites.
surely a browser would alert someone to this discrepency?
This will probably immediately send J. Random Bloggs into a fit of panic that it isn't a secure connection, regardless of whether it really is or not.
This would make you and your company look _bad_
I can't actually test whether this happens or not, not tending to have a spare SSL certificate lying around to play with
meow! Maria
Server certificates contain the host name of the Web server, and the browser automatically warns the user if the "server" tries to present a certificate whose hostname doesn't match. So, in addition to cracking a backbone router, our would-be man-in-the-middle hacker would need to explain to his favorite certification authority why he needs a certificate for www.etrade.com even though he doesn't own that domain.
Your toaster doesn't need a routable IP.
Your doorbell doesn't need a routable IP.
Your random internet appliance doesn't need a routable ip.
Your 200 employees don't each need a routable IP
And your 300 websites don't each need their own IP. With technologies like NAT and name-based virtual hosting we can ride on IPv4 for a *LONG* time. IPv6 is going to take ages to implement so people please please stop whining about "why won't we switch to IPv6? come on!!! it'll solve all our problems!!" well considering the amount of stuff out on the net right now a switchover to IPv6 will take at least 10 years.
Yeah, could you explain that last paragraph? That kinda threw me.
Great explanation of the issue, however, I am more of a programmer and had no idea what this was about, gut this clears it up considerably. Thanks for the info!
One question for you though, is there any way to distribute the risk of that one machine running the vHost redirection? It seems like if that machine was ever subjected to a dDos or went down for some reason, you'd be up the creek. The way it seems now is if a particular DNS server goes down, there is a backup, and sometimes the name to ip is sometimes cached anyway. How frustrating would it be to have your web server sitting totally idle because nobody can get to it due to a crashed vHost redirect!!!
-------------- insert [signature] here
No longer will I be able to get a shell with it's own IP for £54 a year ($80 US) - bummer.. how will i ever irc from i.graha.ms now :(
Also this will probably come down hard on ISPs like Demon Internet 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.
Roll out the IPV6, baby!! Maybe this will aid in the forced adoption of IPV6!! ..one can dream ..
Just thinking out loud to see if I've got this right...
1. I request a page from www.myco.com.
2. Make a DNS resolution, get back an address of 2.2.2.2, which is the same address as several other domains' web pages.
3. Send http request to 2.2.2.2, which happens to be a webserver hosting several pages, or a load balancer, or whatever.
4. 2.2.2.2 looks at the domain in the http request, sends back the page if it's a server, or does it's thing and redirects to another server if it's a load balancer...
Which brings up another question, does this issue with virtual hosting bother load balancers, which use several IPS for each domain? OTOH, anyone loadbalancing their servers probably has enough influence (money) to get as many IPs as they want. I guess you could load balance several domains, all of which are using the same set of IPs and servers.
restricting themselves when handing out new addresses, these people should concentrate their efforts on reclaiming IP's from companies and individuals who are just WASTING them
I know companies who blagged 256 or 512 addresses a few years ago to every PC they own has an Internet IP (no NAT) and they are refusing to hand them back (as they regard them now as a monetary asset...)
If an effort was made to reclaim addresses from greedy companies, and defunct sites then they can be reissued to people who need them!
Oh, and I think a move to name based virtual hosting is a good thing, and should be applied retrospectively as well!
I work for an ISP which has been doing name base hosting for...YEARS! Besides the occasional odd problem here and there (nothing getting rid of internet exploder cant fix) its been a beautiful thing. I thought everyone used virtual hosting...
Before reading this I thought each website needed an ip. I'm one on the millions of people wasting ip's, unknowingly. Can someone point me in the right direction on where I can find information on how to set up virtual sites that use one ip in NT 4 using Microsoft IIS? Thanks!
-Vin vin@thehellhole.com Webmaster of Mr Hat's Hell Hole: www.thehellhole.com
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.
I started doing name-based virtual hosting on my home system in 1996. I only have one IP address, so it was a forced decision. At the time, I had some friends check out the various host names to see what they got. The only ones who had problems were using Mosaic or ancient (1.x) Netscape browsers. Four years later, it's probably safe to assume that almost everyone has Netscape >=3.0 or aIEeee >=4.0 (or else is already having problems much bigger than hitting the wrong NameVirtualHost!).
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 which I've linked here by its IP address instead of its name.
--
Tired of FB/Google censorship? Visit UNCENSORED!
Does this policy apply to l33t shell providers who provide virtual hosts like "my.eggdrop.flashed.its.nuts.cuz.it.is.supal33t.ne t"?
I mean, obviously people like that NEED the IPs, whereas major web providers can think of other ways to serve up some net.
Right now we assign an IP to every website. We have some address space luckilly.. what this will fuck up however is:
/etc and such.
:)
* 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
There are a lot of non-www based services that don't use name based virtual hosting. Name based ftp? Name based finger? Virtualizing is good, but we can't switch to just that for everything, at least not yet. Yes there actually are a few people who continue to run services other than http!
Yes, I know... People can just upgrade their browser. But I think Microsoft should sue them for infringing on one of their most popular business policies - destroying backward-compatibility so people will have to upgrade. Sure, an HTTP standard is different from a version of Microsoft Word, but...
What really gets to me, though, is that they're dicating what we can and cannot use our IPs for. This is like the recent (okay, rather old...) announcement that Network Solutions owns your domain name, and can take it back if they think it's appropriate. What's next? Just suppose for a minute that UUNet, one of the major Internet backbones, releases a new policy - you are not allowed to do your own webhosting. Okay, so, most likely, UUNet would go out of business very quickly. But you get the idea - more and more companies are dicating what you can do on your Internet connection. Suddenly, it's illegal for me to use profanity, post something to more than one newsgroup, or, here's the scary part... Run a "server" on my cable modem. They go on to list some types of servers we can't run, including a telnet server. They're very indirectly telling me what OS I can and can't use.
Unfortunately, places like this seem to have a monopoly. If they stop giving out IPs, we're screwed. (I might be wrong on this...)
BTW, I have another idea... By placing new limits on what can and can't have an IP, they seem to be hinting at the fact that they're anticipating running out of IPs. Here's my idea - add one more "ocet." So, instead of having "255.255.255.255" as a maximum, you would have "255.255.255.255.255" as a maximum. This will multiply your IPs by 256 - and there are already billions. Ensure that 4-ocet (is "ocet" the right word?) IPs will still work with the new standard, and bingo... Maybe then they'll be more lenient with assigning IPs.
SUWAIN: Slashdot User Without An Interesting Name
SUWAIN: Slashdot User Without An Interesting Name
OK, first, the browser is not making DNS ( name resolution calls by itself ). It generally uses some API that in turn makes DNS calls. Under *NIX the API is called gethostbyname() I am not sure about other OSs. SO the difference is not really in how old your browser is, but how bad is your TCP/IP implementation. Oh, well if you use MS DOS 3.3 with LAN manager client you might have a problem... but I don't know any web browsers for this platform except of the lynx port. Anyways, the other thing is that there is already a so called standard so called IPv6 which is a version of IP protocol that uses 6 byte addresses. It is though REALLY difficult to make a change like this transparent especially if your users are not under your direct control. I mean if you have two different addressing schemes, you either have to make translating gateways or force people to use new one over old one. There is no way to force the Internet community to do anything, and someone has to build the gateways without any hope to get paid for it. I hope you see the problem now.
Everybody Lies. But it doesn't matter since nobody listens.
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.
No.
... Its busted!
The problem is that when you have one, eg, webserver, listening on a given IP it has no way of knowing that you want one site or another. That is why you need the host header. Think about it. Any dns implementation which fails to return an A record for a given name when it exists isn't just going to have problems with virtual hosting on single ip
Demon still use SMTP mail delivery as the main method ... .. ie, not only is there an IP for luser.demon.co.uk but if they upload web pages, an IP is assigned by demon to www.luser.demon.co.uk !
and don't forget that Demon Internet (now part of Thus) also has a static IP for each dialup customer that has a homepage
I wonder if demon will change all their dialup users homepages to name based virtual hosting and give back however many thousands of IPs this will free up
I don't know about anywhere else, but at the ISP I work at, we only give a user a static IP if they can justify it, then we can justify it to RIPE
fair's fair, right?
meow! Maria
Virtual hosting isn't just about HTTP. It's also about FTP, POP3, IMAP, SSL, and whatever other protocols a host chooses to support. Some hosts even virtualize Telnet, SMTP relay, or finger. There are problems with bandwidth shapers, traffic analysis, partitioned "virtual servers" or other unique technologies, etc.
I don't think anyone has mentioned the impact of filtering systems or Spam filters such as ORBS. If you have three hundred customers on one IP, and that address gets filtered by such a service because of one rogue customer, you're screwed.
We're not talking about giving IP addresses to toasters. We're not talking about giving Class C's to T-1 customers. We're talking about using IP addresses for hosting customers who need and pay for a package of virtualized services. Services which hosts have provided for years, and will need to continue to provide in order to remain competitive. Services provisioned in a fashion which ARIN has supported.
Lastly, what about enforcement, reclamation, and competitive advantages? Will Host A run out of allocated space before Host B? Will Host C decide to circumvent the policy through any of a dozen methods that come to mind? Will ARIN go to Host A and say "give us back that /18 you've been using for three years"? Will they do the same to Host B? Will the big hosts end up in court?
I'm running for one of the seats on the Advisory Council, myself. It seems that the policy was created without input from those actually using the technology. Again, it's not just about HTTP.
Kevin Martin
sigma@pair.com
www.pair.com
Of coursey you don't, you live in a socialist country.
I want to delete my account but Slashdot doesn't allow it.
I don't know why every is saying that ftp can't work with virtual host names when there is a proftpd config for it.
If you need text styles to communicate then you don't have a message.
I know a few people who serve in some capacity with ARIN and there is a distinct bias against webhosting and the hypertext protocol in general. Too many of the ARIN and Internic directors are they type who lament what they see as the "death" of the Internet at the hands of commercial and individual entities and therefore blame the popularity of this protocol for changing the face of the Internet.
/19, /18 and larger allocated blocks who were assigned these networks many years ago. Rather, they should be actively using non-routable IP space, proxies, and DHCP rather than static IP configurations.
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.
Why do people seem to insist that "The Internet == The World Wide Web" anymore?
It reminds me of The Corinthians 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?
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
NAT is not a technology, it's an abomination. It breaks one of the most fundamental rules of the Internet, which is end-to-end connectivity. NAT is also a weak curtain for people who are unwilling to secure their machines.
Microsoft has been "riding" on top of DOS for the past 15 years or so, how has that been good?
People need to learn when technologies need to be taken out of service and replaced.
Users need to be able to upload to their web space, and HTTP can't upload without potentially compromising the system.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
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!
Will I retire or break 10K?
I don't think that encouraging the use of name-based virtual servers is a bad idea per se, as long as they're flexible and accept the limitations when they're presented in a requirements request document.
In addition to the SSL restriction, if you're running a site, or sites, that use some form failsafe mechanisms for redundancy, you'll have some difficulties trying to do it with only a name-based VIP.
Again, as long as the policy is flexible, and defaults to allowing someone the address space if they justify it's need, then ok.
Unfortunately, I think we're all aware of the history involved, and I don't think the flexibility will be as available as necessary to make us happy.
There are a lot more IP addresses than there are people connected to the internet.
--------
I'm a Demon customer, and a happy one at that. They allow both POP3 and SMTP mail delivery, both of which I use depending on whether I'm just checking it or actually downloading to my primary box.
Anyway, Demon (currently) use a single IP per customer's homepages website, but they plan to change to some name-based virtual hosting. And once they've done that they can recycle those IPs for dial-up customers.
Also, why do you need a shell account with its own IP address? UNIX boxes have been allowing multiple shell accounts off the one IP since year dot.
-- Soruk
I know RIPE have been doing this for about a year (or so)... Whether this is a good thing depends on your point of view. It helps conserve IPv4 addresses. It means people need to think about what they are doing...
But if you offer anonymous ftp server and web server for a single fee then you still need to use IP addresses. FTP is not capable of working on a HOST header basis.
The ISP in the UK that I used to work for bundled anonymous FTP with web servers before this policy came out. I don't know how many people use their FTP space, but it is there. It was a cheap and easy way of adding value to our offerings.
My personal belief is that some people will switch to name based virtual servers, others will start to bundle more services for the same price such as FTP and HTTPS that can't be run on the same basis.
Anyone want an IP based shell account with a web server, ftp server, https server and nntp server of their very own, all for the low price of...
-- Under/Overrated is meta-moderation, and therefore is Redundant.
That would unfortunately prevent access by any users who are behind firewalls that are configured to allow only port 80 and port 443. Depending upon your audience, lots of people who do their shopping from work would get blocked.
But doesn't that cause problems for people behind nazi firewalls? (some companies seem to think anything going ports other than 80 and perhaps 8080 is inherently dangerous and ought to be blocked).
... and yes, this happens... :-(
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Well the main use is if you want to IRC from a certain hostname. IRCd checks when u connect that your forward and reverse dns match so that means if you want a custom hostname - you need your own ip.
:) i'd like to see them improve the webmail service since it's been in testing for about 3 years now and should be nearing maturity.
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
When Demon introduced the ip based virtual hosting for the homepages service, they announced the intention of moving to named based virtual hosting - but as yet this has not happened.
At the time the server sends a certificate, it doesn't yet have any HTTP headers; all it has is the IP address. Without the Host: header, how will it know which certificate to send?
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
I've seen many companies that grossly misuse their IP address allocation. They allocate a static IP per dial-up user; they allocate a static IP in apache for thousands of virtual web-hosting clients.
The point is that where an IP address is needed, like for _public_ ftp servers and for SSL servers, they should be allocated.
It's the people that waste because they can that are in the wrong.
The problem is policing it, of course. Everyone wants contiguous blocks so they'll ask for more than they'll ever need.
It's easy enough to set up a site that changes key/cert upon receipt of the request URI (or Host: header). Simply choose a primary key and cert, do the initial connection with that one. Then, when the client specifies the URI (or Host:), request renegotiation and choose a new key/cert pair. All major browsers support renegotiation.
Citizens Against Plate Tectonics
I know that not every reporting package is written with the same limitations, but if they didn't write it to deal with large numbers of virtual hosts, will it efficiently deal with them? or deal with them at all ?
More to the point if you are hosting several virtual SSL servers on a single box then its likely that your DNS is setup with an alias for the real site to point to the CNAME of the hosting box....
This suggests to me that the client could allow authentication against a certificate from the real host name... eg
website = www.somecompany.com
website = www.anothercompany.com
host = host.hostingcompany.com
with DNS config of:
host.hostingcompany.com IN A 10.0.0.1
and
www.somecompany.com CNAME host.hostingcompany.com
www.anothercompany.com CNAME host.hostingcompany.com
then both webservers could use a certificate for host.hostingcompany.com.
The problem with this of course is that if someone can hack your DNS (which of course would never happen *grin*) then they can fake the SSL component of another site which isn't a vulnerability under the current mechanism.
Really it comes down to a question of is SSL intended to provide security for traffic in transit or authentication of the web site? Consumers are currently more paranoid about the first but I'd have thought the second was actually more important.
I suppose that there could be a two stage authentication process where the real name of the box is used to encrypt the link (and authenticate that host) but then an additional certificate (X509 with an extension) could be provided to prove that a particular name can be hosted on that machine...
just thoughts
Tom
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.)
Just because it CAN be done, doesn't mean it should!
I use Demon for my box at home on a caller-id ringback system (so I've got static IP to ssh into). I also use Demon on my cellphone (ED50 on Orange) in the evenings on their 0121 number, but for daytime cellphone use I use OneTel who charge 1p/min (and on a cellphone 1p/min ain't bad especially at peak rates!) through a freephone number.
-- Soruk
But if it can be progressively done, and backwards compatibility can be maintained, there won't be any problems.
I'm on the internet through a cable connection, and I have about 20 different domains hosted on a server in my house, all using the same IP, apache's directive and some creative CNAME's in my DNS records... It's been working great for like two years now, and it's definately a viable solution to the IP shortage...
-- www.RoachMcKrackin.com
I must object to the characterization that ARIN 'hands out' IP addresses. They don't. At least in my case they made people from my company work for months to justify our initial allocation of a /19. And then they fully gouged us for several thousand dollars to get the IP's, and are going to keep gouging us every year.
No way they just 'hand them out', it's as if they don't want you to have them, so they can save them all for Worldcom or something.
Thanks for the clarification.
Quidquid latine dictum sit, altum viditur.
I only post comments when someone on the internet is wrong.
I admin a couple of servers with about 100 sites each, on 1 IP. The FTP access is not 'name based' but 'user based'. Each user can FTP into the server using any of the names (and any of the IPs), but it will only have access to its own site. That way, it doesn't matter what domain name is using, the access is defined by the username.
--
--
Stay tuned for some shock and awe coming right up after this messages!
I don't know about any one else, but I have been using name based Virtual Hosting for quite some time, and so have quite a number of large ISPs in my area. I personally don't foresee a problem meaning that I have yet to receive a complaint about not being able to use my site. Any one using an old browser shouldn't be surfing newer sites anyhow.
--Dave
"Besides, I think Slackware sounds better than Microsoft, don't you?" --Patrick Volkerding
SSL... yeah... what about SSL? SSL? SSL...
jeeze, read before you post... half the freaking comments are 'BUT SSL!'
Welcome back to the consumer notion that the web *IS* the Internet.
.. "Why do I have to do that?" Bob says... Then you have to talk him through setting his Reply-To: header and that's a pain. Let's let the ARIN people do 20K tech support calls about this and see how they like it.
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
1) IP based virtual hosting is tremendously more manageable than name based hosting - Primarily because DNS takes 1 TTL (however long) to change over in the event of a problem that requires a workaround where one must move a website from one IP to another. If you can move the IP, instant change.
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
this isn't a problem in my book so long as the policy is reversed when IPv6 enters widespread use (beyond universities and Internet2 (I2 is using IPv6 right?)) since once that happens we'll have plenty of IP addresses avalible :)
www.somecompany.com CNAME host.hostingcompany.com
www.anothercompany.com CNAME host.hostingcompany.com
then both webservers could use a certificate for host.hostingcompany.com
Except that the browser will validate the server certificate, which embedded within is the name host.hostingcompany.com and warn the user that the site they have connected to (www.somecompany.com or www.anothercompany.com) does not match the certificate contents.
It doesn't say you can't get allocations for other IP-based services.
Edith Keeler Must Die
But, according to linux-firewall-tools.com, the following address spaces are reserved by the IANA;
# Refuse addresses defined as reserved by the IANA.
# Note: this list includes the loopback, multicast, & reserved addresses.
# 0.*.*.* - Can't be blocked for DHCP users.
# 1.*.*.*, 2.*.*.*, 5.*.*.*, 7.*.*.*, 23.*.*.*, 27.*.*.*
# 31.*.*.*, 36.*.*.*, 37.*.*.*, 39.*.*.*, 41.*.*.*, 42.*.*.*
# 49-50.*.*.*, 58-60.*.*.*
# 67-127.*.*.*
# 169.254.*.* - Link Local Networks
# 192.0.2.* - TEST-NET
# 197.*.*.*, 217-255.*.*.*
Now, obviously the IANA can't release addresses like 192.x and 217-255, but why is 49/50 reserved
What about 58-60?
There are a significant number of useable IP addresses the IANA is just sitting on, and I may be stupid, but I haven't heard of any good reasons for this; maybe someone can enlighten me.
Instead of trying to be fascists about IP addresses, the IANA/ARIN/APNIC/Big-Brother-of-the-Internet should just release the addresses it's sitting on, or get IPv6 out the door; I hate this kind of gestapo crap, where they have to make stupid decisions because of their lack of planning in the first place.
ARIN shouldn't care what I use my IP addresses for, as long as I'm using them...frankly, it's none of their god damn business.
The real solution for the future is WebDAV (and being worked on by the W3C), which fully supports named servers and authentication, and is designed to replace FTP and the various ugly "web posting" systems out there, including the uploading aspects of FrontPage Extensions.
Notably WebDAV implementations include Zope and mod_dav for Apache.
Comments like this are what makes /. for me, a lucid technical description followed by a bout of babbling insanity. Can life get any more perfect?
If ARIN gets its way, the response to one of these lookups will return possibly up to 2500 hostnames. This is if a single server is hosting 800 sites (not uncommon) on one IP, with 3 or 4 hostnames (www, ftp, mail and plain old mydomain.com) for each domain hosted on the server.
Seems a bit short sighted, although maybe they hope to push IPv6 down everyone's throat. What they should probably focus more on is all the Class C's handed out by ISPs to their clients, who can really get by with 4 or 8 IPs and IP Masquerading.
cat
If anything, they're being too aggressive in not letting out IP addresses.. a whole 1/4 of the IP address space was just opened up a couple of months ago (64/2). That's over a billion machine names.
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.
What the hell is wrong with these people. Instead of saying 'we won't assign any more IPV4 addresses for virtual hosting', why not say 'we will only assign IPV6 addresses for virtual hosting purposes.
Then, at the every least, some of the people on the internet might have a good reason to drive the adoption of IPV6.
I gots ta ding a ding dang my dang a long ling long
When you use name based virtual hosting with websites, one problem is that browsers which are not HTTP/1.1 compliant try to reverse-lookup the server's IP address, and so, instead of getting the virtual website, they will get the hosting companies website.
The reason there aren't a lot more SSL servers running now are 1) US crypto export regulations have made it a pain to ship the software around; and 2) SSL servers in the US generally need to license the RSA patent to use RSA cryptography.
The export stuff has just been relaxed a lot, and the RSA patent will expire on September 20, just a few weeks from now. I expect a lot of new SSL servers to go up after that. Sites that store any personal info (not just financial stuff like credit card numbers) should use SSL a lot more than they do. There's easy-to-install free server software available, certificates are a lot cheaper than they used to be, and computers now are fast enough that the crypto computations aren't a real bottleneck any more.
I'll probably announce SSL availability on my own personal site on September 21, the day after the patent expires ;-).
Not wanting to be a pedantic fuck, but IPv6 actually uses 16 byte addresses, from memory.
There is in fact a big problem with doing name-based hosting for secure sites.
...
As pointed out before, the SSL handshake happens before any name can be transmitted, so that the server must always present the same certificate for a given IP/port combination.
The TLS upgrade draft as proposed doesn't really solve the problem. What is proposed is to start a connection insecurely, have the browser send a host header, and then have both the server and the client upgrade the connection to TLS.
The first big flaw is that this requires new clients and servers. There are no servers out there that support this, and no clients either. I work on one of the most popular commercial servers - the iPlanet web server - which, incidently, is available for Linux for free at www.iplanet.com . So I can fix the server part in our next release. And our browser folks could fix that in Mozilla/Communicator too
But, IMHO, we will not do that. The second flaw is that the TLS draft makes the upgrading of the connection "option" and reuses the existing http:// URL scheme. The connection is supposed to be upgraded to TLS only if the server requests it, or the browser requests it, based on the user preferences. This is very bad because a server-side application has no way of enforcing security on its content. It is forced to use conventional http:// links and relies on the browser being TLS-upgrade compliant to do the magic. If not, the connection will just proceed, insecurely.
I think making security optional is a terrible idea. You either want it or you don't, and if you do, there must be no circumstances under which the connection will be insecure.
The right thing to do would be to extend the TLS protocol to support virtual hosts. Failing that, a new URL scheme ("httpt://"?) could be devised specifically to mean "connect insecurely and immediately upgrade the connection to TLS after VS negotiation". Then the security could be enforced by the clients, servers as well as applications.
-- Julien Pierre http://www.madbrain.com/blog
If the hostname you typed into your browser doesn't match the certificate you got, browsers warn you. See https://www.palp.org for an example.
-palp
They have a point in saying that something needs to be done.
What other options are there?? There are only so many availible IPs. More may be coming soon with the new "standard" but that isnt very widly supported yet. This is much more reasonable right now.
What else would you have them do???
A good solution to the FTP and http 1.0 problem would be some server-side extensions to the nameserver. Lets say ftp.bluh.com is pointed at an IP along with 200 other hostnames. When ftp.bluh.com is resolved, a token could be sent to the nameservers for bluh.com telling them what IP is resolving it. This information could be passed in turn to the FTP server, which would know that it's ftp.bluh.com from that IP's point of view, and act accordingly. The same could be done with many other services.
This isn't as hard to impliment as it sounds. We have to start conserving IP's, I don't think putting large blocks of users behind NAT is a good option, and ipv6 is still a long way off from being global.
I know thats how it works at present - but the browser by doing a reverse lookup could also get the real name of the server and validate against that.... this would involve a change to the authentication method but as far as I can see it would be the only way to allow virual SSL servers on a single IP.
It looks cool to appear as graha.ms@graha.ms and clearly identifies who I am to people who know me. It instills a far greater level of trust that I am who I claim to be than if i appear as ~graham@modem13813.uranium.pol.co.uk or any other freeserve like address.
Limiting the amount of bandwidth a web site uses also requires a separate IP address for each limited site. This applies to MS IIS AND Cobalt RaQ [Linux] servers. You can't do this with host headers.
So, I'm not sure about this, but I did notice that HTTP 1.0 (doesn't support the by-name hack) is still about 40% of the hits in our web logs.
Is that more modern browsers trying to be friendly, or is that people who actually *can't see* the NamedVirtualHost stuff?
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I am fully aware of that, in fact, this is why it would require no client side modifications. Simply a token sent from their nameserver to the authoritive stating what IP is resolving what. This type of data can be packet into 20 bytes, even on a large scale, traffic would be negligable.