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
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.
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.
In the HTTP/1.0 spec, sending a "Host:" header with your GET request was optional. In HTTP/1.1, it became mandatory.
/index.html HTTP/1.1
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.
-- Gxis! Ed.
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.
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 and RFC 2068 for information on HTTP 1.0 and 1.1 respectively.
The client must add a host-line to the request header to get the right virtual-host, a simple GET is not enough. And yes, it is a problem if your browser is VERY old (for example a Netscape 1.0). I also remember having trouble with a Python HTTP library that did not support virtual-host one or two years ago...
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
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.
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)
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.
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.
Mea navis aericumbens anguillis abundat
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.
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?
---
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"?
Squid in accelerator mode should do this. You will have to tell it to use the host header though.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
And I think that this means that the net is not ready to abandon IP-based hosting.
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.
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!
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!
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.
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!
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?
Read the FAQ.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
reverse proxy can be done with Apache and mod_proxy, see the documentation for mod_proxy at http://www.apache.org/docs/mod/mod_pr oxy.html. To do name-based vhosting with it, you have two options: either have the <Virtualhost> directives on the rev-proxy and forward to different URL paths on the backend (i.e www.bletch.com/urf becomes backend.serverfarm.com/bletch/urf), or you pass the Host: field as Original-Host to the backend, and then setup a fixuphandler to put it back as the Host: header. There is an example module that does something similar (passes the original request's IP as X-Forwarded-For" at http://www.cpan.org/auth ors/id/ABH/mod_proxy_add_forward.c; it's originally meant for use with mod_perl, but there's no reason why it wouldnt work with anything else on the backend, with a tiny bit of C hacking.
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?
NAT is conceptually ugly because it breaks IP's basic rule "only the endpoints should know or care about established connections". but hey, it works, and it works pretty well. Of course, NAT alone doesn't make a firewall... but it sure gives you a convenient place to put your firewalling rules, and *then* it can be one.
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
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?
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
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!
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
It doesn't say you can't get allocations for other IP-based services.
Edith Keeler Must Die
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
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.
Ah, but what happens when we start to route packets to the infinite number of other planets out there that need (want) access to our hosts?
:-)
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
--
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/