Re: pro/cons of virtual hosting services

At 17:17 14/11/95, Daniel Karrenberg wrote:
poole@eunet.ch writes:
We strongly discourage use of IP address space for virtual hosting services because this represents no technical reason to assign more than one address to a host. Therefore it is in conflict with address space conservation.
A would strongly suggest that this is a NON-problem, even with the gigantic increase in WWW servers that we are all experiencing it is hard to see how this could ever become a serious consideration.
Unfortunately we have seen some significant address space requests based on this. Note that we are not talking about one additional address per organisation served, but one additional address per arbitrary entity requiring a virtual server. Given the boom in http based services this may become quite significant.
To repeat: The second soloution proposed provides all aspects of provider independence. Why should we waste address space if wasting it does not provide significant additional functionality?
It *DOES* provide additional functionality. We had that kind of debate lots of times in lots of places. DNS is the simplest, most integrated "directory assistance" provided on the Internet, and many (most?) people simply try "http://www.company.com" when they need info about that company. The virtual hosting hack is nothing else but a hack. It should never have been used that much, and the "Host:" or "Full-URI" header should already be part of the HTTP spec (it is now postponed till version 1.2 of the spec, if I remember), as the HTTP WG is still trying to normalize the current practice, instead of trying to defined a new good practice (this is not a criticism, the people on the WG do work a lot to define precisely and minutely the protocol, but I think they should place this into perspective, and see that that header should be part of the spec ASAP, before it's too late and the installed base is too large). I think RIPE should put pressure on the people in the WG to include that f***ing header in the spec very soon (1.1 would be a good idea). In the meanwhile, virtual hosting is the only way to do this, so I guess we'll have to do with it. Jacques. --- Jacques Caron - Pressimage Telematique - jcaron@pressimage.net Mail: 5/7 rue Raspail - 93108 Montreuil Cedex - France Tel: +33 (1) 49 88 63 56 - Fax: +33 (1) 49 88 63 64 Pager: 0000026 (Tel: 36 60 60 60/Minitel: 36 09 09 09) Planete.net: Bordeaux, Lille, Marseille, Montreuil, Toulouse, Nantes et Nancy. Bientot Rouen et Lyon - http://www.planete.net

Repeats, clarifications: Transparent change of server machine without changing URL can be supported without using additional address space. http://company.com/ cannot be supported without using additional address. http://company.com/company/ can be supported. Note that the second "company" can be different form the first as long as it is unique on the physical server. Current policy is to "strongly discourage" using additional addresses. Responses to arguments: There certainly are cases where this practise can be justified even when the address space conservation is taken into account. Strongly discouraging does not mean forbidding. If this indeed consumes relatively little address space and parts of subnets which are currently unused it is problem. However promoting this practise will of course create additional demand. Some contributions to the discussion already said "we have to do it because *they* do it". http://company.com/ generally is generally no more intuitive than http://company.com/company/. This is a rehash of the "predictable domain name" and "predictable mailbox name" discussion. It only makes a difference for very well known company names. Promoting this practise will give a wrong image of prestige to a "short URL". Promoting this practise will also put additional pressure on DNS namespace by suggesting registrations of all sorts of entities as close as possible to the root of the tree. This creates even more pressures on an already very loaded system that can only work and scale well if organised hierarchically. This is not limited to one address per company since companies are assigned subtrees of the DNS space providing for an unlimited amount of names. In some TLDs companies can also register arbitrarily many subtrees. Policy: In the absence of a specific IANA policy on the issue European Internet registries will "strongly discourage" the use of additional address space for virtual hosting of HTTP servers. They will not assign significant amounts of address space for this purpose. Further process: If this group does not consider this policy adaequate, please define another. Daniel

There certainly are cases where this practise can be justified even when the address space conservation is taken into account. Strongly discouraging does not mean forbidding.
If this indeed consumes relatively little address space and parts of subnets which are currently unused it is problem. However promoting this practise will of course create additional demand. Some contributions to the discussion already said "we have to do it because *they* do it".
http://company.com/ generally is generally no more intuitive than http://company.com/company/. This is a rehash of the "predictable domain name" and "predictable mailbox name" discussion.
But surely you need to admit that it is very messy. Who likes a messy implementaion?
It only makes a difference for very well known company names. Promoting this practise will give a wrong image of prestige to a "short URL".
Promoting this practise will also put additional pressure on DNS namespace by suggesting registrations of all sorts of entities as close as possible to the root of the tree. This creates even more pressures on an already very loaded system that can only work and scale well if organised hierarchically.
The IP addresses that are being used for 'web aliasing' should not be worried about - they are only a tempory measure until th web client communicate the full url to the web server. Basically, as soon as Netscape implements this all web browsers within a matter of mounths wiill follow suit - look at HTML. Aftre this transition all IP addresses used for web aliiasing may be reused for 'real machines'. When reading the documnetion of CIDR it states that current IP addresses will run out in approx 3 years. The trasition to full URL will occur in a FAR shorter time. You are right in saying though, that current practices cause harm to the DNS - however your suggestion of http://company.com/company/ is an equal offender in this respect. Any strain put on the DNS will be permanent and cannot be reclaimed like the IP addresses can. The only way to help this situation is to remove the rediculously limiting heirarchy that is enforced on it. The DNS is just far to flat. Also, (although it will really irritate many of my customers) stopping resitration to the .com domain would help things out an awful lot.
Further process:
If this group does not consider this policy adaequate, please define another.
Worry more about the mess that the DNS is becoming rather then the IP addresses used for this purpose. Aid -- Adrian J Bool | http://www.u-net.com/ Network Operations | tel://44.1925.633144/ U-NET Ltd | fax://44.1925.633847/

On Wed, 15 Nov 1995 15:38:11 +0100, you wrote: | Current policy is to "strongly discourage" using additional addresses. Daniel; I reiterate that this would best be done in a formal document [maybe an addendum to the address space form] which either defines "valid use of an IP address" or defines what is an invalid use. Then you can point to chapter and verse in situations where someone wants address space for a "strongly discourage"able purpose. In the meantime, if RIPE are strongly discouraging the RIPE community from using the "virtual server" mechanism of providing what our wage-payers want, which is a short URL of the format http://www.company.xxx/, I would like to propose that RIPE take a request from their wage-payers to the HTML designers to ensure that a "full URL" mechanism be implemented in as many browsers in as short a space of time, and that RIPE accept, in the meantime, the use of an IP address to provide the service our customers want. Oliver -- #include <TunaSaladOnWhite.swch> /* work://mail/oliver@demon.net require 'TeaWhiteOne.regularly'; # */ home://mail/oliver@kfs.org

Daniel; I reiterate that this would best be done in a formal document [maybe an addendum to the address space form] which either defines "valid use of an IP address" or defines what is an invalid use.
Then you can point to chapter and verse in situations where someone wants address space for a "strongly discourage"able purpose.
I would add to this. Please come up with a document and present it for the approval or disapproval of the RIPE membership/contributors. If the people who pay for the registry think it *should* be this way then fine, but otherwise the addresses should be made available as a valid business service (to be passed on to paying customers). Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
participants (5)
-
Adrian Bool
-
Daniel Karrenberg
-
jcaron@pressimage.net
-
Oliver Smith
-
Peter Galbavy